81–90 of 181 posts
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…
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…
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
Earlier quoted context omitted.
> Pretty much anything after C/C++ era comes with a usable build system, modules and a package manager. JS is really stuck dealing with insanely low level issues in shit ways for various historic reasons. But of course JS needs neither a build system (runs from source files) nor a package manager (runs from URLs) and recently even plugged the "no modules" hole.
> recently even plugged the "no modules" hole I haven’t heard about this. Do you have a link so I can read more?
Earlier quoted context omitted.
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…
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’…
Front end develoment has never been more fun if you can keep up with the pace. Finally all major browsers have decent standard support (no Internet Explorer anymore), so crutches like jQuery are not needed anymore. Developers constantly find new ways to implement front end apps, and they are not afraid to break backwards compatibility. This may be bad if you have an old monolith to maintain, but overall it's a good t…
It's not great. It is bad, really. It means no one that hasn't dozen millions of dollars can implement or even just maintain a viable browser that can keep up. And since we expect browsers to be free, that means… "complicated" business models cough mostly¹ relying on ads and tracking cough to maintain the Web.
I which it wasn't this way really. There was a time when it was possible for a few people to implement a quite good browser engine in their free time. KHTML. So good, in fact, that it was chosen as the basis of WebKit (and therefore Blink). This does not seem possible anymore.
1. There's Apple maintaining a browser engine without relying on ads, but their business model is also questionable.
Earlier quoted context omitted.
Thank you! Part of the reason that I love these front-end threads is because inevitably somebody will make a fool of themselves by spouting anti-js-dev "backend master-race" nonsense, and this certainly did not let me down.
It would be true if I was working in backend development. I dont. JS is just not good enough for what we want it to do. Someone sooner or later has to make a decision to move further.
Earlier quoted context omitted.
> Pretty much anything after C/C++ era comes with a usable build system, modules and a package manager. JS is really stuck dealing with insanely low level issues in shit ways for various historic reasons. But of course JS needs neither a build system (runs from source files) nor a package manager (runs from URLs) and recently even plugged the "no modules" hole.
Majority of people using JS with these frameworks are using package management and bundling - and suffering because the ecosystem has such shitty tools for dealing with it. If you're linking jquery from your favorite CDN and writing your code inside of tags you're not dealing with the issues this article is describing.
Earlier quoted context omitted.
> Pretty much anything after C/C++ era comes with a usable build system, modules and a package manager. JS is really stuck dealing with insanely low level issues in shit ways for various historic reasons. But of course JS needs neither a build system (runs from source files) nor a package manager (runs from URLs) and recently even plugged the "no modules" hole.
Majority of people using JS with these frameworks are using package management and bundling - and suffering because the ecosystem has such shitty tools for dealing with it. If you're linking jquery from your favorite CDN and writing your code inside of tags you're not dealing with the issues this article is describing.
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…
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.
Earlier quoted context omitted.
If you started with Vue two years ago, you had to learn Vue 3 shortly after that. With a new Vuex. Which has been dropped since in favor of Pinia. Oh, Vite has been developed since, so you may want to add this to your stack, because it makes compiling during development so much faster. Also, be aware of all the breaking changes that Webpack 5 has introduced. I hope front end development will be more stable in future,…
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.