Live data from Hacker News

Ask HN: Why did Frontend development explode in complexity?

news.ycombinator.com

291–300 of 398 posts

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

#291
post #191

Earlier quoted context omitted.

MVVM: yes, in most cases. There are some cases where it's a godsend, but most of the uses I have seen are ... not entirely sane. But MVC? That's pretty minimal in terms of what you're going to do anyway if you have functionality (model) and will be interacting with it (view). Controllers are often misunderstood, and in the case of Apple massively misapplied (Massive View Controllers).

Agreed on that controllers are often misunderstood. I saw them to become both: a view and a model at the same time. :(

What's important to realise is that the elements in MVC are roles not entities.

So for example Views in Cocoa actually fulfil both the View and (largely) the Controller role.

Which is why ViewControllers confused me greatly when they came out. Like they confuse most of the Apple-ecosystem code out there these days. While I do understand how they got there, that doesn't make it better...

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

#292
I'd say this is the result of huge investment bubble in IT companies, where nobody cared enough of efficiency of workforce.

Everybody seems to care of hardware efficiency, because it's very measurable. For example, if CPU is overloaded, an extra virtual or dedicated machine costs a lot, or a daily script works 10 hours and may result in serious troubles -- everybody gets bothered.

But if you add complexity and devs must work a month instead of 1 week on a simple task -- this passes under the radar, because devs unlike CPUs are busy 100% time always. That projects start to take longer, probably gets attention, but many just considered hiring an extra guy.

This probably lead many to consider heavy and complex projects, like Airflow, worthy -- because the costs were not considered seriously, and apart them, the selling point (configuration with some clicks, and launching a task by a click), was in a favorable false dichotomy.

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

#293

All I have to say to this is we recently rebuilt our admin tools application and the team responsible have been all backend / devops engineers. Stack is React and GraphQL. Without having any real FE experience this team has been absurdly productive. Rewind the clock a bit and it would have been a nightmare. From this experience alone I can conclude that the complexity issue the OP is citing is mostly an illusion, ass…

Things are getting better, but it is still pretty easy to get into a circular dependency of NPM packages that makes it really hard to upgrade

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

#295
post #42
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.

Same for MVC/MVVM and Co specifically on mobile. These things were created to teach beginners a few important concepts, mainly separation of concerns. MVC/MVVM work well on toy sample projects with 2-3 pages but can ruin a larger project. Somehow wherever I'm seeing MVVM applied there's also messy, buggy, impenetrable code around it. I don't think it's a coincidence.

Out of curiosity, what's fashionable these days? As opposed to MVC?

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

#296
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.

Savage, but a very interesting take.

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

#297
post #92

Earlier quoted context omitted.

This. No user wakes up and says, "I gots to find me a UI built with React* today, or I'm going to cry." Ever. Users. Don't. Care. We keep adding tech and tools and experiences - if you asked users - aren't improving all that much. * Or whatever technolgy being championed.

I dunno. Lots of users seem to wake up and say “Gimme a UI with rich interactions, super low latency, offline support, and real-time sync.” Even for B2B “back-of-office” software, the standards for software usability are really high, especially for new entrants. Those kinda features are hard without a pretty complex frontend. Not saying those things are always necessary, or that people don’t add bells and whistles wh…

> Gimme a UI with rich interactions

You sure? Because all I hear on daily basis is "please don't make me learn new shit" and "get these annoying ads out of the way". Web is so "rich" these days that disabling Adblock should come with epilepsy warning.

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

#298

All I have to say to this is we recently rebuilt our admin tools application and the team responsible have been all backend / devops engineers. Stack is React and GraphQL. Without having any real FE experience this team has been absurdly productive. Rewind the clock a bit and it would have been a nightmare. From this experience alone I can conclude that the complexity issue the OP is citing is mostly an illusion, ass…

Things are getting better, but it is still pretty easy to get into a circular dependency of NPM packages that makes it really hard to upgrade

Yeah, I definitely know this through painful experience, but historically library upgrades in non-trivial apps have always been difficult. It is what it is, and its the same in every stack.

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

#299

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 other frontend Ui toolkits (eg. Vue, Svelte before Sveltekit, etc.) seem to be able to handle this without going "enterprise" levels of complication.

>2. The grass isn’t greener on the other side. I see a lot of people complaining about the needless complexity of the frontend stack but I don’t think they’ve worked in a modern backend engineering or data engineering project. Modern backend eng is a morass of kubernetes configuration, needless microservices and overuse of async queues, for example. Feels a lot like frontend in terms of accidental complexity. So I’d argue that this is less of a frontend problem and more of an industry wide thing (cynically, it might be a ZIRP thing)

This isn't a counterpoint, it is just pointing out that, well everything is getting more complicated. (more on that in a sec)

>3. With that said there certainly is needless accidental complexity in frontend and I am convinced content marketing is 100% to blame. An easy way to hire engineers is to create an open source project and write a blog post convincing people to use it. This is good for the company and good for the careers of the engineers who worked on it, but can cause people to needlessly complicate their tech stack if they can’t cut through the noise.

Ok, this is more to the point and gets to the real crux of the issue, but I don't think it goes all the way.

Every framework that has ever been adopted widely has been later complicated more and more to make it "enterprise-y".

Look at some early JavaScript (used to make webpage counters and fancy menus) and look at some modern Typescript, which is almost indistinguishable from enterprise Java and used as a basis for SaaS startups.

As soon as "professionals" get involved, it starts getting complicated. Every framework is susceptible to this if there is any amount of adoption.

Look at my beloved original Svelte. Now go look at the absolute shit-show that is the latest Sveltekit! (granted it is still better than the alternatives!)

To your second item above, look at how relativity easy it was to monitor or restart some monolithic projects back in the day with some simple scripts, email, and cron jobs, now it is, as you say, a "morass of kubernetes configuration, needless microservices and overuse of async queues". Literally make-work for the sake of itself in many cases!

Why?

It worked before, why is this necessary? It is the "enterprization" of everything and I agree with your third point that a big component of this is content marketing.

But at the end of the day it is more about the concept of "feeling professional". I mean, if you can teach someone how to program in JS in a couple of afternoons, how can you seriously justify $150k salaries and 3 levels of middle and project management to oversee such a thing?

The original canonical edition of this was JAVA. It was amazing seeing it go from where it started to the, almost satirical, levels of "enterprization" today. The modern version of this is JavaScript.

In both cases complication was added to make it more "serious" not necessarily to make it any better.

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

#300
My theory and personal opinion.

In the past, we didn't have complex UIs, we did, but we dealt with them differently. For example, in the era of forms and limited Ajax, keeping the DOM synced with the state took a lot of work.

The complexity we see today results from different ideas of how to deal with that _synchronicity_.

Keep in mind that there's no way to do it natively; the only way to do it is to manually keep the state in sync. The complexity we see today results from the abstractions people have created to accomplish that, e.g., jQuery, Sammy, Backbone, Knockout, Angular, Ember, React, Vue, Svelte, etc.

Enterprise and FAANG required optimizations for different reasons, scale, collaboration, distribution, etc. Programmers wanted to use paradigms to represent things and apply optimizations on the web, and JavaScript wasn't enough. So, they created CoffeeScript, Flow, TypeScript, ReasonML, etc. These tools became popular in the FAANG, wrote posts about them, then people of all industries adopted them.

To use all these cool tools, people created bundlers—each with its configurations, patterns, and philosophies—gulp, Rollup, Webpack, etc.

At this point, the web skyrocketed in complexity from the days of HTML, CSS, and JavaScript when one of the complex tasks was to make rounded corners with images and cool layouts with tables. Of course, you can still build complex UI without these tools and use JavaScript alone, but you will end up abstracting your patterns and paradigms into reusable bits.

Additionally, some developers attempt to use as little JavaScript as possible; one great example of a complex UI trying that is https://sourcehut.org.

Post reply on HN