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

91–100 of 181 posts

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

#91

Post by ricardobeat »

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.

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

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

#92

Post by cehrlich »

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…

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.

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

#93

Post by jwatte »

cloogshicer wrote: post #70
api wrote: post #39

Earlier quoted context omitted.

My pet hypothesis for years has been that developers always vastly underestimate the difficulty of doing a UI framework or environment. They think it'll just be a matter of painting widgets and presenting data. As a result they under-build the foundation. The insufficient structure is then released out to the world for everyone else to build upon. Once people realize the soul devouring chthonic difficulty of doing go…

I think you're spot on. My hypothesis has been for a while: UIs essentially are video games. They have animations and interactions that rival the complexity of video games. Sometimes they even have sounds too. The rendering is not quite as complex (usually!), but everything else definitely is. I'd like to see a UI system that is built by experienced game devs, who also are good at and understand interaction design.

This is probably a better comparison than one might at first think.

A game engine has a second, hidden, part of the iceberg: The production pipeline for all the 3D world/art assets.

That's actually where most of the work goes -- hundreds of artists go into a AAA game, and all the art they produce must be technically excellent along a bunch of dimensions that have nothing to do with what it looks like (and in fact, generally make it harder to achieve the look you want.)

Game engines that can wire physics simulation to 3D rendering to window abstractions are easy-ish to make, similar to how web UI frameworks are easy-ish to make.

All the production pipeline stuff is where the real meat is, similar to how in WebUI and, package management and transpiling and bundling and deploying is a hard problem. I think the game side has it even harder than the web side, though, although they usually have the benefit of only needing to work on a defined set of platforms, rather than in "the" browser.

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

#94

Post by randomtwiddler »

daenz wrote: post #37

Fads are tempered by a community of people anchored in a deep understanding of the technology. As talented as many FE engineers are, I can count on one hand the number that I've met that have a deep understanding of things like await/async + Futures, closures, DOM trees, etc. These things are (perhaps unfortunately) required to do FE work, yet the engineers using them don't fully understand them, so they don't know h…

It's interesting how you can look down on front end for being new and naive while suggesting that Google is a fine reliable tech stack provider.

I'm the opposite of everything about this post. A very experienced dev (>20 years professional experience) that has moved primarily to the front end recently in my career (gradually over 4 years). I won't touch flutter simply because the sole vendor and essential dependency is Google.

Fads are present in every corner of development. As is "not invented here" or the general draw to green field.

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

#95

Post by oraphalous »

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…

So your solution to the problem of the field re-inventing itself over and over is for it to... re-invent itself again.

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

#96

Post by secondcoming »

tenebrisalietum wrote: post #81
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…

Does WASM make more sense?

The idea is sound, but it'll just allow mediocre JS devs write the same crap but in a multithreaded way.

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

#97

Post by LoveGracePeace »

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…

Java would be my strong preference.

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

#98

Post by daenz »

randomtwiddler wrote: post #94
daenz wrote: post #37

Fads are tempered by a community of people anchored in a deep understanding of the technology. As talented as many FE engineers are, I can count on one hand the number that I've met that have a deep understanding of things like await/async + Futures, closures, DOM trees, etc. These things are (perhaps unfortunately) required to do FE work, yet the engineers using them don't fully understand them, so they don't know h…

It's interesting how you can look down on front end for being new and naive while suggesting that Google is a fine reliable tech stack provider. I'm the opposite of everything about this post. A very experienced dev (>20 years professional experience) that has moved primarily to the front end recently in my career (gradually over 4 years). I won't touch flutter simply because the sole vendor and essential dependency…

If you're looking for a response, you're not really giving me much to respond to. Why do you think Google doesn't provide a "reliable tech stack" ? In any case, I wasn't suggesting that specifically (though I tend to agree with it), only that they have a coherent ergonomic vision by competent engineers.

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

#99

Post by gherkinnn »

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.

Coming from Vue 0.x and 1, Vue 2 felt wrong. It didn’t know what it wanted. Classes and hooks and decorators and options and only some obscure combination offered acceptable TS support.

Having only read the docs, Vue redeemed itself with version 3.

There’s the options API we know and love from v1 and the new and intuitive composition API. The docs make it easy to decide and not to mix them up. And no useEffect fuckery.

Post reply on HN