Do Not Follow JavaScript Trends | Hacker News Reader

Do Not Follow JavaScript Trends

pragmaticpineapple.com

245 pointsnikolalsvk272 comments

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 Decorators vs not using them, and now Hooks. These were mostly cosmetic choices, and if your team picked the wrong side they could migrate over relatively painlessly or straight up ignore the issues for years.

On the other side of spectrum we have Ember that maintained backward compatibility and ease of upgrades since ~2013, Angular 2+ is doing the same for many years, too.

The whole "JavaScript fatigue" meme has to go.

100%. Normally these articles are thinly veiled attacks on something that has changed in the author's coding ecosystem that has angered them. When I saw hooks in the first few paragraphs I assumed it was going to be a "hooks are bad, mkay" article. It isn't, but still some what vague on actionable points or ideas.

Ultimately no one likes rewriting code and is typically under-estimated since developers mentally trivialize previous work rather than a greenfield affair.

I agree for frameworks, but building tools and package management are still nightmares for me

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.

It's probably not that angular is dumb - using angularjs 1.x in 2017 is dumb. And I do concur as someone who also wrote angularjs app at that time and eventually left the company over it.

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!

From that survey, is you look at positive (would like to learn + would use again) vs. negative responses (not interested + would not use again), it looks like React is crushing everything outright. 85% positive / 15% negative. Amongst the other frameworks, the only one without at least 50% negative response is Vue at 43% positive / 35% negative, with a heart "never heard of it" segment as well.

Who cares what developers 'like to learn/use' when in practice they often don't get to, or get lucky and their preferred approach/tech is considered 'safe' a few years later?

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.

How about using Typescript? That still seems like a huge improvement, especially because you can implement it incrementally (aka for parts of code where type checking is vitally important).

I'm using it now at my work and I'm surprised how much info I'm getting compared to whatever JS is throwing at me.

Typescript doesn't strike me as a multi-fold improvement. Dynamic vs static typing is an age-old debate, and in general, advocates can be found arguing that moving your code in either direction results in benefits. So, regardless of your stance on it, it seems unlikely to be unambiguously beneficial. Many large programs exist written in dynamic languages that do just fine.

It seems like it's trending toward static, at least recently. I think the big driver for this is the popularization of statically typed languages that aren't C++ and Java. A lot of people had painful experiences with C++ and Java and attributed that pain to static typing. It's now more clear that static typing is a net benefit, but it must be implemented reasonably and it doesn't solve other language design issues. Also, C++ and Java have each evolved some rudimentary type inference, which improves ergonomics (although I think excessive type inference a la Haskell actually makes it harder to debug issues--the sweet spot seems to be function-scoped type inference).

Hard to say. It seems as cyclic as anything else. Hard to tease apart real benefit from the usual fad/hype cycles.

Ruby, Python, Erlang/Elixir, Lisp/Clojure, etc, all doing just fine without it. (Some, with some lightweight annotative-oriented typing for a subset of projects.)

The best counterargument to static typing I can articulate is that in general, the only way to be sure software works is to run it. And so, ultimately you need to backstop your software with testing, QA, and observability infrastructure to actually execute it and validate it. At that point, the question is what marginal gains remain from catching a subset of those problems at complile time, also incorporating a potential a false sense of security which may lead to less actual execution validation, and more user-facing issues. The other potential tradeoff of static typing is if the software design and architecture changes for better or worse, or if the velocity of shipping changes changes. I believe there isn't yet any hard evidence of which way this tilts in either case.

There's also a lot of innovation in the area of validation-by-execution as well, and so I think that will result in continual debate: state-of-the-art static typing may benefit compared to yesterday's testing/fuzzing tools, but may not compared to state-of-the-art testing/fuzzing tools, for example.

One of the greatest boons of static typing is formal documentation of data structures and interfaces. Catching errors early is a bonus :)

I'm not disagreeing per se, but at least in the Elixir community I get the impression that using Dialyzer (the wonderfully cryptic TS-ish gradual typing solution) and typespecs is increasingly advised and there's a thirst for a better solution. But static typing comes up a lot.

We're doing fine without, but it's definitely a sore point and I'm one of those developers who has become more and more fond of static typing.

Python is trending toward types via support for type annotations. My extensive experience with Python and Go leads me to the conclusion that it’s very difficult to write even moderately complex and maintainable Python code at scale. This doesn’t mean that no one can make money with Python—far from it—only that they would make even more money via Go (iterate faster and spend less time fixing bugs). Of course this can’t necessarily be extended to other languages. C++ and Rust would not be as productive up front than Python and C++ would probably not save you any time fixing bugs. A lisp might be faster to develop in than Go and Python without incurring too many type errors. There are too many variables to make sweeping statements, but all else equal, in my experience, static typing is better than dynamic typing. But again, there are many other variables that can cause a dynamically typed language to outperform a statically typed language for iteration velocity or bug reduction.

Yea, this is why I posted it. To me it seems:

- Small codebase. Fine, use both.

- Medium codebase. Fine, use both.

- Large codebase. You're definitely going to have some typing bugs with dynamically typed languages.

- Humongous codebase. You're definitely going to have many typing bugs with dynamically typed languages.

I'll say that we have a small-medium code base and we see lots and lots of dynamic typing errors in production every day. I would also say "even though we have lots of people who are experienced Python developers", but I think it's actually because we have so many developers who have only developed seriously in dynamically typed languages and don't "think in types" if you will.

Can’t you write the Python functions to force check the input parameter for its type? And error out if not.

This should enable you to catch most errors immediately during development.

Yes, but easier to just write tests.

And easier still just to use static types.

Often not, if the overhead of adding them outweighs their utility for the project.

No, this doesn’t help at all. You only hit these errors if you run those paths in your tests, but those paths would already error downstream. Those paths that weren’t tested may still contain errors that go to production, and again you just hit your new type error instead of the downstream type error.

What you need is something that can help you test more paths, and static type checking checks all paths. Further, they can check all paths without writing any tests (you should still have tests, but you need fewer with a static type system to keep your bug rate the same). Moreover, static type checkers catch errors almost immediately, so you get feedback about your errors sooner rather and more frequently, so you spend less time investing in code that will have to be rewritten. Lastly, they put rails on the code—it’s harder to write bad code including gratuitously magical or abstract code, so your coworkers aren’t writing as much bas code that you have to interface with. If you find static type systems to be frustrating, you’re probably the problematic coworker. :)

I don’t disagree with you. Python seems to encourage poor development practices. Basically, anything goes. This can be problematic if you use other people’s libraries, and if their libraries are not fully vetted.

This is not a Python problem, per se. It is a developer problem. It is a human problem.

However, with your own code and libraries, you can enforce your own rigor. Keep your functions smaller, test all the inputs, and validate all the outputs. Although you may end up with smaller production code, but more unit tests.

The unit tests are good, as they give you evidence that you did cover those corner cases.

However, the good thing, is that if the functions are smaller, and well unit tested, then it becomes rare that you have to modify it at a later date. And especially if you think through all the different angles, and try to future proof it. Now you have the ability to do functional composition. Just keep chaining the outputs of one function into another.

well, sure. certainly one of the costs of a dynamic language is the possibility of typing bugs, and those will likely grow linearly with the size of the code base.

the question is if those programs were written in statically typed languages, how the world would differ, in-full. for example, they may have been built faster or sloer. or they may have better or worse test coverage, affecting severe defect count overall. or you may have had to hire a different team, with tradeoffs. hard to say.

The trend toward static typing is a fad, like NoSQL in the early 2010s. Who knows what the next fad will be. Perhaps correctness proofs will make a comeback.

I would avoid doing state management in Typescript. It's still too early in my opinion.

Use as many hooks and context as possible and keep your redux store as simple as you possibly can because if you end up with a deprecated state management library (redux-thunk, sagas, easy-peasy) replacing that is like pulling gum out of hair.

If you add up the time spent working around typescript errors when dealing with state, it's possible for it to be more time than you need to rewrite the entire app.

For backend work then yes, I'd say doing a singleton or an abstract class in typescript makes more sense in hardening your API code and even making it more readable too.

I'm a Redux maintainer, and I'm _strongly_ in favor of using TypeScript for any meaningful app development [0] [1].

Also, I don't know why you're referring to thunks and sagas as "deprecated". Thunks are the recommended default approach for async logic in Redux [2], and we include them out of the box in our Redux Toolkit package [3]. While most apps don't need sagas, they're a great power tool to have in your toolbox. Neither of those is in any way "deprecated".

[0] https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...

[1] https://redux.js.org/style-guide/style-guide#use-static-typi...

[2] https://redux.js.org/style-guide/style-guide#use-thunks-for-...

[3] https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh...

Sorry I meant as in an older version of a library that an app has been built on and hasn't been updated or maintained for a few months.

I should have put that better, the libraries themselves are not deprecated, their dependencies can be.

While this negligence problem would be on the fault of the dev team and management for not doing regular package updates it is an all too common issue in many companies.

What I am saying is that bad typescript is harder to fix than bad javascript because type errors compound the problems of convoluted code.

In my opinion, if you're going to add a compilation stage to your bundling anyway, you can get far more mileage out of other options (such as Fable) than the tiny improvement TypeScript is.

The additional compilation complexity is not worth the small benefits of TypeScript, in my opinion. An even better language, though? I'm in.

Never heard of Fable, will check it out! :D

TypeScript? Erm... Not for me.

There were many such systems in the past. CoffeeScript was a big improvement over 2010 JavaScript. Before that was GWT, which was sooo much nicer than 2006-era JavaScript. I could list a bunch of others. If you used any of them, you're now stuck with a legacy system(+), and you'll find fewer and fewer people able to read/write your code, and otherwise.

I'm also not a big fan of static typing. And if you do static typing, you should at least do it properly, which is not what TypeScript does.

Types should be things like "This is an integer between 0 and 100," "Meters/second," or similar. We've known this for a long time. Ada is now 40 years old and was mandated for military work since if you added feet and inches without a conversion, that was a problem, and that resulted in more robust systems (TypeScript would make them both of type "number" and never catch the error). If you tried to have 120% of your fuel tank full, you'd violate an assertion as well. Those were turned on in dev and in your test suite (but generally turned off in your deployment system, which was running on a 33MHz CPU if you were lucky).

C++ templates let you define things like "This is a list of lengths, in meters." Duck types languages like Python won't do this statically, but it's easy enough to do dynamically; while you won't catch errors at compile-time, at run-time, you'll get a clear exception.

(+) Standard disclaimers apply.

Dependently typed language can check at compile time if you violate a ranged integer value among many other things.

I'm curious though why you are not a fan of static typing? I feel like if you have a language with inference it's pretty good. I mean you could imagine python with type inference and you could essentially write anything in it you can today (baring stuff like heterogenous data structures) without specifying the type manually.

(1) I like generic code which I can use as I see fit later. In Scheme, I can write:

(lambda (x) (* x (+ 3 x)))

A half-decade later, someone can take that code, pass a pair of specially-crafted objects to it to introspect what it does, and take a symbolic derivative, pretty-print that derivative with LaTeX, combine it with a few other pieces, and compile it into native code (and yes, that does happen).

But a lot of my code is generic in a way where types get in the way.

(2) If I do have typing, the type should usually be specified manually, but it should have semantic meaning, not be based on inferring whatever types my programming language happens to have built-in. What's important isn't that something is an integer, but that it's a count-of-apples. I should be able to compare a count-of-apples to a count-of-oranges without first converting them to a count-of-fruit.

This is especially important for numerical code, and especially in education. A lot of Scratch tutorials have little kids add a velocity to a position, without first multiplying it by a time. That leads to deep-rooted misconceptions.

I don't mind type inference if it's designed to give me feedback. I've seen a few systems (designed for students) which do things like take JavaScript:

let x=5;

let y="hello";

let z=x+y;

And flag that in the IDE. That's kinda nice. And obviously, many systems do optimization at runtime based on inferred types. That's not a problem either.

So there's a fuzzy layer in between. But the discussion was about TypeScript, not that fuzzy layer.

I don't really see how the first example is incompatible with static types. Most often type inference infers the most general type possible. That means you can do exactly the same things with that lambda in a statically types language as in a dynamic language.

The second example with count of apples and oranges is bad. Those are unitless and a thus Just an natural should be fine for them. Numerical code can get messy but that's exactly were the power of static typing is the best. You can have dimensions and units in a type system and you get dimensional homogeneity correctness for free.

I agree that well-designed type systems can be helpful, and in an ideal case, I'd have a mix. It's just that TypeScript is not that. The gap between the types of type systems you're describing and TypeScript is the Grand Canyon.

re: type inference

Inferential type systems fall into a fuzzy zone between statically and dynamically typed. For example, many JITs for dynamically typed languages do type inference, and generate compiled code optimized to the types actually being used. That's a very obviously good idea. And many linters look at inferred types as well to do compile-time checks. That's also an obviously good idea. But I wouldn't call a JavaScript JIT a statically-typed system (or Python code that's been through Pylint).

re: Apples versus oranges

They're not unitless. In the first case, the units are apples. In the second case, they're oranges. You shouldn't compare or add those types. If I do have a type system, that's something I should be able to specify.

Not to mention implicit conversions, if I want them (12 inches + 1 foot = 24 inches).

Well yeah typescripts typing sucks but that's not my point. Type inference falls squarely in the static typing camp. It has nothing to do with dynamic typing.

Take a look at the Haskell units library. That can do the things you illustrate.

Typescript greatest features are optional types and the extensive type inference. On small projects this can work well, but on larger ones I can see overly rigid style guides requiring typing everything explicitly in triplicate becoming cumbersome in an Enterprisey way. Curious what people's experiences are.

Typescript, for me, makes JS jump from 'good enough' to 'might use it even if I have other options'.

I still prefer using other languages when I can (back-end), but hypothetically, if I had to choose between Ruby and Typescript I'd actually go for the latter. And I like Ruby!

Typescript is leagues ahead of Python. Types and async/await are the big ones, but destructuring, no lambda weirdness, optional chaining, nullish coalescing, proxies, JSON support, and generally debugging tools are all better.

I'm not well-versed in TypeScript, and I have plenty of frustrations in Python so it's not that I don't believe you, but I do have a few questions:

* Python has async/await. It's not as pleasant as goroutines, but it exists and is presumably about as pleasant as async/await in TS, at least assuming you're using or not using the type system in both cases.

* Python has tuple/list/iterable destructuring. What is the specific limitation here? Maybe key/value destructuring?

* What's python's lambda weirdness? The single expression limitation? I agree that's tedious, albeit you can do a lot with a single expression (but not handling exceptions).

* JSON support. What's wrong with Python's JSON support? I mean, the type system can't model recursive types yet and that's super annoying, but the JSON stdlib seems fine. JSON maps pretty neatly onto Python dict/list/str/int/float/None/etc types.

* What are proxies and why are they desirable? Genuinely curious.

Python has some async, but it never felt as core and easy.

Tbh, it’s been years since I’ve done much Python. But the last time I did it was just really clear that TS had leapt ahead. Ecosystem may be part of it.

Proxies are essentially meta programming tools, tbh not fully sure Python doesn’t have similar but on looking they don’t seem as intuitive.

As previously mentioned, I'm a Python critic, but it has changed a lot since you last used it. Async (for better or worse) has gained a lot of traction as have type annotations (although the type checker is a huge pain--can't model JSON or any other recursive type, can't express a callback that takes kwargs, getting it to acknowledge type stubs on upstream libraries is a forbidden art, it's pretty slow, etc).

No doubt that TS is better, however. It has amazing engines, an MS-backed developer experience, coherent type system, not the worst package management ecosystem, etc. If I could switch us off of Python to any language, I would choose Go but I wouldn't be angry if we landed on TS.

Proxies are a feature in ECMAscript that TypeScript inherits - it lets you substitute one object for another so you can intercept and override object properties.

Having used both Python and Typescript recently, I largely prefer the consistency of Typescript. [Hey mom, I like cherries better than strawberries]. Having said that, I'd love to have named function arguments in Typescript. Props workaround is, well, a workaround.

What do you mean, everyone is now updating their codebases to remove redux, HoF and switch to hooks.

No, people are realizing that they were just using redux as a caching layer and the boilerplate associated with it wasn't worth it when there are better approaches to caching local data now.

What do you believe people are replacing it with? Hooks?

I disagree. Redux has a lot of icky boilerplate, but the Flux pattern, and variations of it, are useful. You're either using Redux, something like Redux (context hooks, possibly), or you are passing single variables through 3 or more layers of spaghetti.

There's truth to both these statements.

If the only thing you're doing with Redux is just fetching and caching data, and nothing further, there are other tools that are likely going to be more ergonomic for that (Apollo, react-query, SWR).

However, if you're actually _manipulating_ that data after it's been fetched, or working with more complex client-side state, the Flux architecture really becomes useful. As the Redux docs FAQ entry on "When should I use Redux?" says [0]:

> In general, use Redux when you have reasonable amounts of data changing over time, you need a single source of truth, and you find that approaches like keeping everything in a top-level React component's state are no longer sufficient.

(We also have additional guidance on when it makes sense to put any given piece of state into Redux [1], and I'm adding more guidance on this sort of topic as I work on rewriting our docs.)

Beyond that, our new Redux Toolkit package [2] has been specifically designed to eliminate most or all of that "boilerplate" concern, and provides a set of utilities that simplify most common Redux use cases. We now recommend it as the default approach for writing Redux logic, and I'm currently working on a new "Quick Start" docs section [3] that will teach it as the right way to use Redux for beginners (alongside the existing tutorial sequence that teaches how Redux works from the ground up).

Related to this, while I've been very reluctant to try to build any type of official Redux-based query/caching solution, we _did_ recently release a new `createAsyncThunk` API [4] that simplifies the process of dispatching actions while fetching and a `createEntityAdapter` API that handles some normalization [5], and I _am_ considering trying to add some more involved abstraction to RTK in the near future [6].

[0] https://redux.js.org/faq/general#when-should-i-use-redux

[1] https://redux.js.org/faq/organizing-state#do-i-have-to-put-a...

[2] https://redux-toolkit.js.org

[3] https://deploy-preview-3740--redux-docs.netlify.app/tutorial...

[4] https://redux-toolkit.js.org/api/createAsyncThunk

[5] https://redux-toolkit.js.org/api/createEntityAdapter

[6] https://github.com/reduxjs/redux-toolkit/issues/603

Out of curiosity what are the better approaches to caching local data? The only thing I'm aware of is something like Apollo client but .. that only works for graphql.

react-query, swr

Hooks isn't a replacement for Redux though. It enables you to build state management in an easier way, but Redux is not just holding state, it describes the change of state

Yeah I have to say I agree. I think there was valid reasons for some of the framework churn early on (basically no proper standard way to do client side GUI). When the MVC-oriented stuff started to stabilise we all discovered that functional reactive programming UI was a good thing and that drove stuff like React and Angular 2.

But there simply hasn't been a paradigm shift in UI after that (and I doubt there will anytime soon, it's not often a whole new UI paradigm that changes stuff the way MVC and FRP have done is popularised).

Stuff like Vue and Svelte are simply attempts at optimising or improving the reactive approach, but is basically still fundamentally the same idea. Someone versed in React would easily move over.

I don't think hooks are a superficial change. If react stayed with class based components, I'd agree with you.

Yeah; I think your timeline is off. I don't remember React being the very clear choice until probably 2017. It was still up in the air in 2016, and certainly moreso in 2015.

> by 2015 React "won" the framework battle.

Things have calmed down now. Its better, and has been for a couple years (not 5+ years). But, this isn't a battle. Its not a war. Just because things are calm now, doesn't mean they won't go crazy again.

The core of the issue has nothing to do with technology, or the frameworks, or programming languages. It has everything to do with how you, I, and Dave, who's reading this right now, respond when these new technologies come out. Just. Say. No. Play with them. Build toy projects. Give feedback. But for the love of God, at the end of the day, you Say No. No, we will not be integrating this. Looks cool though, we'll circle back in a year and see what progress you've made.

"I don't remember React being the very clear choice until probably 2017."

Maybe you werent paying attention then.

CSS Modules didn't become the default way to go until sometime in 2016. Before that point people were still stumbling over how to manage their CSS in a component-oriented fashion, and it was only once that happened did React "win".

CS Modules are still not the "default", this space is still up in the air. There's CSS-in-JS (like styled-components or Emotion), Sass, plain CSS, etc.

Even utility CSS like Tailwind is gaining popularity...

They're at least compatible then.

More important to my point, back in 2015/early 2016 and before, you more likely than not had to somehow manually include the CSS for a given component library into your page. Right about the same time CSS Modules got popular, the CSS from libraries started getting included automatically in the compiled CSS file (whether by way of CSS Modules or something else that at least doesn't conflict with it).

I remember this part of the timeline pretty distinctly because late 2015 is when we started a new project in React, and struggled with how to reliably deal with CSS for several months.

It wasn't in many places even until 2018 at least. HN isn't the real world.

Either way the article is way off:

> Let us quickly travel back in time to 2016 ... If you are using a JavaScript framework or want to use a framework, Angular.js is probably something you would choose

Angula.JS was in the "failed experiment" category by 2016. The announcement that Angular2 was a rewrite (in 2014) was proof of that.

So in 2016 Angular was still really new and React had eaten AngularJS's market share.

I completely disagree, at least when it comes to my surroundings.

In 2016, the vast majority of recruitment offers I received were Angular, or jQuery/javascript. And while HN (thankfully) was all about React and whatnot, this situation continued for a good few years. Angular was the safe choice which I guess the PM's wouldn't get fired for. I remember many, many conversations with various recruiters where I told them I refused to do Angular projects, but I'd love to work on a React or even 'vanilla' JS project.

I'd say that after React became 'standard' on HN (around the time Vue popped up I suppose?), it took at least 2 years before I started getting emails and calls from people looking for React work.

Currently hoping this will happen with Elixir but not getting my hopes up :). Still, not having this sword of damocles hanging over my head that 'maybe I should learn Angular' is real nice.

You make it sound like we're all using React and that's all there is to it. That's not quite true, and it's just one of the choices you have to make. So you've decided on React, but what about state management, transpilation, do you use GraphQL? What am I doing for styles, should I write them in Javascript too now? Oh no! Webpack isn't for me! Can I use modules yet? Ah bugger, we need SSR, suppose I should have managed state the "Right Way (v28.6)", doh!

I even got fatigued reading your list of choices and you even missed critical choice such as flavor of SSR.

Excuse me, it isn't a real frontend without a service worker and offline capabilities.

Just use Next! I mean Nuxt! I mean really just give up and go for Phoenix LiveView or TurboLinks or Blazor...

People were still writing CoffeeScript in 2015.

Agreed, but I wouldn't put 2015 as the year React "won". It did "win" the SPA frameworks war, but back then the default for webdev was still non-SPA and React was competing with jquery/"no framework" and the rest of not-quite-spa frameworks like backbone, ember, etc. Nowadays React is the standard, I dare say even for SSR sites!

The javascript framework fatigue meme was born during the early days of ember, backbone, angular 1, knockoutjs and meteor. Sometime between 2016 and 2017 was when it should have been put to rest.

Angular(1) wasn't simple but knowing basic stuff made it possible to do complicated things quickly. Angular lost a lot of momentum when they decided Angular had to look like JEE and become a framework trying to justify its existence with complexity.

React had the right idea, just make view management simple, don't force some bullshit IoC container on Javascript and that's it. If you want IoC that's your problem.

Ultimately the problem is that nothing replaces React natively in web API. A tool such as React shouldn't be useful anymore and Web Components isn't as ubiquitous as it was envisioned to be. In fact, I've never worked in any business that used Web Components.

But the biggest issues are on the node.js side and all the complex pipelines put in place in order to fix front-end development. In fine, the tools that will be successful are the ones that will still be actively maintained 5 years from now, and most of the libs/projects will not.

I see it a little differently, Angular 1 lost momentum because it was a bad framework. It was clearly written by people that did not have a lot of experience productionalizing code. Further they choose new and convoluted naming for concepts that already had names. The came up with a creative new way to introduce globals thru rootscope and performance was abysmal. Their component model was leaky at best and the whole framework encouraged writing monolithic controllers that where in the same vain of Backbone.js. There where actually good frameworks at that time such as Dojo they just did not get the mindshare that Angular got and a lot of that was due to it being incubated at Google. The second part of the issue is there where not many people doing hardcore Javascript programming and so there was not a depth of deep CS knowledge in the front end space. It took more and more of them reluctantly converting over, getting one look at Angular and going look guys this is bad because of X,Y and Z. Angular 1 actually set the state of the art back compared to some of the other offerings at the time. The absolute tell, was when the team had to admit it, admit they where going to scrap it for a total rewrite that was to become Angular 2 and on.

The reason React has done so well, is that core team members had deeper CS experience, understood other paradigms for UI development and understood that the best state of the art for UI right now, is a render loop. If you converted it to C, squinted at it long enough you would see the very old, very tried and very true Windows render loop in it. They took a proven pattern, bolted it to the virtual DOM and brought it to the web. They did not perform miracles, they stuck to what has been proven to work. Well the virtual DOM was a pretty clever hack, but the rest is UI dev 101. The problem was most the JS developers at the time, never had that back experience of desktop UI development and a good deal of them had come to development by way of learning HTML, CSS and then bits and pieces of JS as they needed to.

But how long was Angular in vogue before React? If it was also ~5 years then a shift in frameworks every 5 years of calm + 2 years of chaos still isn't ideal.

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/

Agreed. I think a lot of folks suffer from not understanding how web 1.0 worked and really groking REST/HATEOAS (which has since been hijacked for JSON APIs, which is complete nonsense.)

Sometimes I jokingly call htmx "web 1.1 tech", but increasingly I wonder if I'm really joking.

There is the the HATEOAS compatible JSON-LD standard being worked on at the W3C

https://json-ld.org/

Yeah, but it doesn't make up for the decade+ now that plain JSON (perhaps with the occasional URL, which still has to be interpreted correctly by client code!) has been called "REST-ful".

On top of that, JSON-LD is still mainly focused on networked object graph serialization. Unfortunately it manages to be a complex specification without providing the functionality that HTML came with out of the gates as a hypertext in an obvious manner.

HTML is a good-enough-to-great hypertext, we should probably stick with it.

In 1996-1998 as a teen I "made some websites" for local businesses. The one I made for my parents even had a search function (in PHP) in a CSV with their products (which were like 100). The CSV was generated by taking whatever Lotus Approach (their desktop DB) generated and transforming it with some custom Haskell code (I was a teen, what did I know). They clicked an icon to pull the data and another to run a FTP batch file.

Fast forward, I understand nothing of the website being developed in React for my startup. The othe technical cofounder does grok it, but I could not lend a hand and can barely even supervise the outside help we brought. I like to think of myself as well-versed in a generalist manner. I can hack a custom sparse matrix (with a very particular structure I was able to prove an iteration for) inversion algorithm, but I understand nothing about painting the background the correct shade of blue!

I have something for you:

https://htmx.org

Yow. I have an application growing out of control in Streamlit (https://streamlit.io), which is a rshiny-type interactive dashboard gizmo. I'm now able to consider rewriting it with a proper front-end.

It's like a whole world I had been sealed off from has reopened.

(Note: I'm Head of Developer Relations at Streamlit)

Out of curiosity, which features are you looking for in a "proper" front-end? Flexibility?

Streamlit is magic and I don't want this to come off as a dismissal, but it can be unpredictably unreliable. I keep having this issue if I run > 0.58:

https://github.com/streamlit/streamlit/issues/1440

It's over a month old now, with multiple people reporting the same bug and iterating on the problem with no apparent narrowing towards a reason for why this happens, let alone a solution.

Thanks for clarifying. Since HN isn't the right place for a detailed discussion, I would invite you to comment on that issue and try to help us work through it.

As one of our engineers mentions in the linked issue, this bug is hard to trigger (as is the nature of many bugs), and she is working on a solution[1]. This issue has also been reported here[2], with the solution of adding time.sleep(1) inside the loop usually resolving that problem.

[1] https://github.com/streamlit/streamlit/pull/1494 [2] https://discuss.streamlit.io/t/displaying-images-from-opencv...

Yeah. What I should have added here, but didn't want to sound brash and rude, is that Streamlit should focus on having a reliable working product before spreading out as an org with a Dev Relations department.

I know this is a complicated problem domain (because it's the web, Mathematica did this well with complex graphs in the mid-90s), but as it stands now my project has an input on which the graphic depends and a default value; the image breaks before the input control is touched. And it's not a slider, it's a dropdown that makes the app query a db first... I mean, I think I can do this in plain Ajax if I get my story right about sending images. But it's a hobby project meant to explore mathematical ideas...

If you can't do sliders reliably, they should be moved to a beta branch. Streamlit overpromises and underdelivers. But it's a great project, I don't want to be too negative about it.

I see you've both commented here and on GitHub, so I'll make my last comment here and then we can address the specifics on your ticket (I didn't realize I referred you to your own GitHub issue).

As I mentioned, there is a pull request already created for this issue; our head of engineering/founder says its being held up by a lack of tests before merging. This problem isn't a slider issue, but a race condition in our session state manager.

Regardless, one month is a pretty trivial amount of time as far as open-source projects go, as well as in the history of Streamlit (project became public Oct 2019). Like all projects, we try and address things in the order of severity, and as far as this issue goes, it's a pretty isolated one, not an indication that the library is unreliable or somehow reflects that our engineers can't design at an early-90s level of engineering.

.componentInQuestion { whateverBackgroundTagIsCorrectInCss: #hexvalueForColor }, no?

Well it depends, because maybe you're using Styled Components or some other library that ties you into the React/JSX ecosystem.

Or maybe your app passes a 'theme' through various contexts and you have to find the right theme and find the thing you need to tweak the background colour for, which might be in a CSS file pulled in through Webpack if you're lucky.

If you're not lucky, maybe there's some funky SASS/LESS setup where all of the colours are stored in variables describing their purpose, in one of a dozen specially categorised files for storing globals. Now there are six or seven values all with '#xxxxxx' as the colour value and you don't know which one it is, so then you're thinking, is this `lightBlue7` or `darkBlue-3` or `cyanish4`.

Or maybe a few event listeners pull down style information into the component state after first rendering with a bunch of placeholders, so now the component you're looking to change the background of is a function of the time spent on page.

Or, maybe you found some CSS and it was an easy change, but then the project is in Typescript and the CSS is actually derived at build-time from an enum containing all of the config, which is used to replace specially formed strings in the CSS while having sensible defaults in dev.

If you're cursed, the CSS isn't even in your frontend at all and a server-side rendering system is generating your styles from DB backed configurations, which are queried by a graphql layer in your frontend so users can customise their UI in their profile settings, so you have to write a database migration and run a full deployment to add the new colour and its customisation UI to the frontend.

If this seems absurd to anyone, this aligns closely with my experience in React and even more with Gatsby....

I think if I was promoted to CEO, I would go full reactionary and demand that all front end javascript code must be vanilla and interact with the dom directly, and all styling contained in css

Same for me. I even got into CSS and Javascript. Just, you know, right as Ajax was becoming a thing, before SPAs, before Rails even, etc. It was very straightforward.

Now...I'm lost. Every time I poke at the frontend, I get lost again. >10 years as a backend developer of various stripes, three of those in Node even...still lost.

> not understanding how web 1.0 worked and really groking REST/HATEOAS (which has since been hijacked for JSON APIs, which is complete nonsense.)

Anyone who really grokked REST would never say it's nonsense to use with a JSON API.

Yes, I know it's confusing because the language has been so thoroughly corrupted over the last decade.

Let me show you my reasoning:

JSON is not a hypertext, even if you include URLs in it. [0]

HATEOAS requires a hypertext (see the first word of the acronym)

HATEOAS is "an essential part of the of the 'uniform interface' feature of REST" [1]

Therefore a JSON API, even with some embedded URLs, using multiple HTTP Methods and following a traditional hierarchical path scheme, is not REST-ful.

[0] - A sufficiently advanced client could interpret a JSON-encoded hypertext in a general, uniform manner. However, in practice, this is almost never the case.

[1] - https://en.wikipedia.org/wiki/HATEOAS

I really "doubt" you were joking!

I'm sorry, I couldn't resist the pun.

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://eloquentjavascript.net/

[1]: https://www.amazon.com/dp/0596517742/wrrrldwideweb

[2]: https://howjavascriptworks.com/

> JavaScript: The Good Parts by Douglas Crockford

I've been wondering lately, as I'm moving (back) into a JavaScript-heavy stack (it's been... 4-5 years for me), is this book still relevant in the face of 12 years of JavaScript language development?

The code in it will still run and work but there are much better patterns and features now that help you write more succinct and less error-prone code.

ES6 and ES7 are widely supported now and are much better languages IMO.

Thanks, that's kind of what I thought. I recently, finally, took it off of my book shelf and stuffed it into a box in the garage, but it's been in the back of my mind a few times as I've been going through other resources. It's good for the historical understanding but I couldn't see it being terribly relevant today.

As a noobie, Eloquent Javascript was much better for me than The Good Parts. The Good Parts was a book of how not to program, followed by the right way of doing it. Eloquent was a guided path to understanding the language without being shown all the dead ends.

Knowing the dead ends and the history behind them is nice, but I spent a lot of brain power on the dead ends that Eloquent put towards better use.

We're also talking a small book vs a tome of knowledge, but the philosophy is different regardless of size.

Unless the book has had an updated edition it's missing all the ES6 good stuff. It was good to avoid the pitfalls of JavaScript in the past, but nowadays you should be using ES6, strict mode and, if that strikes your fancy, TypeScript.

I personally never really liked that book even when it was new. It's good if you wanna get up and running with JS fast while coming from another language, and are forced to use JS in places but it's not the main language of your project.

But it doesn't really give a strong foundation on understanding the language. It's more like "I know mainstream C-inspired languages, and JS often burns me with its weird quirks like how the this keyword works, I just want to avoid getting burned". But it doesn't really embrace JS itself, just sort of acknowledges that you will be forced to use it in the web so you may as well at least learn the "good" parts.

It's still decent at that purpose, but for really strong competency in JS I can also vouch for the Eloquent JS book and the You Don't Know JS series (I've only read the first edition, a new edition is partially complete and available online).

> it doesn't really embrace JS itself, just sort of acknowledges that you will be forced to use it in the web so you may as well at least learn the "good" parts.

I'm sure you know this, so I'm just pointing it out for completeness sake: that was indeed the only sensible approach to JavaScript back when that book was written.

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?

I would not give it to a beginner, but definitely to an intermediate-plus developer from a non-JS background. The best parts are the reasonable but strong opinions and the admittance of very bad parts. The code is less valuable today but as mentioned above, still runs fine.

Today this book makes a good companion but not a great single source reference.

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

I would like to take this opportunity to point out that the author of "Eloquent JavaScript", Marijn Haverbeke, also created both CodeMirror and ProseMirror [1], which are both extremely well-regarded open source code/text editing tools. I can especially recommend ProseMirror after spending a lot of time with it recently. It's an actually sane wrapper around contenteditable.

[1] https://prosemirror.net/

Somewhat agree. Fundamentals help, but understanding them won't immediately clarify every configuration item in a Webpack configuration.

That's true, but nothing will.

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/

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.

I would add Javascript- The definitive guide (David Flanagan) I just bought it again, Version 7 just been released 9 years after version 6. It’s an amazing book.

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 do / should not be a big cognitive load for anyone.

I get it, resume driven development bad, we get it, we hear it in opinion pieces all the time. Also you should think about it before rewriting an entire application. Yup, that makes sense.

But here we have examples of small changes that are pretty light weight... and no effort is made to do exactly what it suggests, evaluate those choices.

But do we get it? If we get it, why is frontend churn so prevalent?

I don’t think we get it.

Get what?

Resume driven development bad.

Is front end churn really so prevalent? I hear this opinion all the time, but React is 7 years old. I've been using it for around 5 years, I think. Redux is 5 years old. How old does the most popular web framework need to be before we consider it to be low churn?

[Edit: Also, anecdote: before JS, I was mostly a C# developer, and the churn there was at least as bad, maybe worse in my personal experience. Over 15 years of my career, I had to learn ASP, then ASP.NET, and in the Windows app world, we went from WinForms to XAML, then .NET Core came out, and things shifted again... See Rails' history for more examples of churn. It's not like every other platform is a paragon of stability. Clojure is a bulwark of stability compared to just about anything else, but it's hardly fair to hold the front-end community up against that gold standard...]

JS has always been relevant as an ecosystem because it incorporates new ideas. I liked jQuery more than what came before it, and I like React more than jQuery. They make the task of translating an idea into a work app much easier for me, and other programmers I work with also benefit from more readable code.

I wouldn't re-write an existing app to use fetch or hooks, but now that I've taken the time to learn, I'm happy I did. The vast majority of the mental work was done by other people, and I get to reap the benefits. The alternative to this is stagnation, and relegation to legacy systems... I guess the author wishes they could work in COBOL?

I’m not sure if you realize your own paradox. Is churn really so prevalent? You then point out how prevalent it is in the .NET community.

Yeah it’s prevalent, and if we resemble other shitty ecosystems then we need to introspect.

I do realize it. Maybe I should have added: churn as compared to what? JS doesn’t exist in a vacuum. Most language ecosystems experience churn. I explicitly mentioned we shouldn’t hold everyone to the gold standard of stability that is Clojure. But... maybe we should?

I’m not entirely sure that churn is a binary good or bad. When you think, “Hm I have a more elegant solution to this common problem.” And then offer it to the world, you’ll be shot down with “churn” comments. Churn is way we experience experimentation and the slow progress towards a better solution. I, for one, am glad I no longer have to program COBOL.

Anyway, there’s probably a happy medium. Even Clojure has had some front-end churn. Om is no longer the hotness. Reframe seems to have won. Clojure itself isn’t that old.

I’m waiting for the day I can enter a dot net C# codebase the same way you can enter frontend.

None of you make your own landscape easy to enter, and I’m certainly not open to you guys dictating anything in this realm.

We have frontend churn, we are working on it.

You didn’t work on dot net churn while it was occurring, and you show up with the same attitude before the apex on front end. You couldn’t stop it once, and you’re here to enable the next?

If you know how to stop it, talk. Otherwise stay out of it.

We’re trying not to become you.

All client-side development churns. Because it's hard, it runs on user devices in the field. And client development is not a solved problem. It's more a moving target of constant research because client devices aren't static either. It wasn't long ago that touch screens didn't even exist.

The whole Apple client-dev ecosystem is still in the process of changing to Swift, and Apple is trying to develop SwiftUI into a compelling layer alongside/atop {App,UI}Kit. It's not just a web/JS challenge.

Client dev is always changing.

I don’t think so.

Frontend is knee deep in the process of creating cargo cult devs en masse, and I’m depressed by all of this.

Yeah, I'm becoming increasingly frustrated by the flood of "anti-hype-driven-development" blog posts being praised.

The entire article could be summed up with: > Is it solving your problem, and what is the cost?

And it cuts both ways. Change for the sake of change is bad. But so is stagnation for the sake of stagnation.

Picking the best tool for the job and continuous improvement are the closest thing to universal advise in front-end land.

The "everything new is bad" rhetoric is getting exhausting.

I think the idea is to disassociate newness from improvement and only associate it with improvement when it's actually improvement. It's not wise to pick a different tool for every job, nor is it wise to only stick to one tool all the time. The fatigue imo comes from producing approximately the same output in ever more complex but not necessarily more interesting or better ways. If it does arguably provide a marked improvement, then definitely experiment and see how it might help

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 probably don't want to use fetch directly, making Headers objects using obscure methods, manually encoding query strings, and telling your HTTP client that you'd like to treat application/json as JSON and decode it. Use a library.

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.

I don't think you quite understood the point: XHR was not fetches predecessor, because few people were using XHR directly when fetch was being designed and released.

superagent was released in 2011, axios was released in 2014 (jQuery also had an HTTP client that was nice but I don't know much about it). Both of these libraries were wildly popular and do more out of the box than fetch (which came later) does.

Standards should pave cowpaths. Fetch was designed in a bubble.

I’m personally becoming frustrated by the “we draw the line at React hooks” idea - which I feel like I’m seeing repeated. Like that’s the point at which learning new concepts crosses over from useful exercise to useless extravagance.

So let me say something which is true, but totally against the spirit of this article: there should be 10x as many (!) tutorials about how to implement everything in React using hooks.

My reasoning is pretty simple. For a new learner, unless you have a compelling counter example needing classes, you should use hooks. That’s what you should start off learning and that should be your go-to.

But if you click away from this comment, right now, go to Google, and search for tutorials, despite this “best practice” advice, you’ll see an unholy mess of tutorials citing classes, with a few using hooks as though it’s some kind of new fangled, “out there” tech. I’m talking in the top 10 search results on Google’s front page. In 2020, long after the React team has introduced and explained them.

Look, it’s simple. Aside from their other advantages, hooks make it easier to learn React, with less boilerplate. As a result, it would be better if beginner tutorials were updated to use them. Most have not been.

But I see this complaint regularly, where hooks are trotted out as some kind of example of silly React maximalism. If you learned React then hooks are only going to take up like 2% of the total time budget you’ve already dedicated to learning the framework. It’s not hard, and it’s nothing like learning, say, Haskell. Using hooks to make cheap shots against overcomplicated JS frameworks is unfair, when they’re not overcomplicated and have a perfectly valid reason to exist.

Yeah hooks have such a low barrier to entry as far as ... just make a new component with hooks. There is less code, it's easy to do, anyone who has seen a class component doesn't need much of an introduction to understand it.

I've got class heavy applications that will stay class heavy, but almost all new components are hooks and they're quick to write, evaluate what is going on, and work with.

For me, the key thing about hooks is that they both make it easier to write everything idemopotently and mostly force you to write everything idemopotently, both of which are great for future code maintenance purposes.

I'm just now getting back into webdev after 3 years. Can you please recommend a good tutorial/demo using Hooks? Especially if it's using Typescript!

I strongly dislike the create-react-app project because it abstracts everything away.

For react hooks: the base results are decent, for that particular search phrase. You won't go wrong with the reactjs docs, prominently placed there.

https://reactjs.org/docs/hooks-intro.html

For react hooks typescript: sorry, I can't. This is a pretty good example of the problem, because I just searched Google's first page of results for react hooks typescript tutuorial, and they were all bad.

3 of very top results seemed to be a derivative of each other, where they presented a list of concepts, which is not really relevant in teaching you to use them.

Some of the other ones were a very slight improvement, but still not good enough that I'd feel very comfortable recommending them.

On the 1st 2 pages of results, this was the best result I found for react and typescript (not hooks), which at least addresses the topic directly with relevant code.

https://www.educative.io/blog/react-and-typescript

Also I want to call out this example for being especially ridiculous, because it titles itself as "Using React Hooks with Typescript" and then doesn't actually use any Typescript!

https://blog.usejournal.com/using-react-hooks-with-typescrip...

Anyway, this nicely illustrates the problem. I may try to write a tutorial on this myself, after seeing how bad these are. But for now, this is what's out there.

There is an excellent community resource on using React with TypeScript here:

https://github.com/typescript-cheatsheets/react-typescript-c...

Thank you! Much better answer - I'd now recommend this.

> Also I want to call out this example for being especially ridiculous, because it titles itself as "Using React Hooks with Typescript" and then doesn't actually use any Typescript!

That is all 100% valid, fully typed TypeScript

TypeScript's inference is smart enough to know that ...

    const [count, setCount] = useState(0)

... is the same as ...

    const [count, setCount] = useState<number>(0)

> I strongly dislike the create-react-app project because it abstracts everything away

That's the point of it, really. CRA sets up your build (webpack) and test runner (jest). Has nothing to do with hooks. I'd strongly suggest using it, unless you're interested in learning how all that stuff works.

Any dev worth their salt should know how to set up these tools from scratch anyway.

The day I first ejected a CRA app I had started was the day I decided to never use it again. I could not believe the sheer amount of code behind that project...

I’ve been writing reasonably complex React/ Typescript projects for years, and have never had any problems with nothing more than a few simple config files to bootstrap everything.

> Any dev worth their salt should know how to set up these tools from scratch anyway.

Yeah, I don't agree with that kind of gate keeping. I've known plenty of developers who are proficient with React, Redux, graphql, etc, but might not know where to begin when it comes to build tooling. Almost like they're totally different things.

And that's great that you trudge along with your own lesser version of create-react-app. I've personally built my own JS build toolchains and the second I used CRA I never wanted to look back.

Is it gate keeping to suggest that developers should understand their tooling? I guess if we can agree the bar we are reaching for is "proficient", then yeah, I suppose a React dev doesn't need to understand how their project is built. There is nothing wrong with "proficient"! I work with lots of "proficient" developers. Great people. Good workers.

I set the bar for myself quite a bit higher than that though. I mentor "proficient" developers because I know with a little push some of these developers can become "excellent". It's usually not for lack of ability that developers stagnate, rather, passion (relative to everything else), curiosity, and time. Sometimes I can bring that glint back into their eyes, sometimes not. Again, there is nothing wrong with that! Having a some reliable code monkeys around is, frankly, usually good for a business.

And FWIW the longer you do this the more apparent it becomes that "less is more"!

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.

I think you, unlike the writer, would seem to wish to put the time into evaluating.

The article though takes two pretty low cost / easy to use bits of tech (fetch, hooks) ... and relegates them to being "trends" without really evaluating them.

I find it interesting the blog post mentioned Kent Dodds article recommending everyone rewrite fetch. I just argued adamantly against Redux docs about writing tests being switched off of Enzyme to his library because it’s “more trendy”.

https://github.com/reduxjs/redux/pull/3708

Unfortunately, the community overruled me and the docs no longer show how to test Redux apps with enzyme. It only shows Kent’s “react testing library”. The library authors are complicit in this. Rather than showing the pros and cons of both, the trends are being pushed, leading people to falsely believe they must rewrite their whole code base in my experience.

The troubling part for me is often those creating these trends may be working on a very different type of app. When you’re writing something complicated, and the ecosystem is dominated by patterns (also preached by Kent) that work best in simpler apps like “only write integration tests” it can be frustrating.

If Kent thought enzyme promoted anti patterns he could have technically made a docs PR or just written a thin layer on top of enzyme. Now we have yet another divisive issue. Getting him early access to new react apis and officially recommending RTL in the react docs (while he sells his training videos) make it sit worse with me. It doesn’t feel like the trends are always based on the merits, it feels more like “not invented here” and “nepotism” driving some of these trends for sure.

react-testing-library and Tailwind are two tools that I use that I feel the userbase are a bit cult-like.

I don't know if it's "not invented here" syndrome so much as people use tools based on people, not always just merit.

Kent and Adam had similar self-promotion engines running with long-form free video tutorials and strong social media presence, blog posts online, etc. Perhaps this style of promotion more of a tool more than anything is effective at changing the status-quo tools?

(Not saying they're necessarily better or worse, just my observation of why they may have become popular)

Yeah a blog post titled “never do X” is going to get more clicks than “consider the trade offs before doing X” unfortunately. This leads to people following “thought leaders” and trends, instead of thinking for themselves imo

As I said in that issue, I'm not completely against having Enzyme info in that page. However, we're not obligated to have the Redux docs show information on _every_ other tool that exists in the ecosystem, and our own recommendations may change over time.

Right now, we have an entire docs page on how to use Immutable.js with Redux [0]. That page was submitted by a user who cared about Immutable.js. They took the time and effort to write it, and the information is useful.

However, at this point we now actively recommend _against_ using Immutable.js [1], and _do_ recommend using Immer [2]. So, that docs page will be removed in the near future, because it now goes against our recommendations.

As I said in that thread, I personally would not recommend Enzyme at this point. Doesn't mean it's useless, or that people shouldn't use it at all, but it's not something I would use or tell people to use. Given the focus of that specific Redux testing docs page, I also don't see a _need_ to show both methods at once.

I agree that the ecosystem shouldn't just chase new shiny, but there's also a lot to be said for actually keeping docs and recommendations up to date. I understand your concern in this particular case, but it also feels like you're extrapolating rather broadly from one specific issue.

It's also the case that sometimes creating _new_ tools is the right answer. Yarn's release forced NPM to wake up from stagnation. There were dozens of Flux libraries when Redux came out. In the case of RTL, Kent created something because he saw a need, the community has seen that it's useful, and he's well within his rights to promote the tool that he created.

[0] https://redux.js.org/recipes/using-immutablejs-with-redux

[1] https://redux.js.org/style-guide/style-guide#use-plain-javas...

[2] https://redux.js.org/style-guide/style-guide#use-immer-for-w...

Really all I want is instructions on wrapping the component under test in the redux provider that don’t presume I’m using Kent’s library. It should show how to wrap, not how to call RTLs proprietary helper function.

I’m not arguing that you’re violating anyone’s “rights” here, I’m arguing some of these trends feel like nepotism. The fact Redux and React are seemingly abandoning official support of Enzyme, after years of recommending it, after some of its users have written 100s of thousands of tests, is my issue, and I feel like is directly related the article about "trends" OP posted about.

You've been on this crusade for over a year. There's a thread on reddit between you and @acemarke from May 21, 2019 on this exact topic.

In that time, have you stopped to consider that perhaps the incredibly narrow "legacy maintenance" use case you've been bandying about (which isn't enough to justify dedicated documentation space in a project that isn't enzyme) and your overly insulting insinuations about the authors of popular libraries are not a winning combination?

I looked through Your comments. Seems like the compromise You suggested didn't go down well. I understand the maintainers POV - just avoid the flamewars. I liked Your soluton of weighing pros and cons of the different libraries. Maybe the next step would be to create a PR to add enzyme back as a suggested alternative and just build of off this PR?

Already did exactly that FYI

Shiny new thing (SNT) comes along, sales people and thought leaders get excited about SNT because they can sell it, everyone piles on as SNT picks up more and more hype, SNT falls apart as soon as it hits real world use cases, sales people and thought leaders start looking for new SNT and the cycle repeats.

I can not stop the cycle. You can not stop the cycle. All we can do is notice it and let it pass and hope some SNT will eventually be useful instead of pure hype. Oh, and also, avoid joining any cults: https://www.infoworld.com/article/3440104/10-software-develo....

That is a great article!

Thanks!

BTW: I did write a bit about this phenomenon, here: https://medium.com/chrismarshallny/concrete-galoshes-a5798a5... (Scroll down to "It's Not An Either/Or Choice")

From a developer perspective, changes in frontend web development have been pretty dramatic: CSS Grid / Flexbox, React, WASM, extensions to the web API, lots of new JS features, countless frameworks, plugins and build tools more homogeneity between browsers. There is always lots of change and excitement.

I wonder how much of that "innovation" really makes a difference to users. As a programmer, I get a bit cynical about having 50 ways to do the exact same thing. What is possible today that was very hard to do 10 years ago in web dev land?

If we think about users first, maybe we can feel a bit less guilty of not having deployed React Hooks to prod yet?

> I wonder how much of that "innovation" really makes a difference to users.

It makes a huge difference in terms of usability. Some sites are just plain awful to experience now. Not to mention battery hogs on mobile.

in the negative, I agree. I see all the hype around React but when I use Facebook.com I am thoroughly underwhelmed.

Eh? You can't "tell" what framework a site is using just by interacting with the site. What you see is what the designers decided. A better proxy, though weak, would be the number of UI bugs you encounter. The best metric would require you to have insider knowledge, to see how much work is saved by reusing components and writing them declaratively.

You can usually tell react based things from the poor performance and bad handling of network conditions.

Nah, this is just because tutorials for these new frameworks does not include network handling.

It's far more easier to put todo list app or counter app to your blogs.

Really, we need people to come together to build a proper knowledge base rather than fighting for influence with hype and easy blog posts

Might just be a firefox thing, or a symptom of my ad-blocker, but facebook and the reddit redesign are both pretty terrible performance wise. The thingiverse redesign seems performant though so I don't know.

When a website loads displaying a spinner or a splash screen, you know it was made with some heavy framework, it's going to be slow, it's going to break a number of estabilished web UX paradigms (such as scrolling, history or the ability to open links in new tabs) and your phone will feel warm in your hand. You just know.

> What is possible today that was very hard to do 10 years ago in web dev land?

Declaratively writing components and reusing behavior (e.g., hooks) across components/applications was basically impossible with the tools of 10 years ago. The benefit to the user is more stable interfaces and a faster release rate.

> benefit to the user is more stable interfaces

Doubt. Websites are constantly redesigning their interfaces so that they can use the latest trendy technology.

Why blame developers? Why not the designers or product managers?

Is that the fault of the frameworks for existing? That's like saying we'd be better off if we didn't have so many programming languages.

I totally disagree.

Reusable components were already there using jquery plugins. Everyone used them and they were easy to use and easy to install. They were deployed as a single file, with optional CSS.

Try writing a reusable component now. You have to target all major frameworks and tooling.

I think you may be conflating components and good old fashioned libraries. You can certainly make a component into a library but that's not their main use case. Their main use-case is for organization and reusability within a singular codebase.

I write reusable components all the time inside my codebases. I never have to target anything except the stack I'm using for my project.

Components as jQuery plugins aren’t encapsulated or easily composable. What do you do if two plugins used the same namespace or class names? How would you put one component inside another?

In Javascript, maybe, but frameworks like WebForms already had 1st-party components (called "user controls") back in the early 2000s. Granted, it was server-side only.

Hooks are a tough one (they're very specific to reactive frameworks), but we did have other kinds of abstractions that provided similar benefits.

Flexbox certainly allows me to accomplish things faster / in ways I couldn't (or wasn't going to hack together with tables) before.

Is that for the user, I don't think they care, but they do get changes faster / more features because I'm not pulling my hair out over tables....

Analogy: Like looking at stock prices. As javascript developers, we see all the tiny changes every day and it can feel overwhelming. However, looking at with a long-term view, there are only a few major spikes and it seems to be nicely growing.

I want to break this list of things down a bit;

CSS Grid / Flexbox - Flexbox was defined in 2009, and was added to browsers about 10 years ago and iterated since. It was literally in the first public version of Chrome. This is not some new tech that's blindsided everyone. Grid is a couple of years old.

React - First released 7 years ago and iterated since. Reasonably mainstream for 5 years. That's not a very dramatic change.

WASM - Around for a few years now in browsers but tooling for different languages is still patchy. Entirely unnecessary for 99.9% of web development. Most people are still in the "use it because it's cool" phase rather than "use it because it's actually useful".

extensions to the web API - Various, obviously. Can't really argue this point.

lots of new JS features - Various, but not actually very fast moving with new features. Most things are made available earlier through transpilers, so you can use a feature without it being in mainstream JS engines if you want to. Can't really blame the web if you make that choice though.

countless frameworks - You don't need to learn them all. Pick any number to use between zero and all of them depending on how much time you want to spend learning frameworks. Again, this is a choice, and if you're finding it overwhelming it's because you picked the wrong number of frameworks to learn.

plugins and build tools - Same answer again. Pick something and learn it. Update your skills every few years if you think your tooling is holding you back.

more homogeneity between browsers - This reduces complexity. To complain about that in a list of things to taking up your time is weird.

The web isn't that fast moving. I completely agree with your point about focusing on things that benefit the user though. I would argue that frameworks and build tools that enable me to iterate features faster do that though.

There is always some lag when it comes to being safe to use certain features, while it's true that flexbox is quite old, consider that at the time it was released many people still had to support browsers like IE6/7.

There was also a problem that the spec changed so at one point you had to support two versions, which put a lot of people off adopting it for a long time. The point is still that this stuff isn't new though. Browsers don't change very quickly, especially for the fundamental building blocks of how you get a website on a screen.

I would also argue in direct contrast to the author that it makes a difference in terms of keeping interest. The new thing to learn in a dynamic ever changing landscape is also a way of staving off monotony.

I legitimately don't care about React hooks though one way or another and it's a bizarre thing to draw a line at.

As a software developer I consider the most important part of my job to be evaluating new tools and techniques. This craft is in its infancy and our profession borders on complete incompetence when it comes to predictably building usable tools at a reasonable budget. Nobody can afford to miss out on productivity enhancements and that means following trends, but with a critical eye. If someone is "tired" of this process it might be time to consider another profession.

And a key component of that is evaluating not learning the new framework.

It's a meta analysis on the new tech that can be done in less than a day, rather than spending weeks mastering it just to determine if it fits in your tech stack.

Focus is everything. The universe is too infinite to learn everything.

> As a software developer I consider the most important part of my job to be evaluating new tools and techniques.

Really? I would argue it’s building software.

> This craft is in its infancy

We’ve been building software since ... dunno ... 1950s? 1960s?

> our profession borders on complete incompetence when it comes to predictably building usable tools at a reasonable budget

This is probably true, but I suspect chasing new tools isn’t the solution. I’ve seen a lot of very much with it development teams fail at building stuff because they couldn’t get their shiny new stuff to work predictably.

> If someone is "tired" of this process it might be time to consider another profession.

On the front end, yes, it’s probably par for the course. I suspect it’s because front end development is even more removed from rigorous engineering practice than back end development.

On the back end, however, lots of stuff is still built in Java and C(++) and it all works reasonably well.

It’s just not very exciting.

The user does care. At a previous company we started migrating from angular to vue. Vue was so fast that those parts would be completely rendered and the rest would be white. It was also snappy.

Of course, one has to be mindful about the transition. You cannot stop business, but you can take a little extra time whenever there's need to modify a section to improve quality (both code and ui). Actually that's why we chose vue, it allowed to a progressive migration out of angular.

BTW, someone had the "great" idea of not using a framework for an internal admin portal. It turned immediately into a huge ball of mud.

> BTW, someone had the "great" idea of not using a framework for an internal admin portal. It turned immediately into a huge ball of mud.

It's never the case that you "don't use a framework" for something like that. You'll use a framework, alright. The choice is between using something well-built based on best practises as we know them, or... building it yourself. Other than in very rare circumstances, I fail to see the point of reinventing that wheel. UI frameworks (web front-end or not) are a quagmire of edge cases and other infinite time sinks.

On the react bandwagon for almost 5 years now and haven’t regretted it a single day. Started using it because it allowed me to build d3-type data visualisations but with way more flexibility in terms of hierarchy and grouping of DOM elements in what for me felt like a very intuitive format of components and JSX. So I would say thrust your own judgement when considering which tools! Not all trends are pure hype, there might be something real behind it :)

In my opinion, React is one of the few libraries out there where the gains from using it is much larger than the effort needed to learn it. It has a relatively small API, more so now that you can get a lot done with just function components. In return, once you grok the whole "components as a function of state" concept, designing data models and designing app components becomes very simple.

I really like react, and I'm glad to see other environments adopting a React-like approach to UI development (Apple's SwiftUI and Android's Jetpack Compose, to name two)

Almost every time it is better to invest in learning your framework well and learning patterns to work around framework's issues rather than learning a new framework.

First, it is naive to think the new framework does not have any problems. Marketing would like you to think everything is perfect but if that ever happened, why do we have new frameworks all the time?

Second, you will pay with decreased productivity while you are learning the new framework and you are not guaranteed to be more productive than with the old framework.

Third, due to decreased initial productivity, even if you potentially get more productive with new framework, it is going to take time to realize any benefits. If you are switching the framework too frequently you are cutting yourself off from the benefits.

I forgot to mention there is actually one reason to learn new frameworks and it is to educate yourself on the tools that are available. If you do it correctly you can get 90% benefits with 10% effort.

Just don't decide to build your new production application with a framework that you don't know or did little more than hello world.

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 that's about it.

Meanwhile in React every year there's this new convention that isn't explicitly mandatory, but for some reason "cooler" than the previous one.

All this won't matter once the next gen compiler-frameworks reach maturity. My take is that hooks are React's swan song.

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 Wordpress. Web tech confuses me thoroughly, and I read HN all day.

> As an outsider, I feel like the Model-T does too much (an internal combustion engine? Aren't current horses enough to carry our wagons?)

If you don't need a virtual DOM, nobody will judge you for not having one. But once you really feel 'behind the wheel' of a framework like react or vue, it's hard to go back. Not only is it easier to hack out something quick over a weekend, it's also more suitable for collaborating large, complex applications.

> 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.

Not true.

litElement (used by Polymer) uses tagged template literals and no vdom.

You're right, LitElement and Polymer don't use a VDOM. [0][1]

I don't think Polymer 3 uses LitElement though. Seems to say they're highly compatible, but that Polymer 3 uses PolymerElement, not LitElement. [2]

[0] https://lit-html.polymer-project.org/

[1] https://www.infoq.com/news/2019/06/polymer-lit-html-element-...

[2] https://github.com/Polymer/polymer

Polymer 3 and LitElement are separate projects by the same team. LitElement is the successor to Polymer 3. It would have been named Polymer 4, but it's quite different.

They're highly compatible because they are both web components-based. There's no "framework" that creates component instances, the browser does that when it sees the custom elements. So each component is in control of its own lifecycle and rendering. You can have a Polymer element use LitElements (or Stencil, or Lightening, etc) or vice-versa.

How does it work with data-binding? Isn't that a Polymer-specific feature, rather than a feature of Web Components?

As mentioned, LitElement doesn't use a vdom, but neither does Angular, Ember/Glimmer, Solid, incremental-dom, and many others.

VDOM diffing is pretty slow, memory intensive, and unnecessary. It's very good it's not the only game in town.

Thanks, I see I'm mistaken. Could've sworn Angular was VDOM-based, but no. [0]

[0] https://stackoverflow.com/a/39739739/

> Since its introduction in late 2016 Angular 2+ has had no major changes

As someone who has used Angular 2 since beta, I can tell you, it's been a bumpy ride nonetheless.

> its target audience - large companies making large-scale applications - is fairly conservative

React was built for Facebook, which is a large company building a large-scale application.

> All this won't matter once the next gen compiler-frameworks reach maturity.

And here I am using HTML and CSS with tiny sprinkles of JS for most websites, and it's working just fine, and has been for many years.

Personally, I hope that server-side rendering will be the new ~old~ trend.

> As someone who has used Angular 2 since beta, I can tell you, it's been a bumpy ride nonetheless.

Oh yeah. I remember the "let's just apply the good parts of AngularJS here and there" in v4-6.

"React was built for Facebook, which is a large company building a large-scale application."

One large scale application, which is not enough to create stable conventions that are badly needed in a framework that's supposed to be used in multiple such projects done by very different organisations.

Personally, I hope that server-side rendering will be the new ~old~ trend.

Users don't tolerate the inherent delays caused by this approach anymore.

All those hoops current frameworks are jumping through so that we can eat the cake and have it too are there because of this.

> Users don't tolerate the inherent delays caused by this approach anymore.

Well, I certainly also do not tolerate the delays in contemporary React sites either. Take Reddit for example, which used to be lightning fast when it was mostly serverside, which now is painfully slow, especially on mobile.

Yep, I agree. Was just talking to my wife about Reddit. It's so slow now, especially on mobile. The page constantly crashes on my Android phone and they always recommend the app. No thanks.

Today is the day I decided to switch to old reddit... My Mac can run garageband and vsc and 40 chrome tabs at once, but as soon as I click a front page Reddit link, that modal is like pouring sludge into my computer.

> Users don't tolerate the inherent delays caused by this approach anymore.

Well, I'm from Germany, but have a 6-y/o Android phone and live in a rural area with poor EDGE connectivity (~50kb/s). Most "modern" websites don't load/work for me.

From my personal experience, there's quite a few people now saying that their computing devices are getting faster and faster every year whereas the majority of websites, uh, webapps are seemingly getting slower each year...

This is also not just a problem with mobile and poor connectivity. Here's an example from my high-powered desktop work-station with a 100 mbits: When I open https://github.com/, my repositories (on the left) are server-rendered and shown instantly as the site is loaded, which usually happens in under 1s. The activity feed in the middle is rendered asynchronously on the client. It usually takes around 3-6s to finish rendering on my machine (while there is space for 5-8 activity feed items on my screen).

Optimizing SPAs is notoriously hard. You don't really have to optimize HTML.

> As someone who has used Angular 2 since beta, I can tell you, it's been a bumpy ride nonetheless.

I can second this - I've been working on a variety of Angular apps in an enterprise environment. It's worked fine and the "batteries included" has worked for my org, but it has definitely been a bumpy ride to get from beta to 9 with plenty of changes along the way.

> And here I am using HTML and CSS with tiny sprinkles of JS for most websites, and it's working just fine, and has been for many years.

This has been my favorite setup at work - pick "boring" tech like Django/Flask or Spring Boot and then sprinkle in some Javascript for highly interactive forms/pieces (React or Vue if needed).

Not just JS. JS is an enormous ecosystem, so it shows this issue, but pretty much all tech (and other industries, as well), have the same problems.

We can have problems when folks start suddenly painting "The New Thing™" over classic designs and architectures.

In my experience, that's even worse than rewriting everything.

Also, it can become a requirement for hiring, because some manager, or their "top tech," have suddenly latched onto a technique/technology they encountered at a conference.

I remember applying at a company, and they gave me a "take-home" test.

Fair 'nuff. I like these better than the silly "draw spunky" tests that are so en vogue, these days.

They said I needed to use a certain third-party library, and use MVVM, or PM. That made no sense to me. It would result in the dependency being "married" to the application.

In my response, I used dependency injection to add the third-party library they wanted me to use. I wrote the app in about three hours, and incorporated the library (which is a great library, but one I had never used before). I delivered an app that met their specs -very quickly-, and of remarkably high quality. It also featured the ability to easily "swap out" the dependency (which is a huge reason for using dependency injection).

Dependency Injection is not a new thing. I think the name may be a bit new, but it's a fairly classic pattern that is a great way to encapsulate dependencies (which is something I always do).

It Freaked. Them. Out. I have no idea why. They literally shredded my résumé, at that point.

I have my suspicions why. I think they found out something else about me during the process (my age), and that may have been a contributing factor.

I once worked with a group of people that were afraid of makefiles. I doubt it was your age. People are always afraid of things that are unfamiliar. This applies to snakes and spiders just as much as it applies to programming languages and associated technologies.

> I doubt it was your age.

Wish I could share your confidence, but I have run face-first into this phenomenon.

[...removed some stuff that I don't feel like backing up...]

We are an unpopular bunch. It used to get me quite upset, but I’ve learned to make it quite clear that I am no youngster; right up front. Avoids stuff like what I mentioned.

Really? Do you have specific examples. In my experience hacker news tends to be much more friendly and sympathetic towards older programmers.

I'll withdraw the post (rather than spend a bunch of time, hunting down comments that just get me depressed), but the tide may be turning.

Now that the VC money may not be as easy to get as it once was, there may be a bit of a demand for software that ships, as opposed to glossy slide decks.

Us old farts ain't so bad at that.

Indeed. Focus on fundamentals never hurts.

> and use MVVM, or PM.

PM?

Presentation Manager.

Sorry. That was the term I learned, many moons ago. I learned it as a Microsoft pattern, and I used it to create Web-focused SDKs.

The more familiar one is MVP.

Really, if you are talking about creating a UIKit or AppKit app, you should use good old MVC, even though it’s “square.”

That’s because it is the pattern the toolkit was specifically designed to implement, and other models actually introduce dangerous departures from the norm.

SwiftUI and React are much better for MVVM or MVP.

Let me make the argument against axios.

Even if you are happy, your users may not. Axios (btw still on version 0.x despite being one of the older javascript packages, means it can introduce breaking changes without any warning, think about that) adds 4.4kB (minified+gzipped) to your bundle. Do that a few times and you have hundreds of kB of additional code your users don't need to download (and execute!). If all you need to GET or POST, without any special needs, the w3c fetch function is definitely better for your users.

> adds 4.4kB (minified+gzipped) to your bundle ... Do that a few times and you have hundreds of kB of additional code your users don't need to download (and execute!)

A few times? You're suggesting doing that 50 or 100 times.

Adding 4.4kb an actual few times is meaningless for the end user.

axios is actually not that bad, in terms of size. There are definitely worse dependencies you can have. However to me the fact that someone decided to use axios in the frontend makes me cautious about everything else. Are they perhaps also using lodash (70kB) for just that one function? Or are they using ramda and lodash at the same time (or any other two packages that contain duplicate functionality)?

Don't get me wrong, there are valid reasons to use axios, and I don't have a problem if you communicate those clearly. But I believe few developers make a conscious decision about the tradeoffs, most developers simply dgaf.

My argument for using axios is developer ergonomics. There are a few libraries that I use both in the frontend and the backend, for which I gladly accept the increased bundle size: axios, lodash, moment, Q. My users get the benefit in me being able to ship features faster because I don't have to constantly keep up with which feature ships in which browser version etc. I also found the fetch API horrendous to use. It's a tradeoff I'm willing to make.

Do you take on the entire of Lodash as a dependency?

If so, do you use any of the Lodash features not described here?[0]

If you use more than described, or if a specific Lodash feature is more performant, you can selectively import[1].

[0] https://github.com/you-dont-need/You-Dont-Need-Lodash-Unders...

[1] https://www.npmjs.com/search?q=keywords:lodash-modularized

When you found the fetch API horrendous were you using async/await? They make it not horrendous.

You don't have to keep up with which feature ships in which browser; that's what browserslist is for. https://github.com/facebook/create-react-app/blob/master/pac...

In the end fetch was supposed to supersede all these libraries. Unfortunately in cases like this seems like Node.js, and JavaScripts's lack of standard library really shows. Every developer will use whatever either they encounter first because they don't feel like learning a new shiny library or whatever is the most comfortable and maybe not right. NPM has its positives - discoveriblity being one for sure but also its drawbacks - million ways of accomplishing the same thing.

Axios after fetch being standard everywhere starts to feel like jQuery after document.querySelectorAll being available everywhere.

> the w3c fetch function is definitely better for your users

Sure, unless your users are desktop IE11 users. They won't care about 4.4kb but they'll definitely care about a broken page :)

No one I know has moved away from React as the base of their front-end UI for the last three years.

Maybe I'm out of touch? It doesn't seem like the churn is as much of an issue.

The underlying problems are mainly psychological in my opinion. FOMO (fear of missing out) and attaching your identity to a language or tech stack.

People get so religiously tied to their technology sometimes that they cannot change without changing themselves.

It's the same case with the fractured ecosystem of Linux distros, there's tonnes of them! From the outside it looks overwhelming as all these projects are concurrently developing similar things. But the benefits are a rich and diverse ecosystem meeting a range of needs.

Imagine if everyone used one language like Java and never created new packages... and simply maintained existing libraries... that's not a world I'd like developing in...

I agree totally with this - but if you want to get a new job, you have no choice but to follow the latest javascript framework, because thats who's hiring. They want to build their new doodad in the latest doodad - react, Vue, ...., because thats what their google turned up thats the latest and greatest.

Further if you're looking at getting your next job, you'll make your next project using the latest doodad, because thats who's hiring when you finish this project (as long as your project doesn't take to long and you miss the boat - you can probably quit midway, I suppose)

Javascript has always gone through hype cycles.

Interestingly, it appears to be somewhat correlated with market manias and peaks near the tops of markets.

Generally, following industry trends appears to be good for individual careers but bad for code bases (on average, but with occasional big payoffs.)

Since I own my career but signed away all rights to the code I write as a condition of employment I'm OK with this trade-off.

Agreed entirely. Now all you have to do is convince my team of this without being bombarded with the platitude of "don't reinvent the wheel."

Have followed the trends and I now know Ember, Angular(both legacy and new), Vue(with and without typescript), and React(both classes and hooks). I've also used Svelte, and Stencil JS in my personal projects. In addition, I've also dived headfirst into GraphQL and Typescript pretty heavily lately.

Do I regret investing time in learning any of those frameworks or technologies?

Not at all. It was fun and interesting at the time I learned something different from each of them. Perhaps the most valuable thing I learned was that it is worthwhile to evaluate new technologies and to continue learning new things.

Does it devalue me as an Engineer to learn many things as opposed to becoming an expert in a single tech stack?

Much the opposite. A lot of the underlying principles and architecture remain the same and yet, I find each framework offers something new. Whether it's questioning some convention, or approaching a problem with a different paradigm, or just being heavily opinionated, I feel like I gained some value from each of these and had fun while doing so.

The downside probably being that an employer paid you during that time of learning and didn't get much work product out of it.

Learning for the sake of learning is an infinite endeavour.

I try to practice strategic learning - learning skills/frameworks/topics that will have a high likelihood of being used in the course of my current project.

There's just so so much out there... focus is everything.

I am actually paid by my employer to do 5 hours of training per week. It's required and I am allowed to study anything I want, whether it's a new framework or a self-improvement book.

I usually spend that time studying something that I think may be useful or related to my job but I have been encouraged to explore. My employer is a big believer that innovation comes from exploration.

As you pointed out, it is an infinite endeavor. I'm okay with that. If I just stuck with the current technologies that were used when I first came in, we'd probably still be using jQuery and .ERB templates. Instead I personally pushed for using new technologies and my team is personally responsible for introducing Vue, Typescript, and GraphQL to our stack among other technologies.

One problem I have with that hype cycle diagram is that it appears to show that all technologies that get a lot of hype will eventually even out and get good adoption once they go through some growing pains.

Realistically though a lot of new tech will get into the hype stage and then everyone will realise that is in fact no good or just disappear for some other reason.

People see that diagram and think it doesn't matter if you jump in at the hype stage because eventually this tech will become mainstream, when a lot of the time that graph just drops to zero after the hype stage.

Agreed. I approach it more from a "Draw a line in the sand" perspective.

We start a project, pick our stack, pick framework versions and features to use. And then we code for a year using those decisions. We do watch to see what new things come up over the course of a year. We also learn lessons from our choices. When our year is over, we talk about new things, evaluate them, decide what we want to adopt, and move the line in the sand to include the changes that make sense. Then... for another year, stay where we are.

One thing that is, unfortunately, a bit neglected in the post: dependencies deprecate and JS has a lot of them.

One npm audit shows a lot of vulnerabilities for the long trail of dependencies in my Angular 4 app. My web app uses Hapi 17 and many plugins have changed APIs in the more recent version.

This fact alone leads to many heavy refactorings and even rewrites.

As a solo dev, I can only try to reduce dependencies (taking a massive hit on productivity) or keep up with the newest way to write stuff in my former self’s framework of choice.

This lustrates a problem I've encountered on a few recent projects - we are suffering an embarrassment of riches when it comes to front end technology.

I found myself slipping in the architect role on a few recent projects with various employers and being forced to make the call on which front end framework to use. The problem is that there are so many to choose from and it very hard to predict what you will need in terms of features from your chosen framework six months or longer after making your decision.

Plus, your fellow devs will probably be arguing with you over which one is better based on their experience. All the emails and messages pointing me to various websites claiming React/Vue/Angular etc is best with stats and graphs I really don't have to the time to get my head around.

It's that fear of making the wrong choice that bothers me. The idea a year down the line the front end seems a bit sluggish and someone then points out that {other_framework} would be flying with the same workload.

Don't get me wrong choice is good, but with so much going on in the world of front-end right now coupled with all the hype and shouts about which is best it is hard to just pick one and run with it. Especially in the metric driven world we live in where a manager who doesn't get tech will berate you for choosing the wrong framework or wonder why you aren't buying in the latest hyped up framework.

That being said my preference is to use a framework to prototype and then convert to plain old JS where possible.

I think Software Engineers' role is to pick the right tool for the job - taking into account all the advantages and drawbacks of each one. Following the trends is a good way of knowing if any of the drawbacks of the previous tools were alleviated in the new ones. Of course the refactoring time must also be a deciding factor in a switch - most of the times it won't be worth it. I think what the author meant was don't follow the JS treds blindly.

Let's reverse the question: if you didn't follow the trends, were a decision maker, and wanted to bet on a frontend "framework" for the next 10+ years for a greenfield (or full rewrite) project. What would you chose in 2020 ?

From where I stand, it seems vue or react aren't going away anytime soon. But the same could be said of angular, ember, and probably many others. What would you chose and why ?

The problem to me isn't so much hype trains for this or that framework but that, as a Front-Ender myself, many Front-End Devs don't know how to do anything without a framework; the person I report to, the Front-End Manager, had been mucking about with jQuery for 15 years straight and didn't know about CSS animations.

I was able to work alongside a very saavy consultant for a year when I started out who I feel pointed me in the right direction wrt coding 'from the problem itself', if you will, but they'd have me do interviews and I'd be astounded at what applicants didn't know or grasp who'd been doin this front-end thing much longer than I.

If there were better solution design pedagogy instead of React's original marketing of "We know better about efficient DOM updates than you" I think you'd see substantially less reliance on these types of things, and probably a lot less unmaintainable code disguised as maintainable because it uses "a framework".

I'm teaching frontend development to designers right now and after almost a semester, I have the feeling I have to cut out much more concepts.

There are just too many ways to do things to teach a beginner in one semester and they just should be able to create basic prototypes anyway.

Serious question, why do they need to know anything about creating prototypes?

The argumentation went like:

We did design projects for companies and showed them our ideas as mock images and they didn't like them.

We then implemented the exact same designs as prototypical apps, they clicked around in it and loved it.

Oh, that makes sense. I thought you meant Javascript object prototypes!

You can mock user interactions in Sketch and Figma.

I don't use these apps.

It were design teachers that hired me, so I guess they knew and still wanted their students to learn a bit programming.

I think either vanilla js, or the other route, a full blown batteries included, like Visual Basic 6 was for windows development. Either abstract away nothing, or everything.

In the middle, is developing with a framework. The problem is you have to know the language + the peculiarities of the framework. New frameworks and "features" happen on too short a timeframe. And, frankly, it costs too little to just invent a new framework. So, 10000 frameworks.

There is a mental cost that increases exponentially with every layer of abstraction. When people have to post questions about why they can't understand such "features" of panacea x , that's the problem.

Been a while for me, but I agree

But when I spent a year doing Javascript I found that in JQuery there were a lot of shortcuts I was writing my self to lower the RSI from typing long Javascript statements.

Beyond that there is nothing useful in JS frame works. They make simple things easy and the complicated stuff (which is design and logic) stays hard.

I just wish more developers would stop trying to improve their products by chasing the newest, coolest standard, and instead work on fixing bugs. But that's not en vogue these days.

I don't use frameworks, and have found more efficient, better organized, more native ways of doing everything that frameworks do.

It took a lot of time and effort and being a stick in the mud, but the trick was ultimately an algorithm/abstraction I call source derivation (SDx).

Here's a simple example of the algorithm: https://codepen.io/SephReed/pen/gOaeQLv

Unfortunately we work with others and sometimes powerless in this. I worked in 2 front-end teams both using redux inherited from the early stage of the projects. In both cases the marority of the team don't like it but we're too deep in it to get out without affecting our roadmap. Another case I had to talk a college into not using graphql just because he could, felt like a jerk.

this is a fight a developer alone cannot win. my first job after college was in a company that created a software to manage industrial production. they were on their third refactor of their frontend. first was polymer?, then angular and now they were trying vue. I spent a lot of time and energy trying to convince them to write they own framework, if they like frameworks so bad. funny story, that's how I built FOS, the framework I use on my website. anyway, I was hired by some other company and don't know the end of the story there, but I'll bet they went with vue, just to rewrite the whole thing in react in a couple of months

I recently started a new app using Material UI, after doing web dev since pre-CSS days. I'm trying to grok CSS-in-JS, and it's only been a few weeks but it still feels so completely unneccessary.

tl;dr: use TypeScript, but don't worry so much about hooks.

---

I recently switched my JS + PureComponent mobile app to TypeScript and FC Hooks. I felt motivated to do so because:

- You cannot use hooks in PureComponent render(). The two modalities do not play nice together.

- Many of the libraries I use like react-spring and react-navigation have fully embraced hooks, sometimes without an HOC equivalent. So I felt forced to also embrace hooks or write complicated wrappers to facilitate them, for example new component lifecycle methods (e.g. componentDidFocus).

Some things I noticed...

1. TypeScript is amazing. Combined with Intellisense it has given me coding superpowers. I can write code faster and with dramatically more confidence.

2. You can incrementally shift your JS app to use TypeScript. You can even write type declarations for your JS code without rewriting it in TS. Most of your favorite libraries already have such type definitions (see DefinitelyTyped).

3. Hooks require a significantly different mental model than PureComponent. It feels horribly wasteful at first but apparently relies heavily on JS interpreter optimizations and memoization to achieve superior FMP performance[1]. My app feels noticeably snappier now, but it took a good bit of tuning to correct issues introduced during the port.

4. It IS indeed possible to write a functional wrapper that provides otherwise unavailable hook support for your Component or PureComponent. The tricky part is that you need to use a ref to invoke lifecycle methods on your wrapped component[2].

In retrospect I think I would recommend against porting an existing React project to hooks. However I would absolutely recommend porting to TypeScript, even if you do so slowly and incrementally.

1. https://medium.com/@dan_abramov/this-benchmark-is-indeed-fla...

2. https://medium.com/reactnative/custom-lifecycle-methods-in-r...

I was initially kind of worried about TS. It has kind of a high barrier to entry with linter settings, typescript-specific setting, solving how to compile your code easily, learning the new syntax, etc. etc.

I literally spent like an hour reading up on it and learning it, and I realized I never want to go back to a plain old JS. TS feels way closer to Java than to JavaScript, with its own quirks and way of functioning of course. The barrier of entry seems perceived, but not really that big of a deal.

I wonder what are the cons of TS.

The number one pain point for me is that sometimes time is wasted tracking TS error or bugs than actually solving my problem.

To me I sometimes get too obsesded with types and try to wrire clever ergonomic type inference. Usally I stop when I realize the types are double loc comparing to the actual implementation or what I was trying to do was impossible. It can be a drain on productivity if you're like me.

Coming from Java background, I personally have no such problem. Is JS your only/main language? Maybe JS + Python?

Not really I played around with multiple things. Came from a Java background too. I'm in the process of trying to get to a better language actually, like scala or F#. Java seems too limited and typescript while can do a lot of things is no scala and not as clean as F#.

> TS feels way closer to Java than to JavaScript

You and I clearly have different understandings of Java, JS, and/or TS. Typescript's structural typing feels like the opposite end of the spectrum from Java's nominal types.

> Typescript's structural typing feels like the opposite end of the spectrum from Java's nominal types.

Be that as it may, I said nothing about type systems. I said that TS feels closer to Java than it does to JS. Seeing as JS has no type system, I fail to see your argument.

> Be that as it may, I said nothing about type systems.

Typescript is nothing more and nothing less than a language that adds static typing to Javascript. Any discussion about how Typescript changes the feel of Javascript is a discussion about type systems.

> Seeing as JS has no type system, I fail to see your argument.

Javascript absolutely has a type system. It's not static, and there are lots and lots and lots and frankly too many ways to automatically coerce types, but it definitely has a type system.

"I wonder what are the cons of "TS.

I would like to know too. Sounds too good to be true....

I remember 2016 as the year my peers started telling me that jquery was evil. Also a year of switching from angular to React/redux

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.

Depends if you want your code to be maintainable into the future with other teams.

If you do not care about the future (which os OK in some contexts) then you are correct

Stay curious, try new things! Party of being a developer is exploration and discovery. Do not discourage!

Some days I miss using prototype.js and script.aculo.us

Article very empty of any real, tangible advice.

What do these have to do with managing fads?

I remember having a coworker who was "learning clojure". That guy did more damage than could even be imagined.

A while back, I got tired of dealing with the mess of Gatsby, Next.js, and Vuepress, so I made my own static site generator in Python.

I don't want a GraphQL database for my static site. I just want something to template out my site's boilerplate, and I don't want to deal with Webpack speed, or lack thereof. One file, ~200 loc, and I understand all of it.

The tentatively named Zhi works fast enough for full rebuilds triggered by fswatch. It does one thing and does it well:

  fswatch -0 -e .venv -e out . | xargs -0 zhi build

If there's interest in a simple, understandable Jinja-based static site generator, I can clean it up and release it: https://github.com/0az/zhi (empty repo).

If you didn't like Gatsby, why not simply use one of the tens of simpler static generators? Hugo is extremely popular, but also just Jekyll or something similar. You won't understand the whole codebase, most likely, but on a user level, it's literally just a "put a markdown file in this directory" type of a thing for most of these generators...

Reply on news.ycombinator.com