151–160 of 181 posts
The web browser as a platform just sucks to work with, it always has, just now the issues are more nuanced than just dealing with quirks or ms jscipt weirdness.
Earlier quoted context omitted.
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…
> 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 upgr…
> 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'm the author of this piece. I no longer think front-end suffers the instability people accuse it of. I think there are a lot of _vendors_ trying to usher in a revolution around their particular products - there's a lot of VC funding in JavaScript tooling nowadays - but that's a different problem.
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…
Earlier quoted context omitted.
The Vue 3 disaster (in my opinion) shook my trust in the framework forever. I immediately knew this is not a framework I will spend any more time in. What if I "upgrade" my apps to 3 and then Vue 4 comes along with yet another fundamentally different concept? This is not acceptable for apps with any kind of long time support requirement. Yes I know, Vue 2 paradigms are still usable in 3 but they feel very deprecated.
I inherited a vue2 codebase with a vuex store, and upgrading to vue3 and pinia one component at a time over a course of 3-4 months was quite easy. The upgrade path is really clear and they did a good job making everything compatible so that it could be made gradually over a relatively long time.
Earlier quoted context omitted.
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 even…
Having started to work more in dev ops lately, I no longer think this problem is unique to FE. The number of tools used in the dev ops scene makes my head spin. There are hundreds of products and services one can employ when building out infrastructure that didn’t exist 5 years ago. Everything being built on top of kubernetes alone will send you into decision fatigue and months of research. I see no meaningful difference. Why’s is that? Do we just feel like the gravity of infra is more deserving of the complexity?
Frontend is unstable because it attracts ppl whose attention span is often lower than the one of a goldfish. Every JS frontend dev I met was speedrunning trying to prove himself by "inventing something new" which in fact was already a state of art. The amount of rehashing and reinventing the wheel with new catchy names in the field is staggering. TBH, if the field wants to improve -> its time to ditch JavaScript and…
This is true at every layer of software development.
> TBH, if the field wants to improve -> its time to ditch JavaScript and force Browsers to move to something that makes more sense.
I don’t think I could disagree more. JS is a tool, swapping it out doesn’t remove the unique problems of front end development.
Let’s say we switched to python for the FE. The team wants to use numpy for some of its features. Bam, 30 mb being sent over the wire for one library. What do you do? You decide that’s unacceptable and start extracting the functions from the library you are using. You realize that these functions are useful enough on their own and publish them separately on pypi. You describe the library as fast and only 1kb.
Then someone else comes along and decides this is a tedious task to break up all these libraries and publish small functions as packages. They figure out a smart way to tree shake the library so only the code used gets sent over the wire. Do you see where I’m headed here? In 5 years the python ecosystem for FE development will look shockingly like JS of today.
Your solution does not resonate with me because it does not address the core problems of FE development. The tool isn’t the issue, it’s what the tool is trying to solve for that is the problem.
Maybe that’s my inner geezer talking or there’s some nostalgic distortion at work but building a website and a small product used to be comparatively easy. Today with the elevated expectations on functionality and the tons of tooling it quickly becomes an almost insurmountable task. Everything appears to be optimized for the large scale, where all the tooling and workflows probably help. There are just so many moving parts, all the time.
I’d like to build performant web sites and products with as little JS as possible, make a good living doing it and spend time refining the foundation. But those jobs are gone. It’s all JavaScript and full-stack development positions now.
Earlier quoted context omitted.
> 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 upgr…
> > 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…
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.
Well, isn't it the case?
One more article confusing web programming with the whole software development!
Front-end development is unstable only for those applications where the nicest, latest GUI is the only value the developer takes to the table. Learn the business, have your application solve an actual business problem, offer a well-thought and on-spot ergonomic interface, and the users will love the features, and the GUI will not look oldish to them after two years.