Live data from Hacker News

Ask HN: Why did Frontend development explode in complexity?

news.ycombinator.com

321–330 of 398 posts

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

#321
post #33

Earlier quoted context omitted.

TWenty years ago windows development was a lot simpler than modern browser applications. Fire up visual studio and create a new winforms project. You could literally drag and drop your way to a modest application with only minimal programming 'under the hood' for the business logic. I still don't think anything has surpassed the usability of winforms for a developer just wanting to get something done.

I do not think that you would be able to do ActiveX, COM, OLE, MFC, C++ after 2 weeks of bootcamp. Yes, Delphi and Visual Basic simplified many of it but there were still many challenges to develop and ship your software. Just shipping alone and dealing with installers was a challenge by itself. Now compare it with a browser tab and a single click that deploys your code across the globe so it event can run in space o…

My 15 year old Delphi program which runs the whole factory still hasnt been replaced, despite the company and IT staff growing by 10x. Its now taken 4 years, 3 IT Managers and 2 consulting firms to decide Delphi is archaic and it will all be re-written using "cloud and modern frameworks". They have given the team of 3 developers 2 years to do it. Considering they have not managed to keep a developer or IT Manager for longer than 18 months, I would say good luck. I really dont know how anyone gets anything done these days.

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

#322
Regarding frameworks: Things like frameworks have utility in large scale web applications where you need to manipulate a lot of data on screen on the fly. Using the right framework for the right thing can make development and maintenance fat cheaper and faster.

That said, using a framework because other companies are using frameworks is definitely an unnecessary layer of complexity, and most websites don't need to be using React or the like.

Regarding UIs and Designs: companies want their sites to look nice and so they hire designers who may or may not be trained to design for the web. Print design and web design are very different disciplines. You can end up with really strange and poorly performing sites when a design doesn't match up with the reality of browser rendering.

Regarding sites that have huge payloads: this is almost always a product of management/marketing input, and payloads end up ballooning when someone says "can we just add an X pixel" or "can we try this one new piece of tracking software." Is the complexity there necessary? Probably not, but when multiple stakeholders have say, this is probably going to happen.

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

#323

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 think it is a problem that the frameworks smooth over many issues around working with web standards, which means that less successful patterns emerge around working directly with the DOM.

I suspect that amongst all of the patterns, frameworks, and learnings gained from the Nodejs era of web dev, there exists a far more cohesive and scalable way to build front-end app directly on web standards, but this mode of development can’t compete with the shear number of developers working on solutions layers above the standard platform. These solutions have an allure because they have more elegant workflows for very immediate problems (I need to update the DOM based on this state change) but the unstandardised nature of these solutions don’t really help the ecosystem advance to its potential.

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

#324

Earlier quoted context omitted.

So web frontends are great because ... they're incredibly successful. That kind of tautological reasoning doesn't contribute to the discussion tbh. Web frontends are everywhere because recurring payments and/or attention economy approaches are more profitable than classical software sales, simple as that.

Web front ends are great because they truly run on any device without needing to install a binary. They're our only way to permissionlessly reach mobile users (due to mobile duopoly and sandboxed OSes). A web front end can reach billions of users and devices and be deployed in milliseconds.

That doesn't mean that the tech stack/ecosystem is great compared to how good or bad it hypothetically could be while having the property you mention. It's like saying a programming language is great because it is Turing-complete, which, while certainly an important property, is not exactly an encompassing measure of quality.

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

#325

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…

I'm old enough to remember when Flash and Java were hailed as the future of application development because they were "cross platform."

Your "browser made for apps" isn't the dream you're imagining - today's SPAs are miles better, whether they run in-browser or are packaged up as Electron apps.

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

#326
post #145

Earlier quoted context omitted.

I'm a Windows developer and as such I'm biased, but I think Windows apps are dramatically easier to write than web apps. I still use WinForms professionally to this day. Productivity is absurdly high. The number of concerns to worry about is low. The framework has been stable for 20 years and I know all of its quirks, which never change. Fads are ignored. We can zip around with amazing speed. On the other hand, our a…

Would solving these painpoints be a market? Sounds interesting to delve into.

Most of them can be solved by using a more modern but similar toolkit like Jetpack Compose, JavaFX etc. Then you have distribution, but to get rid of the scary warnings just requires you buy signing certificates. Distribution is still a pain after that, but that's why I built Conveyor, to simplify it.

Going further would require remixing bits of Chromium to create a browser-like thing with a sandbox, but which is much less opinionated about what runs inside of it.

Problem is, for there to be a market requires that devs (or someone) pays for it. How much would you pay to be able to not write a web app?

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

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

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?

Curious about your replies and thank-you for your time.

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

#328
post #307

NPM is the Instagram for developers. They produce mostly wrapper packages around standard APIs in order to get some fame. It would be much better if they teach people how to achieve basic stuff without already-baked-in APIs. I'd assume that 80% of the available packages are completely unnecessary, i.e. "I need to set a cookie ... let's download this NPM package" or "I need to make two AJAX requests in order to fetch…

Any link to that YouTube tutorial? It's hard for me to imagine someone who presumably knows how to create CLI scripts not independently coming up with a solution very similar to yours.

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

#329
post #97

At first, only devils used JavaScript. Then jQuery/AJAX/Web2.0 made it permissible for it to be used for good. Then Apple killed Flash. Clients and employers still demanded fancy web sites that weren't just hypertext and images. Browsers still only supported JavaScript. Node and npm enabled front-end devs to build and share. All the tiny problems that front-end devs used to deal with, like minor browser incompatibili…

May I take advantage of your (presumed) typo, to henceforth refer to myself as a JavaScript Devil?

That's good enough for a business card/avatar tag/equivalent, IMO--yeah, I love it!

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

#330
Web 1.0 was very simple programatically:

1. user requests page

2. program generates page

3. user clicks on something.

4. * entire page is regenerated *

Javascript was terribly incompatible across browsers, so it was avoided. Then in 2004 or so, jQuery made it seem easy and desirable to do more than just regenerate the whole page when a user took an action. This introduced all the complexity you see today. React is just the apotheosis of a long sequence of tools whose purpose was to reduce the complexity introduced by jQuery (and "Ajax").

One way to look at it.

Post reply on HN