Live data from Hacker News

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

breck-mckye.com

11–20 of 181 posts

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

#11

I think that if you want a page to impress or make a splash then sure, you always have to move to the next greatest thing, however, I don't work for them but I've paid for Telerik Kendo Controls (the react ones specifically)since they were released, before then, the AngularJs ones and it's been great - it keeps my (albeit internal app) UI development stable, fast and looks great with minimal fussing about. It's been…

I had to read your comment twice to be sure we're talking about the same Kendo. I've consulted for a number of companies over the years who have used it (or tried to use it), ever since the jQuery version to up until now, and it's always been pure pain. I understand how their components work, I understand the underlying architecture because I've stepped through it too many times with a debugger, and I still always fail to understand how they have any happy customers. Perhaps there is a good experience to be had if you only use the components exactly the way the documentation examples use them, but the moment you step outside that narrow path, things fall apart. Never mind custom code, simply using two different components from their library together doesn't even always work.

The first time I had a bout with Kendo was some odd ten years ago, and then I was sure it was simply me not understanding the framework. After all, every component library has its own kinks and it takes a while to get up to speed. After seeing them again and again many times over the years, I've changed my opinion. In my eyes, Kendo is what I like to call an MBA trap. It ticks all the boxes that an MBA manager going by a feature checklist is looking for, but under the hood it's garbage software. I'm glad you've had a good experience, at the same time I don't think I will ever stop recommending everyone to stay away from Kendo.

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

#12
Maybe I'm the odd one out, but I feel like the instability is mostly surface-level and FE is not, actually, so much less stable than other areas? I got into tech via web development, migrating further into the backend over time, and about four years ago became pretty much exclusively backend. Just started a new job and I'm back in the front end.

Some things have changed, but not that much.

- Typescript was just getting popular when I left, now it's basically a standard, but 1) after having been in javaland for a while, adding typing to JS makes a lot of sense to me and 2) though it's a change, feels like a change toward more stability, not less?

- React was the big framework when I left, still is the dominant framework.

- There's still a lot of option -- eg vue, etc. nextjs wasn't a thing I knew about that I am starting to learn now. Class syntax felt unecessary to me but seems to be de facto these days. But... these all feel relatively small?

I started in FE back in the days of IE 6. jQuery was a godsend when it arrived, underscore was super helpful. I'll grant the shift from "we use JS to add some interaction, form validation, and sometimes interact with Flash" to "we use JS to write actual programs delivered via your browser" was a huge shift, but since we've made that shift it seems most of the "instability" is more around FE devs adopting practices already common in the rest of the stack.

I think maybe that's where this sense of instability comes from -- a focus on the wide array of possible _implementations_ -- but I feel the really disruptive shift from "interactive decoration" to "web applications" was the really big one, and that's a while back now. And even with the dizzying array of possible implementations, there's obvious market leaders -- you're not going to go wrong by learning React, any more than you're going to go wrong by learning Spring Boot. Always good to explore and get familiar with other libraries and frameworks, but if one feel overwhelmed by options, there's some clear well trodden paths that aren't changing _that_ fast.

One thing I will say is that I do think FE is _harder_ than BE, because the scope is wider. You need to grasp all the aspects of good programming, but _also_ get a decent grounding in design and UX, which are their own disciplines. A backend API doesn't have to think about things like screen readers or color contrast or all the weird ways users will figure out to misunderstand how to interact with your GUI widgets. A UI for humans is inherently harder than a UI for machines. But that's not the same thing as saying that the FE is unstable.

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

#13
post #6

The old saying goes like this: "if you want freedom on one layer you need stability on the layer below" My guess is that since frontend web development is at the top of the stack it has an incredible amount of freedom so everything changes every minute. You don't see too many people wanting to subvert HTTP making a billion homemade alternatives

> You don't see too many people wanting to subvert HTTP making a billion homemade alternatives

No? I constantly come across new protocols, promising improvements compared to it. Some even become relatively popular and are included in browsers by default. Just some examples are WebSockets, WebRTC and QUIC. I expect we'll see more of them in the future as specific use cases requires more specific protocols.

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

#14

Hum... The Great (Web) Frontend Revamping seems to have passed. Nowadays people are still discussing if React or Vue is better, with a clear intonation of "whatever works for you, I prefer X". Looks like the field is maturing. Either that or we are on a fake calm before we see a lot of articles about people migrating into wasm in "whatever language has support for it right now" (AFAIK, currently wasm goes with rust).

Don't worry, view layer may be stabilizing but what about

Managing backend requests is too complicated!(react-query)

You *need* gql don't you?

Don't forget forms. Super hard to do right. react-final form, react form hook, etc

We need a monorepo framework! Nx, turbo, rush, pnpm (too low level), Lerna (too old and unmaintained)

What about bundlers huh? Vite, esbuild, rollup, webpack

I still see plenty of opportunity for teams to ignore persistent issues and just diagnose a new framework without analyzing their current woes. Silver bullets for everyone!

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

#15
Saying React support libraries are at fault here is not fair - React basically reimagined itself over the years and went from OO and class based components to hooks and functions. The fact that you can still do OO isn't really helping it since it adds to the complexity of things you need to learn to grasp the ecosystem.

But that's honestly missing the forest for the trees - JavaScript itself went from asynchronous callback pyramid of doom, to promises and callback chaining, to async/await. The community went through multiple half-assed module approaches/specifications. Several FOTM bundlers with extreme complexity and various tradeoffs. Various build systems.

Features like hot reloading, transpiling, source mapping, shimming are table stakes for any frontend framework and involve a lot of complexity and tooling - because the entire ecosystem is built on a foundation of shit that is JS and the browsers.

So frontend frameworks are the least relevant part here - it's everything that makes them tick that's the problem.

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

#16

Hum... The Great (Web) Frontend Revamping seems to have passed. Nowadays people are still discussing if React or Vue is better, with a clear intonation of "whatever works for you, I prefer X". Looks like the field is maturing. Either that or we are on a fake calm before we see a lot of articles about people migrating into wasm in "whatever language has support for it right now" (AFAIK, currently wasm goes with rust).

Don't worry, view layer may be stabilizing but what about Managing backend requests is too complicated!(react-query) You *need* gql don't you? Don't forget forms. Super hard to do right. react-final form, react form hook, etc We need a monorepo framework! Nx, turbo, rush, pnpm (too low level), Lerna (too old and unmaintained) What about bundlers huh? Vite, esbuild, rollup, webpack I still see plenty of opportunity fo…

The difference is that's all ignorable. If you want to standard React with classes, redux, npm and webpack like it's 2017 then you absolutely can, and it's still a maintained and supported solution.

That's very different to say the evolution from JQuery to Backbone to AngularJS to React where you ended up being on an increasingly unsupported platform if you didn't upgrade.

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

#17

Hum... The Great (Web) Frontend Revamping seems to have passed. Nowadays people are still discussing if React or Vue is better, with a clear intonation of "whatever works for you, I prefer X". Looks like the field is maturing. Either that or we are on a fake calm before we see a lot of articles about people migrating into wasm in "whatever language has support for it right now" (AFAIK, currently wasm goes with rust).

Don't worry, view layer may be stabilizing but what about Managing backend requests is too complicated!(react-query) You *need* gql don't you? Don't forget forms. Super hard to do right. react-final form, react form hook, etc We need a monorepo framework! Nx, turbo, rush, pnpm (too low level), Lerna (too old and unmaintained) What about bundlers huh? Vite, esbuild, rollup, webpack I still see plenty of opportunity fo…

[deleted]

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

#18
post #6

The old saying goes like this: "if you want freedom on one layer you need stability on the layer below" My guess is that since frontend web development is at the top of the stack it has an incredible amount of freedom so everything changes every minute. You don't see too many people wanting to subvert HTTP making a billion homemade alternatives

> You don't see too many people wanting to subvert HTTP making a billion homemade alternatives No? I constantly come across new protocols, promising improvements compared to it. Some even become relatively popular and are included in browsers by default. Just some examples are WebSockets, WebRTC and QUIC. I expect we'll see more of them in the future as specific use cases requires more specific protocols.

I think you make a fair point but on the other hand I don’t see many “top 20 alternatives to http in 2022” articles (which implies there are more than 20 alternatives) like we have for front end technologies.

I.e. https://www.netguru.com/blog/front-end-technologies

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

#19
post #6

The old saying goes like this: "if you want freedom on one layer you need stability on the layer below" My guess is that since frontend web development is at the top of the stack it has an incredible amount of freedom so everything changes every minute. You don't see too many people wanting to subvert HTTP making a billion homemade alternatives

> You don't see too many people wanting to subvert HTTP making a billion homemade alternatives No? I constantly come across new protocols, promising improvements compared to it. Some even become relatively popular and are included in browsers by default. Just some examples are WebSockets, WebRTC and QUIC. I expect we'll see more of them in the future as specific use cases requires more specific protocols.

Those are orthogonal choices though.
Post reply on HN