Live data from Hacker News

Ask HN: Why did Frontend development explode in complexity?

news.ycombinator.com

381–390 of 398 posts

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

#381
post #174

Earlier quoted context omitted.

I find that in larger GUI apps the best thing to have is a layered architecture where visual and non-visual parts are separated globally, not on a view-by-view basis. One advantage of this is that you can slice off your visual part and have something like a "headless browser" variant of your app. Among other things this is good for writing integration tests if you also have a backend. Same trick is impossible or very…

> visual and non-visual parts are separated globally, not on a view-by-view basis Yes, yes, and YES! This is something that confused me greatly over the last years: teams/companies I was in contact with were really struggling getting MVC to work (never mind MV*) and I wasn't...but I wasn't doing anything special, at least not that I could tell. I would implement my model, TDD-style, put minimal views on top, possible…

>>"headless browser" variant of your app

> Exactly. Do this.

> The app is an object. It has an API. It knows how to coordinate its pieces. The local I/O, the remote I/O, any timing stuff. All of it. Then you plonk the UI on > top of that. You can have sub-parts, but you need one piece that ties it all together, on the model side.

This is exactly what I did with all projects I've worked on. It helped that I had to target both, iOS and macOS where sharing "business logic" was crucial, so you were kinda "forced" to think about that.

To put it simply, there is one question I'm asking myself, can I delete UI and then rewrite it from scratch without updating non UIView/NSView code (just calling MyClasses i.e. my APIs)? Let's just say, if I have to write NSSortDescriptor again, that means there is an architectural issue with my code, which has to be fixed.

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

#382
post #347

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

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.

>Every decision is a trade-off.

Sure, the problem is that people are making the trade-off without justifying the decision.

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

#383

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

Everything will get complicated on large projects. The problem, especially the problem pointed out by GP, is that there is a lot of over-complication in smaller projects ... which is most projects!

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

#384

Earlier quoted context omitted.

Does this mean we could fragment an application into, say, a low-level "engine" or "kernel" in C or Rust, an application server to handle requests to it, and the view be any of a React Native mobile app, desktop app, or convenience web API? Please forgive the lack of background of this next question, but does this mean you do not support BFF pattern? Have you heard of Dubray's SAM (State-Actor-Model) approach? Curiou…

> Does this mean we could fragment an application into, say, a low-level "engine" or "kernel" in C or Rust, an application server to handle requests to it, and the view be any of a React Native mobile app, desktop app, or convenience web API? Let me present: Kotlin Multiplatform Mobile[0] (or KMM, a real mouthful I'll grant you). Something I'm very excited about, because you could do exactly that. Seems like an inter…

Sounds neat, thank-you. Have you heard of Java Cuba/Jmix?

From my limited, surface understanding, that is what KMM reminds me of: a way to define UI in Java, which means the entire stack could be in a single language (or mix of JVM languages).

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

#386
post #365

Earlier quoted context omitted.

The bundled apps feels like an odd claim. I don't think of many of those that feel modern. That said, I'm probably not thinking of the right ones. Will try to take a peek at the rest of this list. I don't, oddly, use that many native Mac applications.

> I don't think of many of those that feel modern. This is a bit interesting to me, which bundled apps don't feel modern to you? Mail, Notes, Pages, Safari... they all seem modern enough to me.

Mail has always felt like garbage to me. Notes, I will have to give a try again. Though, really, the entire "office suites" that everyone makes always feels off to me. I will full cede that that is just preference.

Safari feels off, as well. But I'm pretty firmly in camp firefox.

When I think bundled apps, I think of their notepad equivalent. The finder. The calculator. And... that is about it. I remember trying to make a script once, and that script editor left me very very lost.

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

#387
post #92

Earlier quoted context omitted.

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…

> 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 I'm inclined to disagree. One of the most successful web apps I know is a CGI (not FastCGI) app written in Pascal and containing some 30-yo code. 100% of users I met are happy but they don't even know why. "It's good", they say. I believe their underlying reasons are: - the app i…

This! I often build Django apps without any javascript and it's so light weight that the pages render instantly. If there is some interactivity needed then I toss in htmx where needed.

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

#388
post #253

Earlier quoted context omitted.

But here's the thing: you didn't needed COM or ActiveX or MFC in many cases. You could literally wire up and build an up pretty effortlessly. With webdev today we jump directly to very complicated things when 90% of the time they are not needed.

For simple things we still have Excel and Ms Access where people continue to build simple UIs for personal use. At my previous job, our CFO build own framework (Excel) to manage and automate financial reports (which makes him a full-stack developer based on industry standards) I guess the frustration comes from the fact that historically Web started as a set of static HTML files to create/publish documents and we ine…

Picking the wrong tool but also cargo cults. If everyone is a X-developer and is using Y and you are working in X you start to wonder if you should be using Y, right?

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

#389

Earlier quoted context omitted.

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

Just want to highlight something from my original post:

> react is the only way this new crop of devs knows how to do DOM stuff with server side effects

DOM stuff with server side effects, they think they need react to do dynamic DOM stuff, especially if that dynamic DOM stuff affects server side state. So this isn't just about AJAX

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

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

I think there is some truth in that thought. If they spend some of their energy into learning a backend technology, this would be much better spent effort. From my experience frontend-only developers are often very limited in their programming skills. Frontend development has its own complicated challenges, but usually the programming part is quite trivial compared to backend. And a lot of logic inside frontends would be better off in the backend (Full Stack developer speaking here).
Post reply on HN