Live data from Hacker News

Ask HN: Why did Frontend development explode in complexity?

news.ycombinator.com

141–150 of 398 posts

Re: Ask HN: Why did Frontend development explode in complexity?

#141

Unpopular biased opinion. Frontend development is mostly done by people who are into visual things and less into logic. Unlike backend engineering, where people working are primarily choosing technology based on logic/merit and less by visual appearance. This leads to the adaptation of large number of garbage frameworks in frontend primarily because their landing pages look visually appealing. After some time fronten…

> Unlike backend engineering, where people working are primarily choosing technology based on logic/merit.

Sometimes I wish I could do the crying-while-laughing emoji on HN.

Backend devs have biases and get tricked into making the wrong choices just like everyone else.

Re: Ask HN: Why did Frontend development explode in complexity?

#142

Unpopular biased opinion. Frontend development is mostly done by people who are into visual things and less into logic. Unlike backend engineering, where people working are primarily choosing technology based on logic/merit and less by visual appearance. This leads to the adaptation of large number of garbage frameworks in frontend primarily because their landing pages look visually appealing. After some time fronten…

In my opinion the complexity is caused by the amount and the combination of technical choices, design choices, and process pipeline choices.

... Long story short is that a web app is cross-platform (browser) program and that very quickly gets quite complicated requirements. Of which security, dependency management and frameworks are a big part. Because you need to know about them, and how they work etc..

Long story / ramble:

A simple static website can be as simple as a bit of HTML with CSS.

But when you introduce workflows and users it isn't long before security comes around the corner. And that introduces a lot of complexity, which frameworks and packages help with. (Don't roll your own)

So the security packages comes with typescript. Which makes you adopt typescript and adds a bit of complexity over JS. (But also typesafety! I'm a fan FYI)

And then you want the website work as a progressive web app, so you need a service worker. More complicated.

You then might want to add some sort of isolation of CSS, or use Sass or some other framework. To help with code re-use and avoid breaking things as the app gets larger. Also more complicated.

Then your PO says you need to have async workflows and let the user know when something starts and is done, with push messages. So you need a background worker and push messages.

And we're not even talking about the technical issues, like not all browsers supporting certain API's or certain styles. Or updates to package X breaking package Y, needing a package patch.

Not to mention keeping up with the evolving syntax and language capabilities. HTML, Javascript, Typescript, CSS, SASS etc... They all keep changing and evolving.

Re: Ask HN: Why did Frontend development explode in complexity?

#143

Because the browser nowadays is an "operating system" that needs to be capable of handling all manner of dynamic software: maps, video, image editors, games, etc. I haven't done Windows development, but I assume browser-based development complexity will continue trending towards essentially the same complexity as developing e.g. a Windows program.

I'm a Windows developer and as such I'm biased, but I think Windows apps are dramatically easier to write than web apps. I still use WinForms professionally to this day. Productivity is absurdly high. The number of concerns to worry about is low. The framework has been stable for 20 years and I know all of its quirks, which never change. Fads are ignored. We can zip around with amazing speed. On the other hand, our a…

A large part of the reason people ignore your model for business use, where the target platform is locked down to a single target, is the perceived need to run their software on any given piece of hardware.

That's a question that really aught to be answered. If the business application only requires Windows PCs as a target your design wins out despite the perceived shortcomings.

Re: Ask HN: Why did Frontend development explode in complexity?

#144
post #47

Earlier quoted context omitted.

To be fair most front-end projects have abandoned redux now. It was for sure boilerplate hell.

I've been doing some research recently and it continues to be by far the most popular state management framework for React. The fact that there are alternatives doesn't mean that most projects have abandoned it.

Has it occurred to you that maybe “state management” is not something you need a framework for?

Re: Ask HN: Why did Frontend development explode in complexity?

#145

Because the browser nowadays is an "operating system" that needs to be capable of handling all manner of dynamic software: maps, video, image editors, games, etc. I haven't done Windows development, but I assume browser-based development complexity will continue trending towards essentially the same complexity as developing e.g. a Windows program.

I'm a Windows developer and as such I'm biased, but I think Windows apps are dramatically easier to write than web apps. I still use WinForms professionally to this day. Productivity is absurdly high. The number of concerns to worry about is low. The framework has been stable for 20 years and I know all of its quirks, which never change. Fads are ignored. We can zip around with amazing speed. On the other hand, our a…

Would solving these painpoints be a market? Sounds interesting to delve into.

Re: Ask HN: Why did Frontend development explode in complexity?

#146

Unpopular biased opinion. Frontend development is mostly done by people who are into visual things and less into logic. Unlike backend engineering, where people working are primarily choosing technology based on logic/merit and less by visual appearance. This leads to the adaptation of large number of garbage frameworks in frontend primarily because their landing pages look visually appealing. After some time fronten…

IMO a lot businesses could/should be in the business of providing the API and leaving the UX to end users.

Especially dev/ops facing services where I want simple quick answers, not memorization of mouse motion, and click habits.

Services like DataDog, as an example, are inherently dev tools but their frontend is designed to distract and make you feel lost.

If a retro is needed, that’s when the pretty charts and graphs are useful.

Re: Ask HN: Why did Frontend development explode in complexity?

#147
post #62
post #47

Earlier quoted context omitted.

To be fair most front-end projects have abandoned redux now. It was for sure boilerplate hell.

Tell that to European corporations. Angular + NgRx/NGXS is the de-facto gold standard there.

What were they using before?

Re: Ask HN: Why did Frontend development explode in complexity?

#148
'Backend' work has had longer to be refined.

Backend developers are much more likely to pass leetcode and algorithm questions and have decades and decades of material and languages to draw from. We don't use 1st generation stuff to build anymore.

Once 'frontend' (i.e. browser dev) has close to that much time to cook we'll have a lot better experience with typed language support native in browsers and/or a proper green threads.

I mean, just look at everything that came out of the past ~10 years alone: Coffeescript then Typescript, LESS, SASS, most bundlers, push notifications, webworkers hot reloading, websockets, webrtc, SSE, free/default-on certs, all the component frameworks like bootstrap, tailwind, material ui etc...

While browsers have been around for a while, the ability to use the browser as a full-featured UI is pretty recent and most people working in this area seem to be pretty young.

Re: Ask HN: Why did Frontend development explode in complexity?

#149
post #22

Earlier quoted context omitted.

One of the best examples of this complexity inflation problem I always see is the Redux pattern in frontends. This pattern comes with a lot of overhead, a lot of things that need to line up (Actions, Reducers, Actioncreators, Selectors, ...). And most of the time the applications that use it are completely trivial. If you remove Redux, half of the code is gone, it's faster and easier to understand and extend.

All this complexity is actually a counter reaction to frontend developers not being considered to be real developers. They went overboard trying to prove that they are.

See: microfrontends

Re: Ask HN: Why did Frontend development explode in complexity?

#150
Transpilation.

Imagine if TypeScript/JSX was available native in the browser requiring no transpilation step, and we dropped support for any package requiring some exotic transpilation.

You could easily step through your entire codebase first and thirty-party without battling source-maps or minified files.

Libraries that required adding a compilation step and a complex dev server would be shunned. Having this compilation step in place means it's easy to just pile on tons of functionality, import hooks, AST transformations, etc. which causes the complexity.

Post reply on HN