Live data from Hacker News

Ask HN: Why did Frontend development explode in complexity?

news.ycombinator.com

231–240 of 398 posts

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

#231

The lack of objectivity around this is absolutely astonishing from a community such as this. It exploded with complexity because frontend complexity exploded. Simple. Absolutely no people expected an "API call" from a frontend application 20 years ago, now people expect loading indicators on buttons (that make API calls) after pressing them. Just have a look at the comments on the recent Standard Notes / React Native…

In my experience, people don't start out with the goal of loading indicators on buttons. It's usually the mistaken idea that avoiding a page reload will make the action faster. Instead, you now have a slow Ajax call, and the button appears broken, so now it needs a loading indicator.

"a slow AJAX call"? What is even meant by that. Async JS is not slow. It's only limited by the user's connection speed and amount of data to be transferred and server response speed. This is a few dozen milliseconds but can be optimized down to sub 10 ms (the server and latency is the bottleneck not JS). A full page reload will of course take longer because instead of one tiny JSON object you have to send the full HTML back down the wire, and the screen also completely repaints and sets up a whole new DOM structure in memory for the same components.

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

#232
post #200

Early react team member here. The popular react/webpack/npm stack is probably what the OP is talking about. It was popularized because the Instagram web team used webpack and npm in 2013 so we recommended it alongside react in the early days. I was TLM of the team when we made these decisions. There are three main points I want to add to the conversation. 1. UIs actually have a lot of complexity. The number of states…

Don't forget about resume driven development, though that ties in with marketing.

And companies that specifically are looking for developers

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

#233
post #161

Earlier quoted context omitted.

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

Tell me you're not making complex webapps without telling you're not making complex webapps

The publish-subscribe/observer/mediator pattern is perfectly fine for state management, and doesn't need a framework. At most, a small-ish library, but you can also re-implement it yourself quite easily.

Reading your comment, I have the impression you took it as "there shouldn't be any state management necessary", instead of "state management doesn't need a framework" sense.

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

#235
post #187
post #12

It's artificially inflated and I'm seeing this in almost all areas, not just frontend. Some of the projects I've seen could have been reduced in size multiple times with no effect on the outcome whatsoever. In one instance I rewrote a GUI app and made it 15 times smaller (!), that's my absolute record to date. Been wondering for years, so you need to actually be inventive to add unnecessary complexity, it's not that…

"Where is this coming from? Is it because we want our work to look important?" I am intimately convinced it could play a role, at two layers. First, at the framework layer itself: the plethora of propositions seems symptomatic of our approach to dealing with things we don't like. When confronted to the choice of walking the extra mile to improve and contribute to an existing language/framework, or building your own n…

> some architect thinks that segmenting a system into as many components/technologies as possible somehow always makes it more reliable at the end. If I owned a software company, I'd immediately get rid of anyone showing these behaviors. But I have to admit: the bigger the mess, the more hours I can bill :)

I recently greenlit a project that uses the latest Angular, C# REST APIs and a SQL server.

It's clean, it works, it's performant, it's logical and it's maintainable.

And as long as I'm still here, it's staying that way :)

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

#236
post #47

Earlier quoted context omitted.

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

What are people using now? Good old context?

Things like react-query for syncing with server state (which can be most state in web apps) are getting popular, or smaller hook-oriented stores, like zustand, jotai or recoil for true client-side state.

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

#237

Earlier quoted context omitted.

> HTML and CSS weren’t designed to be general-purpose GUI description languages Maybe not, but they are now, and are incredibly diverse in what that can achieve. > HTTP wasn’t designed to be a client-server GUI application protocol. Again, maybe not, but it is now with Websockets, http2 and webRTC. > JavaScript wasn’t designed to be a serious application programming language. Also maybe not initially but it is now in…

So web frontends are great because ... they're incredibly successful. That kind of tautological reasoning doesn't contribute to the discussion tbh. Web frontends are everywhere because recurring payments and/or attention economy approaches are more profitable than classical software sales, simple as that.

Web front ends are great because they truly run on any device without needing to install a binary. They're our only way to permissionlessly reach mobile users (due to mobile duopoly and sandboxed OSes). A web front end can reach billions of users and devices and be deployed in milliseconds.

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

#238

Early react team member here. The popular react/webpack/npm stack is probably what the OP is talking about. It was popularized because the Instagram web team used webpack and npm in 2013 so we recommended it alongside react in the early days. I was TLM of the team when we made these decisions. There are three main points I want to add to the conversation. 1. UIs actually have a lot of complexity. The number of states…

Async queues are far from meaningless. They are the basis of distributed, resumanble/retryable computation. If you can't see the advantage of keeping your processors fed with work as close to 100% of the time as humanly possible, I got nothing for ya. Hell, AWS is basically popular because you can have novice programmers toss up synchronously programmed lambdas, and scale out the underlying infrastructure with Amazon…

I didn’t say they were meaningless, just that they are often overused and can make systems needlessly more complex.

How many microservices architectures with dependent webs of async queues emulating distributed transaction semantics could be replaced by one big rdbms? I think a lot!

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

#239
I'm more of an ops and backend guy, but I used to do a lot of web development in the early days of the web - assembling HTML, a sprinkling of javascript, hand-rolled CSS and embedded styles. In a certain way it was very simple, but in another it was horribly complicated. Sure, the pages we built were simple compared to today, but the tools we had were extremely crude and building a large website required some pretty clever things to stay maintainable. After I started doing more backend stuff, I lost touch with the evolution of Javascript and its various frameworks and I believed everything had become very complex.

Recently, however, for fun I've been tinking with TypeScript and Vue and I have to say, it all seems way easier than how we did it back in the day. CSS seems far more reliable, HTML now has sane ways to lay things out, Typescript/Javascript has evolved wonderfully, and these modern frameworks that isolate components from each other and bundle code, style and layout together are almost a pleasure to use. Sure, there are some concepts you have to learn, and there's so much magic happening behind the scenes it's terrifying. But I'm building stuff I would have spent days on in a matter of hours now and I have no idea what I'm doing.

What I'm noticing now though is that now that frontend development has become a lot more about coding and a lot less about knowing arcana, frontend coders seem to be going through growing pains that are a lot like backend coders have already gone through. For example, it's funny to me to see discussions about how to handle components needing to access shared data. Should you pass the down down through the component hierarchy or have a single global data object that components can interact with, and I'm thinking, next stop, a dependency injection framework. I'm not sure I'm actually right about that, since I've only just played around a little bit. I'd be interested if others would agree with that assessment.

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

#240

Earlier quoted context omitted.

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

This relates in no way to any statement from the comment you replied to. Did you mean to reply to a different comment?

> [..] the most popular state management framework for React [..]

Quoted from the comment they're replying to.

> [..] maybe “state management” is not something you need a framework for?

Quoted from their reply.

Post reply on HN