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

Why is front-end development so unstable? (2018)

breck-mckye.com

Post reply on HN
Print view View original

111–120 of 181 posts

Re: Why is front-end development so unstable? (2018)

#111

Post by karmasimida »

I think it is getting stable recently. It is a choice of React/Vue/Angular for the most.

Be hold there are some choices to make here and there, but if you go with a vanilla setting with popular choices (like Webpack for build), things won't go wrong. Not everything needs to be shiny and edgy.

From that angle, the frontend space doesn't seem to be that different from wrapping around pytorch and offer yet another Trainer API with some callback shenanigans and claims to invent an AI framework.

Re: Why is front-end development so unstable? (2018)

#112

Post by abraxas »

thepasswordis wrote: post #89
ricardobeat wrote: post #80

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…

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.

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)?

Re: Why is front-end development so unstable? (2018)

#113

Post by korm »

ricardobeat wrote: post #80
zero_shift wrote: post #54

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

Re: Why is front-end development so unstable? (2018)

#114

Post by abraxas »

nawgz wrote: post #82
ricardobeat wrote: post #80

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’…

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

Re: Why is front-end development so unstable? (2018)

#115

Post by throw_m239339 »

pojzon wrote: post #56

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…

> TBH, if the field wants to improve -> its time to ditch JavaScript and force Browsers to move to something that makes more sense.

Javascript was never the problem. Today there are bazillions of solutions using another language for the people who don't want to hear about Javascript. The problem is all the DOM and WebAPI available to the developer. You can potentially interact with all that in C++ if you wish, but you'll always be limited by the exact API as Javascript in the browser, by design.

Fundamentally there is a mismatch between how the DOM works and how most people develop complex interactive UI, switching to another language doesn't solve that problem.

Re: Why is front-end development so unstable? (2018)

#116

Post by nawgz »

abraxas wrote: post #114
nawgz wrote: post #82

Earlier quoted context omitted.

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’…

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

Re: Why is front-end development so unstable? (2018)

#117

Post by xwolfi »

abraxas wrote: post #112
thepasswordis wrote: post #89

Earlier quoted context omitted.

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.

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

Re: Why is front-end development so unstable? (2018)

#118

Post by scrose »

korm wrote: post #113
ricardobeat wrote: post #80

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…

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 doi…

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

Re: Why is front-end development so unstable? (2018)

#119

Post by runarberg »

suction wrote: post #49
jansan wrote: post #41

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.

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.

Re: Why is front-end development so unstable? (2018)

#120

Post by ajmurmann »

Let's use an analogy to maybe get closer to why churn on the front-end tech is so high: A few weeks ago I was reading a discussion on which musical instruments are hardest to play. Someone said that they are all equally hard, because if the instrument is easy to play, people will write more complex music for it.

I think the same happens in front-end dev. It happens here because it's obviously exposed to users and we want to a) follow fashions and b) wow our users. As soon as tools get more powerful and we start to master them we'll start to push the boundaries and everything becomes a pain again and several people will write frameworks or tools to make it easier.

Post reply on HN