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.
Ask HN: Why did Frontend development explode in complexity?
231–240 of 398 posts
Re: Ask HN: Why did Frontend development explode in complexity?
#232Early 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.
Re: Ask HN: Why did Frontend development explode in complexity?
#233Earlier 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
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?
#234Re: Ask HN: Why did Frontend development explode in complexity?
#235It'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…
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?
#236Earlier 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?
Re: Ask HN: Why did Frontend development explode in complexity?
#237Earlier 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.
Re: Ask HN: Why did Frontend development explode in complexity?
#238Early 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…
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?
#239Recently, 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?
#240Earlier 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?
Quoted from the comment they're replying to.
> [..] maybe “state management” is not something you need a framework for?
Quoted from their reply.