Unpopular opinion: Because people started thinking it'd be a good idea to treat the browser like an operating system instead of an ardent renderer of interlinked hypertext documents..
Ask HN: Why did Frontend development explode in complexity?
341–350 of 398 posts
Re: Ask HN: Why did Frontend development explode in complexity?
#342Earlier quoted context omitted.
My favorite is when a new project thinks it needs this on day one. I'm willing to place money that most new projects will struggle to saturate a single computer. Much less a distributed infrastructure. (yes, I'm well aware there are some cases. But even most fang projects are doing relatively little work, all told.)
Another reason there is so much complexity is that the computer speed allows it. If you are constrained by processing power you will chose a more simple architecture... until you start optimizing. A lot on unnecessary complexity is premature optimizations. That "web scale" service you are building with "serverless" and other cloud services will likely run fine on a 1$/moth VPS - but who would like to manage such a sm…
It's just so ironic to see this monstrous amount of complexity that is only made tolerable by the massively overpowered hardware beneath it, and which, reduces the throughput of said hardware enough that said complexity becomes necessary.
Re: Ask HN: Why did Frontend development explode in complexity?
#343Early 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…
>1. UIs actually have a lot of complexity. The number of states they can be in is often higher than what you see in other disciplines of software engineering. They also have to contend with managing data fetching over unreliable networks, including balancing bundle size. Additionally they are notoriously hard to test because “does this feel right to a user” is hard to encode programmatically. Ok, reasonable, but othe…
> Ok, reasonable, but other frontend Ui toolkits (eg. Vue, Svelte before Sveltekit, etc.) seem to be able to handle this without going "enterprise" levels of complication.
I've used Vue (2.0) and React extensively. I find them to be pretty equal in terms of complexity on reasonably large projects.
Re: Ask HN: Why did Frontend development explode in complexity?
#344Because the web distribution model for apps is extremely cost efficient. This has caused exponential growth in web app development. To support this, frontend frameworks have grown almost exponentially as well. Every corporate app is a webapp nowadays. This wasn't the case 10 years ago. When we talk about web development, we are now not just talking about websites but about apps as well. So the industry has changed significantly.
UIs always have been complex btw. A lot of different states, and keeping backend and frontend in sync is hard too. So many edge cases need to be considered, orders of magnitude more than in the backend. The UI is also your first line of defense against unexpected user input.
Summarized: (1) app distribution has shifted to the web, (2) UIs are complex
Re: Ask HN: Why did Frontend development explode in complexity?
#345Earlier quoted context omitted.
As much as I hate modern frontend code, I question this narrative. What 20 year old GUI library is running circles around... anything?
Django, bootstrap and a sprinkling of jQuery works really well and results in simple code that can be maintained by a single dev. Bootstrap is only 11 years old. jQuery is 15 years old. Django is 18 years old. jQuery is used by 94% of the websites that use JavaScript. https://w3techs.com/technologies/overview/javascript_library
You're comparing apples and oranges.
Re: Ask HN: Why did Frontend development explode in complexity?
#346Earlier quoted context omitted.
/me remembers MFC/QT/BCGsoft and C++ codebase and gently smiles on thought that maybe the issue are everywhere else except the UI complexity. We are where we are, but it is interesting that GUI libraries from 20 years back are still running circles around latest and the greatest UI web front-end, even if it is also client rendered. Maybe, just maybe, we should search for an issue somewhere else?
As much as I hate modern frontend code, I question this narrative. What 20 year old GUI library is running circles around... anything?
Is there a 10+ year old framework that does responsive UIs well?
Re: Ask HN: Why did Frontend development explode in complexity?
#347Early 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…
>1. UIs actually have a lot of complexity. The number of states they can be in is often higher than what you see in other disciplines of software engineering. They also have to contend with managing data fetching over unreliable networks, including balancing bundle size. Additionally they are notoriously hard to test because “does this feel right to a user” is hard to encode programmatically. Ok, reasonable, but othe…
Every decision is a trade-off. If you call TypeScript complicated, what do you call maintaining a 1000+ component-based web app without types? Please try to understand that every decision is a trade-off. Also, all the major frameworks default to non-TypeScript documentation, so nothing is getting more complicated.
Re: Ask HN: Why did Frontend development explode in complexity?
#348Earlier quoted context omitted.
>1. UIs actually have a lot of complexity. The number of states they can be in is often higher than what you see in other disciplines of software engineering. They also have to contend with managing data fetching over unreliable networks, including balancing bundle size. Additionally they are notoriously hard to test because “does this feel right to a user” is hard to encode programmatically. Ok, reasonable, but othe…
> Ok, reasonable, but other frontend Ui toolkits (eg. Vue, Svelte before Sveltekit, etc.) seem to be able to handle this without going "enterprise" levels of complication. I've used Vue (2.0) and React extensively. I find them to be pretty equal in terms of complexity on reasonably large projects.
For all intents are purposes they are roughly the same. Same ideology, same goal, same developer workflow. Vue has a bit more syntactic sugar which takes away most of the complexity of React (unnecessary rerenders, useEffect hook that has its own book and still no one understands it) at the cost of somewhat leaky abstractions. Vue 3 is a huge step ahead by the way.
Re: Ask HN: Why did Frontend development explode in complexity?
#349It'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…
This. While engaging in flame wars about React I have noticed that all of them start with a peculiar definition of done that, lo and behold, necessitates not only React but whatever feature if the month they are busy ductaping to it. What we need is an honest conversation about what USERS think about spa apps, flat design, etc while holding very obviously interested parties from skewing the narratiwe.
On one hand we are complaining about app store monopolies, and on the other hand the enormously rich web ecosystem with plenty of choice and enormous freedom is also too fragmented/bloated? What is the desired state here?
PS. Needless complexity === I don't understand it so it's useless?
Re: Ask HN: Why did Frontend development explode in complexity?
#350Earlier quoted context omitted.
> 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…
(note: I agree with your approach, just making a point) > that uses the latest Angular But what's the migration plan for the next time Angular goes through a massive ecosystem migration and suddenly you're staring down the barrel of being massively out of date, or investing anywhere from days to months of work running just to stay in place? This is what actually seems to be the problem to me, not just in frontend eit…
Let me ask you: what is the alternative? Life cycle management and building software go hand in hand.