As a webdev I actually target older methods in order to get my work done. Is it as "sexy" as a ton of stuff you mentioned? Nope. But I can get a lot done with 20-50 lines of jQuery (or maybe a bit more verbose w/vanilla JS) by directly working with the DOM vs. roping in frameworks in every situation I find myself in. I try to build those "business capable" websites you're mentioning in the first paragraph.
The biggest thing that bothers me is most of us in the industry are "abstraction obsessed" where we would rather have discussions on the complex tools we use vs. how we solve the problem at hand. God help you if you're that one older dev in the back of the room going, "yeah but can't we just throw some vanilla JS/basic jQuery/simple DOM manipulation at that and be done with this?"
Something tells me that you could probably serve a page with almost no JS on it and accomplish the same thing Imgur does, including the comments and monetization stuff, with "server side rendering", which is what we used to just call "CGI serving HTML" until that wasn't trendy enough.
I'll go out on a limb and say that most webdevs (regardless of schooling) can't handle basic "from-scratch" work using a language without a framework... it's terrifying. It's a lot of trend-followers who often can't verbally dictate their decision to use one tool over another (framework, lib, or otherwise).
I have a JS interview question which is, "describe to me the the common nodes one would often leverage in a DOM?" Really all I'm looking for is a basic understanding of the document, element, attribute, and text nodes as those are the ones often interacted with. I'd say about 80% don't have an answer/totally BS one. They still totally get hired though (and I'm seen as the big bad wolf who "thumbs-downs" everyone). This is in Southern California in a major city where there are multiple FAANG offices =|
Webdev has always been a huge variability of skill. You have WordPress "install 50 plugins" "developers" all the way up to top-level programming talent who are just as technically talented as top C/C++ folks (they just target a browser/web server)... and it's incredibly difficult to weed the engineers out from the "devs" in my experience.
> Something tells me that you could probably serve a page with almost no JS on it and accomplish the same thing Imgur does
Yep - and I'll even argue it'd work better (more performant), and be a much more predictable product to develop on and ship!
> which is what we used to just call "CGI serving HTML" until that wasn't trendy enough.
100% agree and actually had a good chuckle at this =)
It moved a lot of complexities from the server side to the client side-- management of state and orchestration of data, turning a single request for a finished page into a whole streak of API hits to populate out a template.
They went for an API-based approach with the thought they could expose it directly for external power users, but the API ends up not even serving their INTERNAL needs well (the information you want for this report is scattered across 12 different tables, but combining them together violates the REST spirit)
I'm not sure it will be faster or more stable than the old code even once they finish optimization. The only user-facing benefit appears to be that they replaced the 200-millisecond flash of white as it loads each page with a 5-second spinning beachball in the template as it collects the data a piece at a time.
I strongly suspect a lot of the motivation was the devs wanting to put some trendier technologies on their resumes.
Otherwise, like you said, it's just rebuilding everything that a capable server-side framework gives you to then run it in the browser with worse UX. I've consistently proven to my team that a server-rendered page with some optional JS on top (Vue is great for this) is 1000x better for users than a giant JS payload just to make API calls and render some HTML.
We run a React SPA, and our backend for initial page load & API is in PHP.
Frontend devs work with backend devs to ensure the critical path of the page can we gathered in 1 request. This usually means having some expand query params on the get request.
We also preload critical API responses in the initial page load to prevent this initial loading indicator.
> I'm not sure it will be faster or more stable than the old code even once they finish optimization. The only user-facing benefit appears to be that they replaced the 200-millisecond flash of white as it loads each page with a 5-second spinning beachball in the template as it collects the data a piece at a time.
If it's a ton of individual web requests there's very little chance that it will optimize anything because it sounds like a lot of HTTP overhead. I've seen this same anti-pattern 1000 times in my career and frankly would rather take the processing onto a very fast webserver that's optimized to crank through stuff like that with some SQL/joins/etc. (ie: doing a few joins on the server side vs. and sending a "view" of the data is WAY more appropriate than putting the responsibility of lots of web requests on your client and increasing your HTTP overhead)...
> I strongly suspect a lot of the motivation was the devs wanting to put some trendier technologies on their resumes.
Yep - and often if that's the case they end up creating a mess of an application that has all sorts of crazy constraints that never needed to be introduced.
---
That being said, new-era anything can be good. Heck - I needed to do the "shotgun a whole bunch of HTTP requests" approach for a GIS mapping solution that would load chunks of data in at a time based on the map's viewport. It just needs to be justified, and most of the time I feel like people just wanna do what they're comfortable with vs. what's a best-fit for the problem.
I personally have no idea why they did this, but I don't presume to know either. However I can add my two cents from the peanut gallery. When it comes to doing something right or wrong, or complex or simple. The bottom line is what does it cost? If you can't finish it in a reasonable amount of time with a reasonable to little or no tech debt, then it's not sustainable for a business. That's the part that literally every level of the peanut gallery ignores when looking at issues like this. And having said all that I still can't seem to imagine why they would want to put that much unnecessary load on their servers, perhaps they get something out of it in return? Perhaps they wanted more control over access to their content, and that required this waterfall loading?
One extremely annoying thing about this is that if your internet is slow, it can take a minute to load the title of the video you're watching. So if e.g. you get linked something without context and you may not actually want to watch it but do want to know what it is, too bad.
The comparison here is, "serving your content, and then doing whatever the heck you want", and "dynamically fetching all of your core content on the fly after synchronously downloading and executing all of the auxiliary content that >85% of your users do not care about."
I think Youtube is overengineered as well, but at least Youtube has the good sense to prioritize loading the video first, and the recommendations/comments second.
It is surreal to jump from a thread with a Google dev telling me that user-agent scraping is necessary because progressive feature detection would require shipping unnecessary polyfills to modern browsers, to a conversation with an Imgur dev telling me that because 5% of their users need a special feature, everyone should wait twice as long to get core content served to them.
I realize these aren't the same people, and the web development community is diverse, but... I don't know how to reconcile those perspectives. We will jump through so many crazy, horrifying engineering hoops to get bundle sizes down: using statistics/user-behavior to calculate dynamic bundles on the fly, user-agent sniffing, compiling Javascript frameworks, prefetching URLs, HTTP2. But serving an img tag with our core HTML is a bridge too far?