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…
Ask HN: Why did Frontend development explode in complexity?
321–330 of 398 posts
Re: Ask HN: Why did Frontend development explode in complexity?
#322That 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?
#323Some 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 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?
#324Earlier 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.
Re: Ask HN: Why did Frontend development explode in complexity?
#325The 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…
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?
#326Earlier 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.
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?
#327Earlier 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…
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?
#328NPM 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…
Re: Ask HN: Why did Frontend development explode in complexity?
#329At 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…
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?
#3301. 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.