Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do Not Follow JavaScript Trends

pragmaticpineapple.com

Post reply on HN
Print view View original

111–120 of 275 posts

Re: Do Not Follow JavaScript Trends

#111

Post by DelightOne »

mxschumacher wrote: post #5

A good way to not be completely overwhelmed by all the new tooling and frameworks is to have a strong grasp of the fundamentals, here are three foundational resources: "You don't know JS": https://github.com/getify/You-Dont-Know-JS "How browsers work": https://www.html5rocks.com/en/tutorials/internals/howbrowser... "High performance browser networking": https://hpbn.co/

What helped me most understanding the tooling around babel & co was to watch an intro video from vue.js on the new Viue 3.0.

Copying anything by hand while he explains it. With minimal package count.

And always use a code generator later like when you start a Typescript/JS project, because you can do so many little things wrong on your own while you don't know enough.

https://classic.yarnpkg.com/en/docs/cli/create/

Re: Do Not Follow JavaScript Trends

#112

Post by desireco42 »

dlbucci wrote: post #109
andrewl-hn wrote: post #92

I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Deco…

I have to chime in as someone who created an Angular.js app in 2017. I suppose it happens. Not that I actually wanted to, I was just working with a dumbass who overruled me. I don't really have anything it say, I just have a really strong negative association with this specific topic, I guess...

You are not the only one. It is just a question of personality, some people feel comfortable in Angular world, most people are like you and me.

Re: Do Not Follow JavaScript Trends

#113

Post by hajile »

mxschumacher wrote: post #24
no_wizard wrote: post #16

Earlier quoted context omitted.

I also want to add the great Eloquent JavaScript[0] to this list. While its targeted at learning programming as a whole, its still a wonderful resource, even for seasoned programmers, to learn some ins and outs of the language if you haven't had a lot of experience with it. I also want to give mention to JavaScript: The Good Parts by Douglas Crockford[1], and his new book, How JavaScript Workers[2] [0]: https://eloqu…

Given the publication date of May 2008, isn't "JavaScript The good parts" deeply outdated at this point? Would you still give it to a beginner?

It's a subset of modern JS, but a subset you cannot escape from as all modern features are layered on top of it.

Re: Do Not Follow JavaScript Trends

#114

Post by MaxBarraclough »

thanatropism wrote: post #35
Tade0 wrote: post #14

I feel like these problems are endemic to React and the surrounding ecosystem. Since its introduction in late 2016 Angular 2+ has had no major changes on the scale of hooks and is unlikely to introduce them, because its target audience - large companies making large-scale applications is fairly conservative. Vue I think had one measurably large syntax shift around v2.5(or 2.6) and will have another one with 3.0, but…

As an outsider, I feel like React both does too much (a virtual DOM? Aren't current web standards enough to make a flower shop website?) and too little -- there's all these terms/technologies/subframeworks that people are using like "create-react-app" and "Redux" and so on. It's neither an overarching architecture that makes normal web technology obsolete but runs on it, like Windows 95, nor a website generator like…

> a virtual DOM? Aren't current web standards enough to make a flower shop website?

Of today's frameworks, all but Svelte use a virtual DOM.

Re: Do Not Follow JavaScript Trends

#115

Post by tarsinge »

andrewl-hn wrote: post #92

I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Deco…

You are overly optimistic with the timeline. No, React had not "won" by 2015, not even by 2016[0]. Also the burn of more than half a decade is very real, both on developers and in codebases.

[0]http://2016.stateofjs.com/2016/frontend/. From that link:

> What's more, there's just so many options: Do you use React or Angular 2? Do you really need Webpack? And what's this month's recommended way of dealing with CSS?

> Like you, I spent far too many hours reading about all this, and at the end I still wasn't sure. So I decided to create a survey to see what everybody else thought. It seems like I must've hit a nerve, because I got over 9000 answers in just over two weeks!

Re: Do Not Follow JavaScript Trends

#116

Post by munchbunny »

duxup wrote: post #9

I'm a little lost on the examples. There are reasons to use fetch and hooks, and the article seems to relegate them to being unnecessary 'trends' without doing what it suggests, actually evaluating what value they might have... In React you can use hooks with a class heavy application and still be just fine / get the benefits of hooks in a given component(s). If you want to use fetch, that also is hardly an ordeal to…

I've settled on one maxim when it comes to evaluating new technologies: there is no free lunch. In real projects there is always fundamental complexity. Where will that fundamental complexity go?

If a new framework/library/paradigm comes in looking really hyped up and cool, my automatic question is "well what's the catch?" There always is a real caveat in there somewhere. Usually the new shiny thing solves one class of problems at the cost of making a different class of problems harder to solve. The important question isn't what the shiny thing makes easier, because everybody and their grandmother is telling you what that is. The important question is what that shiny thing makes harder.

React, for example, is awkward for continuous, time-stepped state (games) because what you see is an interpolation of many objects transitioning between many states. It's not that the abstraction can't work, it's that it's a clumsy one to apply. Thankfully the vast majority of web apps don't have this issue, so it's usually fine, until you try to make something real-time.

Same story with NoSQL databases. The canonical issue there is that joins are much more expensive. So how much do you need those joins? Turns out some non-trivial number of scenarios are fine without joins, but for CRUD apps, turns out a substantial number of things are easier with joins.

Re: Do Not Follow JavaScript Trends

#117

Post by hajile »

nailer wrote: post #98
oefrha wrote: post #65

Earlier quoted context omitted.

Kinda funny the author refuses to evaluate a five-year-old (?) standard (fetch), labeling it a trend/hype. And what are they holding onto? A third party library they “used before”; even cited the number of GitHub stars — i.e. aggregate trendiness — to justify the choice. Pretty sure at some point someone dismissed it as a trend and held onto their XHR, and they would have had a better point.

> Kinda funny the author refuses to evaluate a five-year-old (?) standard (fetch), labeling it a trend/hype. And what are they holding onto? Fetch is a very poor standard if you compare it to high-level HTTP clients that have been around since 2010-ish. However it's author states that it wasn't intended as a general purpose HTTP library but rather a low level tool that-level tools can make use of. So yes: you probabl…

Lots of us remember the days of XmlHTTPRequest. Fetch is downright modern in comparison. You should understand how your browser actually works and in this case, it's actually gotten a lot easier.

Re: Do Not Follow JavaScript Trends

#118

Post by wegs »

andrewl-hn wrote: post #92

I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Deco…

Rewrites only make sense if you get a multi-fold improvement. In the history of computing, that's rare. So they rarely make sense.

Well, JavaScript was really horrible when it came out. It was just about the worst major programming language ever made. It sort of reminds me of an interpreter I threw together for a programming language I invented when I was in high school, when I really didn't get any aspect of programming language design, and I based it on a misunderstanding of Lisp.

Given its central role, lots of people used JavaScript, and lots of smart people tried to fix it. Every few years, it'd get a lot better. It actually made sense to rewrite everything -- you got that multi-fold improvement in productivity going 1995 JS to 2000 JS, 2005 JS to 2010 JS, and so on. I mean, with each iteration, it was still obnoxiously bad, but it was that much less bad.

It looked like an exponential growth curve for a while, but you always knew it was an S-curve -- you hit an inflection point when you reach the level of competently-designed programming languages.

At some point in the past five years, JavaScript stopped being really bad. I mean, it's no Python, but it's at least within spitting range. Heck, it's better than Java. I won't even lose 2x productivity writing in JavaScript over best-of-breed languages, at least core language (ecosystem aside -- there is no numpy/scipy/pylab -- but that will come too).

With that, rewrites every five years no longer make sense. Unless there's some fundamental progress in computing, I expect JavaScript code I write today may still be used in 20 years. That's not something I would have said in 2010 or 2000.

Re: Do Not Follow JavaScript Trends

#119

Post by jaquers »

Didn't read. Follow JavaScript trends that make sense for you and your team. Ignore the noise, get shit done.

You know what I hate more than "JS fatigue" - it's ppl complaining about "JS fatigue". Software evolves, and I'm always looking to bring a better experience for my users - and then means replacing components sometimes when there are clearly better alternatives, whether that is for developer experience, smaller bundle sizes, etc.

Re: Do Not Follow JavaScript Trends

#120

Post by z3t4 »

mxschumacher wrote: post #5

A good way to not be completely overwhelmed by all the new tooling and frameworks is to have a strong grasp of the fundamentals, here are three foundational resources: "You don't know JS": https://github.com/getify/You-Dont-Know-JS "How browsers work": https://www.html5rocks.com/en/tutorials/internals/howbrowser... "High performance browser networking": https://hpbn.co/

In order to learn JS you should grasp the event loop. Once you learned to think async, being able to write queues, limit concurrency, etc its just different flavours of syntax and ES6 is mostly syntatic sugar. If you are a web dev you should learn the basic web APIs and avoid libraries and frameworks at all cost. Dont use React until you have written a web component without it. Also if you are a web dev, learn CSS its very simple and powerful once you understand that a rule below overides a rule above, and a more specific rule overides a less specific rule.
Post reply on HN