Earlier quoted context omitted.
> build apps that scale easily to hundreds of thousands of users I don't understand this. Frontend dev is about writing a portable software to run on as many runtimes as there are users. There is literally nothing to prevent any frontend software, good or bad, to "scale", because scaling in terms of users is nonsical for frontend dev (unless you consider browser compatibility as scaling, to which statement I'm orthog…
Doing most of the work on the client instead of the server can often make scaling much easier. I read your comment as assuming that the division between the server's job and the client's job is fixed, but as the browser has become more powerful many things have moved to the client.
I can only think that modern front end development has failed
171–180 of 521 posts
Re: I can only think that modern front end development has failed
#172Earlier quoted context omitted.
We had functional applications for forms and the like, in the 90s, running on machines with 8MB or 16MB of memory. They weren't as pretty, but they had simple development paradigms, VB and Delphi, easy to get started. HTML has been the wrong place to make creating UIs (as opposed to marked up text) for such a long time. Things are getting better from multiple angles, but it's still very uneven.
It's always easy to solve a problem by taking away a number of it's requirements. VB was good at forms but visually unacceptable for branding. It was difficult and unsafe to deliver over the internet. And again, there were a LOT of really bad VB applications that hurt usability and performance. If all you're doing is building forms for an application then it's acceptable, but that's an easy problem solved with elegan…
Far less usable too.
> It was difficult and unsafe to deliver over the internet
No one cared, we had physical media.
> And again, there were a LOT of really bad VB applications that hurt usability and performance.
Most of them were fast enough.
Re: I can only think that modern front end development has failed
#173Back in the late 90's and early 00's, most websites were largely "brochure" websites. Companies were getting online because they heard about this whole internet thing and they knew they just needed to "get on the internet". You largely saw companies uploading whatever brochure they had basically into a digital one online. Those websites were insanely straightforward. Render a page, static content, the end. Maybe it's a little more dynamic than that, perhaps you're running a basic LAMP stack listing, say, real estate. Query the database, render the page, we're done here. Very little interactivity.
Those websites still exist, but they're likely not the ones we're complaining about. Site's like boeing.com are those traditional brochure sites which deliver very little interactivity. Relatively quick and nimble, the hero image is larger than all the JS they load (and, honestly, they could probably remove most of their JS now - they're using jQuery, modernizer, underscore, stickyMenu, require.js and a bunch of probably unnecessary jquery plugins we can eschew today, but we're here to complain about today, not praise it amirite?).
What we're actually complaining about are usually the interactive sites. Your Twitters, Facebooks, even sites like Reddit that dynamically load content as you scroll, click posts and download more content, comment - all manner of interactivity. Typescript? React? Functional components? Hooks now? Learn Redux? Unlearn Redux? CSS flexbox? CSS grids? My website now has a build process? I used to just edit the PHP file and upload it via FTP. What the hell?
These are not simple "brochure" websites, so yeah, they're more complex. They're applications. And being that they're applications, we shouldn't be comparing them to brochure websites, since they're delivering a completely different experience and have a completely different goal. We should be comparing them to desktop applications and the desktop application development environment, and therefore, comparing their stacks against the likes of C# and WPF, Swift and Cocoa, C++ and Qt or C and GTK.
And compared to those tools, how does the modern web development tool chain stand up? I have no idea, I don't write desktop applications! But what I do know is companies like Slack and Discord have elected to use electron rather than create their products in whatever desktop application framework. VS Code is electron-based and being a Microsoft product they had all the reason in the world not to do that - and it's dominating it is space today. Offerings like Figma, which by all rights one would imagine should have been desktop software elected to be an online tool and has completely shut out the competition.
So if you're going to complain about online applications, don't compare it against an old programming paradigm that would never apply to these products. Compare them against the modern desktop application development experience and let's start the conversation there.
Re: I can only think that modern front end development has failed
#174Earlier quoted context omitted.
Good, and commercially successful, don't always go together. Amazon is commercially successful but few would argue their UX is good.
Amazon's user experience is fantastic. Why else do you think they are so commercially successful?
And AWS.
The web store UX has become appallingly bad - unreliable/fake reviews, tens/hundreds of sellers all roboselling the same identical items from China, poor quality items, unreliable/poor product search ("10TB external hard drive" shows... not many 10TB external hard drives). And so on.
Re: I can only think that modern front end development has failed
#175Re: I can only think that modern front end development has failed
#176Earlier quoted context omitted.
Good, and commercially successful, don't always go together. Amazon is commercially successful but few would argue their UX is good.
Amazon's user experience is fantastic. Why else do you think they are so commercially successful?
Re: I can only think that modern front end development has failed
#177Fundamentally it comes down to the same thing: use appropriate tech. Use it because you should and not because you can. Don't build a SPA if you can do it in a simpler way with plain HTML and CSS. Don't build an app if you need a website. Don't bother with some enormous backend horror if your site is never going to need to scale to that size.
It was the same way back with Flash, dhtml, html5, early JavaScript, CSS, Dreamweaver, whatever - if you need something, use it, if you don't, don't.
Re: I can only think that modern front end development has failed
#178I'd like to add a bit more nuance. Modern frontend development provides many opportunities for failure. These failures often make their way into production. I, personally, get great results with modern FE development. My users are happy. I am happy. It's all very successful. All the defenders of modern FE development will likely chime in with the same sentiment. I also get great results with C, which arguably provide…
Re: I can only think that modern front end development has failed
#179Earlier quoted context omitted.
I read it and feel it's the same as how we perceive modern music. Everyone says music "used to be better" but that's just survival bias. Just like music, there was a LOT of trash web development back in the day as well. Sites built with tables in dreamweaver best viewed on netscape navigator at 800x600 with animated gifs bogging the download speed existed long ago. What we have today are the same problems with a new…
> I read it and feel it's the same as how we perceive modern music. Everyone says music "used to be better" but that's just survival bias. Well, if the top 100 tracks from, say, 1961 to 2021 progressively get less musically diverse, with simpler chords, less harmonies, less timbral variety, lesser melodies, more repeatition, less dynamics, less genre variety, more infantile lyrics (something that has been studied and…
If you can't find more diverse modern music than the top 100 offers today you're not trying that hard.
Re: I can only think that modern front end development has failed
#180Shared frameworks and libraries do help significantly with this but the fact that they still undergo substantial churn tells me they haven't completely solved the problems they address. When's the last time you needed to drop down into Assembly to fix your JavaScript? Probably never—you can operate at that higher level, which lowers barriers to entry and increases productivity for developers. (Put your hand down, you wonderful machine code hobbyist, you.) In contrast, we still "drop down" from web app components into JS/HTML/CSS all the time.