Hacker News Reader

Comment by ricardobeat | Hacker News Reader

You covered the frameworks, but a lot of the feeling comes from the tooling and library ecosystem. For example, a recap of the last 10 years:

- grunt / broccoli / gulp / browserify / webpack / metro / esbuild / parcel / swc / turborepo / bun

- flummox / redux / unstated / mobx / mobx-state-tree / xstate / apollo / apollo-link-state / swr / react-query / zustand / recoil / jotai

And this is just within React, and off the top of my head. Then you add all the ECMAScript versions, browser feature churn, node.js, npm/yarn, immutability, classes, functional components, hooks, fiber, the list goes on and on.

View on HN

I've used the same React tech as the basis for most projects for 6 years now. Webpack, Redux, Yarn, React Router, all still popular and maintained. We even used hooks for functional components since then, through the "recompose" library, so there wasn't a big paradigm shift for us.

Anyone who feels compelled to jump from one unproven state management library or bundler to another, in serious projects, is just not doing their due diligence.

> I've used the same React tech as the basis for most projects for 6 years now. Webpack, Redux, Yarn, React Router, all still popular and maintained. We even used hooks for functional components since then, through the "recompose" library, so there wasn't a big paradigm shift for us.

Have you worked at different companies or contributed to different OSS projects in those 6 years? If you have, and they've all been set up exactly the same as what you mentioned, that's rare, but great. I think most people's qualms on the amount of different frontend tooling is based on the fact that almost every company or OSS maintainer takes different approaches to accomplish essentially the same thing.

Yes to both, and I can't say many projects followed a radically different approach, at least without good reason. Webpack and Redux for example are many times more common than something like Parcel or Jotai, so it's rare to encounter many of these alternatives in one project.

> that's rare, but great

Not OP. At a big tech company. As far as I can tell neither myself nor anyone I work with has touched a system developed in the past 6 years that didn't use React with with Webpack and/or Esbuild for the build system. Of those, 90% + used Redux for state management or switched to Redux after starting with a different state management system like mobx or xstate. The only exception to this the only exceptions are apps that needed something Recoil-like (e.g. Redux caused too much computational overhead). Some of them also used Nextjs for static pages.

I’ve experienced similar thing wrt the build system, but haven’t used redux in all but one of the React projects I’ve worked on as a full time product engineer over the past couple of years.

Just to chime in here for anybody reading along:

I work full time as a software developer doing react. I have got literally no idea what almost everything you listed is.

"Broccoli"?

I have heard: grunt, gulp, webpack, metro, redux, and recoil. The rest of those could be sarcasm for all I know.

These are only the mainstream ones I can remember, there have been a ton more! I guess if you've started post-2018 things have been a bit more stable, but there was quite a bit of churn to get here. And it's still happening - no two React projects are alike even in the enterprise.

https://github.com/broccolijs/broccoli

That’s because react is a library, and not a framework. React doesn’t have opinions, that’s why you can find 300 state management libraries and 200 routers which do the same thing, just in different ways.

> That’s because react is a library, and not a framework.

React should be considered a framework.

React absolutely imposes a data model (unidirectional workflow) to the developer thus a certain code structure. The fact that it is light weight compared to Angular doesn't change the fact that React is a front end framework. React usage completely replaces the traditional way to interact with the DOM and manage DOM events, thus abstracting it.

> React doesn’t have opinions,

React becomes very hard to use if your data model isn't organized to suit React architecture.

It doesn't have opinions about everything (like AJAX or SPA routing) but it absolutely has an opinion about how you data objects should be structured.

Indeed, it's unfortunate that React bills itself, in its front-page copy, as a library and not a framework, out of a desire to emphasize its portability and being "lightweight"; but the day-to-day of building a React app is more that of working in a framework than calling library functions.

Quote from reactjs.org: A JavaScript library for building user interfaces

Literally on the start page

If you don't know these words you haven't been coding JS long enough. Those like myself who started in 2014 or earlier know all of those and more (anyone still remember shrinkwrap for example)?

Depends HOW you coded. I started JS at 11 yo in 2001, and became fulltime around 2012 - 2 more years of JS than you, I'm your grandaddy in this ever changing mess... I do not know Broccoli either. Googling it: "A fast, reliable asset pipeline, supporting constant-time rebuilds and compact build definitions" I raise my eyes to the ceiling and whine "why the hell isn't there an Oracle or IBM for JS to finally standardize just building crap".

It's probably cause I switched 4 years ago from the typical perma-migration grind to rarely using any framework and coding JS like I code the backend. Simple service classes in pure JS, rare dependencies, simple build. I once ditched years of work by a team of 40 to rewrite "everything" in low level javascript and showed the guys that what we spent all this years writing, really, was useless: did we need that enormous angular runtime config resolver that would draw generic components reading from crafted json configuration ? Or could we just write the damn things as we mean it in... javascript directly ?

Don't use a JS framework as long as you can help it, just the simple fact you can trace the whole function chain in a few seconds, vs reverse engineering the damn VueJS, or React, or Angular (does that monster even exist anymore, we hear about it a lot less than when it was all-encompassing, 8 years ago) plumbing, is worth it.

And son, if you want some war stories from your granddad, have you heard of jQuery ? :D

Very, very few places will let you not use a framework nowadays. There is a ton of cargo culting around JS frameworks and coding vanilla is pretty much heresy land these days. Personal projects? Go for it. Commercial apps built for your employer? Good luck with that. Not only will you be raked over the coals for "reinventing the wheel" you'll also be blamed for any stumble along the way, whether it's related to using vanilla or not.

> if you want some war stories from your granddad, have you heard of jQuery ? :D

Bah, whippernsapper! I cut my baby web teeth on CGI and spent the bulk of it in Struts and JSF. Remember THOSE?

No I don’t. I was too busy programming ENIAC using patch cables. Grace Hopper once made a snide remark about it after lunch. She smelled like corned beef hash.

I was "born" after Struts was "obsolete" (so I had my honeymoon phase with Spring/Hibernate until I fixed so many mistakes in companies I decided using smaller surface tools and closer to the metal queries would actually save time) and never touched JSF :D CGI for me is prehistory loool.

However, employers dont need to be involved in choosing a framework or not. You ll notice that usually its the little bees building their resumes that bemoan non stop about migrating from react to vue or vue to react :D

I never heard a sales guy tell me: WHAT, it works fine, is cheap to maintain and has no stupid 10k levels dependency graph in npm ? I ll stop making money on this until you completely "standardize" it into a moving sand on npm. And dont forget a pipeline of 3 transpilers, you wouldnt want to write in a browser-native language, caveman.

I do use requireJS to split in nice files and import easily though I admit.

Broccoli I believe is still used to build ember projects

It’s true that there are a lot of different ways to do the same thing, but the good news is you’re doing the same thing and the difference is mostly just syntax. Someone who has used Redux extensively can get up and running with Zustand in no time, and vice versa. Likewise React Query and Apollo Client are basically the same thing.

Build tools are a bigger issue, but fortunately most front end devs don’t actually need to deal with them all that often.

As if it's so easy to move from one thing to another. Yikes!

Some libraries will create code mods to assist in transitions. For example I've used some MUI codemods in the past to make transitions to newer versions of the library more seamless [1].

There are also codemods to say move from underscore to lodash and vice versa (been a while and can't find them at the moment).

ASTs [2] are pretty cool in this regard. Especially if you write your code in a manner that easier to automate against.

[1] https://github.com/mui/material-ui/blob/master/packages/mui-... [2] https://en.wikipedia.org/wiki/Abstract_syntax_tree

Postgres, mysql, mariadb, cockroachdb, Prometheus, neo4j, firebase, dbaas. The list goes on and on.

Multiple things exist. That’s fine and healthy? You don’t need to know absolutely everything.

There's people out there who chose PostgreSQL twenty five years ago and found out since to have made the right choice. Not sure if that can be said of any item on the list you were responding to.

I would be thrilled to work someplace that uses neo4j. Such a good graph dbms. Too many folks believe the only way to organize data is with relational tables.

and now its all use Deno and Svelte bro. 6 months it will be you're still using Deno and Svelte, should be using XDenoX and ReSvelte (or something).

Webpack has been the de facto build system for react since 2017

Competing state libraries is to be expected but picking redux or mobx has let you use the same ones since 2017

JS itself has improved but hasn’t really ever deprecated anything, it just grows and adds terse methods to the language

Npm and yarn are among the best package managers

React hooks were the only major change you’ve touched on but even they didn’t deprecate class based react or change library semantics very significantly

These are not really counterarguments to the fact that things change a lot here, and newcomers and veterans alike need to continuously learn, and pick the best. None of these started off as the default choice, I remember when each and every one of these was the weird / risky option.

They are very much counter arguments to the idea that there is big churn still happening.

Webpack 2 was in CRA in 2017

Redux and MobX have been the #1 and #2 state managements for that whole span, and clearly all the observable libs are successors of MobX after Proxy came out

Every language changes, many with breaking version changed that JS avoids

I don’t know how you’d point at package management as an issue in JS land

It’s just that every single popular community has massive amounts of clones or similar libraries, I don’t know how that qualifies as “churn” though. I maintain my 2017 apps including major version bumps with no issues today, using the same libraries and tools. The argument you’re making was fine in 2016 but is half a decade out of date.

> I maintain my 2017 apps including major version bumps with no issues today

Sorry but I have to call bullshit on that, unless you’re taking about tiny one page “apps”. Webpack alone has gone through five major revisions in this time, with large breaking changes meaning all of your plugins and babel extensions needed upgrading (sometimes not readily available), rewriting the entire config, even before you get to upgrade React and dependencies. React Native has changed massively in this timeframe, I’m talking complete API refactoring and packages moving around, not simple function signature changes.

This is simply not reality for people working tech jobs.

For a glaring example, you say it’s #1, but Redux is dead in the water. I haven’t interviewed a single person in the past two years that wants to use it. The creators have been recommending “just using react.Context” for years and that has clearly had an effect.

> > I maintain my 2017 apps including major version bumps with no issues today

> Sorry but I have to call bullshit on that, unless you’re taking about tiny one page “apps”

What a strange stance. It's a React/MobX collaborative model editing internal tool deployed in production to users who generate and analyze models with it. It started on Webpack 2 and React 15 and MobX 4, now it's on Webpack 5 and React 17 and MobX 6. I of course had to update some babel configurations but it was much more version bumping than configuration rebuilding. It still uses decorators and looks like complete dog-shit, and that's my point: the same tricks and patterns available then are not only there, but working identically now.

Re: native, I don't believe in React Native or any webview-based "native" replacement anyways, but it's easy to do this as my user-base is interacting with this app from their company-provided laptops anyways. I would willingly concede React Native is an environment with churn, I don't really recall RN every reaching meaningful stability

> Redux is dead in the water

https://www.npmjs.com/package/redux shows 7M downloads weekly

https://www.npmjs.com/package/react-redux shows 5M

https://www.npmjs.com/package/@reduxjs/toolkit shows 1.5M

MobX / MobX React are around 1M/700k

Your list of "flummox / redux / unstated / mobx / mobx-state-tree / xstate / apollo / apollo-link-state / swr / react-query / zustand / recoil / jotai" seems to peak at 500k with the exception of "react-query", which I don't really see as applicable to a conversation about state management. Overall, this list perfectly illustrates my point that there's new stuff but you don't need to know it, and the value props aren't convincing alive-and-well shops to drop everything and rebuild

> you say it’s #1, but Redux is dead in the water

I never personally believed in Redux, it struck me as a terrible pattern from the start, thus why I selected MobX; but I find it difficult to believe that you really think React Context scales the same way building an external state management tree does. I like React Context, but it doesn't do a very good job of hiding away complexity from the developer as the application grows. Not to mention it does no render-optimization for you.

Again, I'm not saying things don't change or that there's not alternatives, but I am saying that someone who learned fundamentals in 2017 is still able to get up-to-speed in the updated versions of the library kings of 2017 in virtually no time, and deliver standard-fare webapps. I say this because I've worked at the same place for over 5 years, I use the same tools, and my users regularly are telling me the tools my team puts in front of them are the gold standard. The churn is long gone, everything you describe would have perfect analogues in any other popular modern language / library ecosystem.

> I find it difficult to believe that you really think React Context scales the same way

I don't, and I find the advice on this subject found around the web pretty terrible. But it's the position you'll most often see from React core team and people selling online lessons.

jQuery is still used in > 50% of websites. Popularity in numbers lags way behind developer adoption.

I've been involved in multiple new product development efforts in the last decade, and can tell you it looks a lot different from maintaining one stable product. And it's sped up by 10x if work at an agency putting out a different project every 2-3 weeks. This is where the fatigue comes from.

Lol, where did you get that I maintain one stable app from? I additionally don’t see how your working conditions relate to churn in JS given that you could use the same stack for each of those projects, as I said, as far back as 5 years ago

You said 'It's a React/MobX collaborative model editing internal tool' so I assumed you're commenting based on that particular project. It's not a value judgement either way.

The kind of development you do (product / projects / marketing) makes a huge difference in your experience, how often you get to start from scratch (= latest versions of everything) vs maintaining existing codebases. I don't think that's controversial. You could use the same stack for every project, but people and teams change and want to catch onto the latest "advancements" in the field.

Yes, this whole time you’re assuming I’m doing the bare minimum, and that no one could be using the same tools.

Yet, here I am, new apps in hooks based react, old ones not, and the same stack delivering great performance in either case - DX is only suitable in some tho

I’ve used Context only, SolidJS, Angular, whatever you like these days, I still would only build real apps with MobX. Typescript is the only real change since 2017 you need, otherwise what’s newer is not what’s better since then. That’s the point. Take care and try to not get lost in the noise, it’s very different than what came before it

> Webpack has been the de facto build system for react since 2017

lol and that's why we saw the emergence of rollup and parcel and snowpack and whatever the hell else came along since then?

I’ve never seen a situation where someone hasn’t tried to rebuild something that’s already working (in a big community like JS land). Some people wanted more performance from their build systems, some people like other languages to do the transpilation, some people thought the configuration options were too heavy and opaque. That’s why we saw ESBuild and rollup.

But CRA is still on webpack, and CRA is still the de facto default way to make a new react app. I don’t really see the fact that alternatives exist as implying churn when the same option has been the longest living and most popular.

Reply on news.ycombinator.com