Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why did Frontend development explode in complexity?

news.ycombinator.com

Post reply on HN
Print view View original

211–220 of 398 posts

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

#211

Post by prettyStandard »

etimberg wrote: post #21

I think it's generally caused by a few issues: 1. UI development is hard to do well. Throughout my career I've seen complexity explosions in C++/Win32, C#/WPF, and JS UIs so this isn't a new phenomenon 2. It's always easy to develop the correct UI in hindsight once all the requirements are known. When starting out it's hard to know what will be needed or not and this leads to overly complex solutions 3. The browser a…

Long time front end developer here.

This is pretty accurate. I would rank your issues a little differently though.

I think what's different here from other front end development are items 4 and 3.

So 4, 3, 1, 2; I guess.

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

#212

Post by satyrnein »

beardedman wrote: post #160

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.

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

#213

Post by wildrhythms »

trashburger wrote: post #91

Some scattered thoughts: Just today, I built a complex order editing form in vanilla Javascript with AJAX. It's over 900 lines of Javascript where half of the code is state management boilerplate, painstakingly ensuring the correct effects are run when the user changes an order line's quantity or picks another product. We currently can't use libraries with our stack, so it was necessary to write it like this, but it…

I agree with all of this. We are building web 'applications' now, not just websites. Users expect interactivity i.e. state management, animations, modals, dialog boxes... We have moved all of the UI patterns from the operating system into the browser, for better or for worse (probably worse). We have made front-end developers today what used to be Winforms devs, JavaFX/Swing devs, Cocoa devs... but without the basic OS UI frameworks they could build on top of before. Never mind the limitations front-end devs still have to deal with- like being asked to theme a god help you!

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

#215

Post by throwaway9870 »

I think the natural evolution of programmers is to become more capable of building complex systems until you reach the realization that just because you can build it, doesn't mean you should. You then think hard about how to build as simple system as possible. The front-end space hasn't historically struck me as filled with a lot of grizzled systems programmers that have learned this lesson, so we get what we have today. Eventually they will learn and thinks will start becoming more minimal.

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

#216

Post by rgovostes »

In my teens, I could regularly churn out a small GUI program after school in an application like HyperCard, or later REALbasic (now Xojo). I remember writing a saved game editor for Psion Boy[1] which had an editable list of inventory items, fields for character stats, and buttons for saving and loading game files.

I have many more years of experience programming now yet I could not make the same program nearly as quickly. Fire up Xcode and then fumble with storyboards or SwiftUI or IBOutlets? Start writing functional React components on a Bootstrap grid with some live reload script injected into the browser?

Modern frontend tools enable improvements like accessibility, internationalization, cross-platform compatibility, touch screen support, etc. But they have really extinguished my excitement to build anything beyond the command line.

1: https://macintoshgarden.org/games/psion-boy

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

#217

Post by andix »

acemarke wrote: post #162
andix wrote: 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.

Hi, I'm a Redux maintainer. I'll definitely agree that Redux _has_ been overused. But it's also worth understanding _why_ Redux was created in the first place and why it got so popular. As a brief recap: the first major wave of JS MVC frameworks had major flaws. Angular's dirty checking didn't scale and was impossible to debug. Backbone's event-based system led to events ricocheting around the app with no way to trac…

I didn't look into Redux for a while, but RTK looks really good. That's a meaningful evolution.

I never did really complex frontend applications, but once I used React Query or SWR most of the needs for global state were gone. And so the need for Redux.

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

#218

Post by spaceman_2020 »

davedx wrote: post #47
andix wrote: 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.

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?

#220

Post by salawat »

peterhunt wrote: post #167

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 magic, which in a non-AWS system translates to "define queue and message format which will be servicing producer/consumer workers, deploy and start dumping messages in/popping messages out of said queue; scale to taste.

It takes a while to wrap your head around async, but once you get there, you're building with one of the most powerful computing primitives I've yet to come across.

It's just unfortunate that the language and requisite mental model around it is, in my experience, a bit difficult to intuitively reach.

Post reply on HN