Ask HN: Why did Frontend development explode in complexity?

Post by bushbaba » Mon, Jan 02, 2023, 7:26 PM UTC

thefourthchime wrote: post #310

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…

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

Post by fredefdef » Mon, Jan 02, 2023, 7:36 PM UTC

Post by z3t4 » Mon, Jan 02, 2023, 7:38 PM UTC

taeric wrote: post #252

peterhunt wrote: post #238

Earlier quoted context omitted.

I didn’t say they were meaningless, just that they are often overused and can make systems needlessly more complex. 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!

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.)

Post by damethos » Mon, Jan 02, 2023, 7:39 PM UTC

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…

Post by JoeyJoJoJr » Mon, Jan 02, 2023, 7:59 PM UTC

andix wrote: post #22

mojuba wrote: post #12

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

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.