Live data from Hacker News

Ask HN: Why did Frontend development explode in complexity?

news.ycombinator.com

371–380 of 398 posts

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

#371

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…

> Modern backend eng is a morass of kubernetes configuration, needless microservices and overuse of async queues, for example That's certainly the trend. At my org, we "partnered" with AWS to help us figure out what the tech stack should look like. Sure enough, everything should be in an SQS queue, triggered off S3 running in AWS Step that's triggered through SNS notifications. All this requires countless lambdas whi…

Makes sense that AWS would recommend these stacks (they are probably compliant with their Well Architected Framework), though the idea is to recommend something that can scale de facto infinitely with minimal SMEs required to run it all.

I agree that aiming for the simplest service your team can maintain is the best approach, scaling up as needed.

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

#372

The main reason is because we shoehorn complex apps/ui's into a browser that wasn't made for it. It's not the UI is very complex , or that there are ton of frameworks with different maturity levels. It's because the browser and thus html/CSS was made for documents. If we made a "browser" made for apps, where we didn't need to transpile to js, and didn't need to cater for incompatible browser versions, but could conce…

So, something like Java applets?

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

#373
IMO it's because the bar has gone up, especially from customers.

10 years ago, your social app didn't need to have sub-second response time worldwide while collecting literally everything about user journeys to drive engagement and serve ads, thwart DDoS via scraping or client-side crypto mining attempts, be compatible with mobile and desktop browsers, or be insanely visually appealing and deal with even bigger markup and stylesheet languages that, again, must seamlessly work on mobile and desktop. you didn't really need to have a mobile app that communicates well with frontend.

Also, consumer internet bandwidth, disks, and computers are way faster and cheaper now in the US and Europe than it used to be (and even in developing countries with the proliferation of Starlink). we have facebook machines AND PHONES running m2/a15 Apple Silicon that rivals workstation-class compute at a fraction of their CPUs TDPs. So customers will demand more because they can demand more.

Could we collectively just stayed frozen in 2013 or 2010 when life was simple and browsers weren't operating systems? sure. but clearly the push for more things is working as every tech company is worth more than they used to be back then, even after accounting for today's climate.

TL;DR: capitalism?

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

#374
1. Browsers evolve but the JS ecosystem is competitive so instead of using the brain power to find a common solution to problems we end up with a grid of benchmark of frameworks about how fast it refreshes. I still see job description mentioning Redux while you don't need it 99% of the time or even never.

2. Frontend dev is actually Blog/Video/Trend based development. Simpler tools exists but yeah.. I guess there is a market that feeds on this complexity.

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

#375
The Barrier (tm) has lowered substantially. Let's be honest guys, it is really hard to hire an engineer whom understands the virtues of modern system, and how simply you can work out the most complex logic with it.

It is possible to make beautiful, simple frontend systems today using React and a handful of k8s microservices, just the man who does it is invisible. It is possible to keep integration cost practically free, but these men who keep it are sought with fire. It is possible to use our tools just how they were designed to be used, avoiding bad and worst patterns, but only few of us mastered our tools.

You just need to hire one engineer if you are not and engineer and you didn't walk their shoes for decade and hope for the best of luck. The Javascript and React are not strict tools at all, so they will allow a lot of people to fool you into thinking they are too good.

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

#376
post #359
post #224

Earlier quoted context omitted.

Tailwind got popular because react doesn’t include CSS in components. Angular 1 wasn’t components based and only three people ever used angular 2.

no tailwind became popular because it introduced the concept of "utility css" and was the pioneer of it, if React included css in the components it would have looked like styled/inline javascript or scss/less or css modules, developers do not write their own classnames with tailwind

Utility CSS is the mixin pattern and was widely used for a decade before tailwind existed. This confirms by believe that tailwind is mainly used by people with little to no CSS experience.

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

#378

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…

>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…

I'm sure you know this already but to clarify - Svelte isn't going anywhere and you can still very much use it without SvelteKit

Curious though, what are the problems you see with SvelteKit? It can always be improved!

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

#379
post #258

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…

For me the reason for the explosion in complexity in both frontend and backend comes down to package managers on all platforms getting way better with transitive dependencies and lowering the cost of adding those dependencies. Developers used to be wary of bringing in another dependency just in case it created some conflict, but ecosystems that near-perfectly encapsulate transitive dependencies have gradually done aw…

Ironically, I think more dependencies are actually better, because it means they are smaller. "Do one thing well".

The problem is large dependencies depending on other large dependencies.

Dependencies should advertise their transitive dependency tree size including LOC per dep.

Also, the fact that every dep has it's own non-standard build process, language, dir structure, and ESM/CJS legacy support, makes things not ideal.

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

#380

Earlier quoted context omitted.

In what way is react related to ajax calls? I don't get it :(

The GP is saying that people use react as an ajax abstraction library. It does make some sense. People used to use jquery exactly that way, and react provides an even better interface for ajax. I wouldn't be surprised if most of the usage of react is there just because people don't want to query their servers by hand.

> react provides an even better interface for ajax

how does react provide an interface for ajax? react does literally no calls at all...

I feel like 50% of the people complaining in this thread have never touched react or their last interaction with frontend code was jquery 15 years ago and they're still carrying those learned paradigms around and applying them to every new framework/ frontend lib they come across

Post reply on HN