Comment by danShumway | Hacker News Reader

Comment by danShumway | Hacker News Reader

Parent Full thread

The hoops people are going through to justify this are crazy to me. The comparison is not no-JS vs a business-capable website. They could serve a static image tag that would load quickly, and then load the comments/content around it. Progressive enhancement has been a well-known development pattern on the web for a very, very long time.

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?

It's cargo cult development. I've seen it everywhere I've worked, and have been a huge offender myself. It's the engineer interjecting themselves vs. doing what's best for the end-user: KISS (keep it simple stupid).

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?"

Right on. I think some newer devs come out of school not actually knowing how to implement their own, from-scratch application using vanilla JS or jQuery, so this stuff seems frightening to them; others are obsessed with the (possibly true) idea that the thing they build with React will be more extensible in the future, while discounting the poor fit in the present.

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 think some newer devs come out of school not actually knowing how to implement their own, from-scratch application using vanilla JS or jQuery

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 =)

A company I know has been replacing some pre-Cambrian "Individual PHP-built HTML pages with the occasional JavaScript enhancement" pages with a React-based app. There is a case for updating the site-- it predates responsive design and several corporate rebrandings-- but I'm not sure new-era web tech is actually doing them any good.

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.

Turning every site into a major SPA is the single biggest problem with webdev today. They should only be used for truly complex webapps that need real-time updates and interactivity.

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.

Too be honest that’s just poor development practice.

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.

^^ Also agree on this. I have seen the whole "it has to be RESTful" thing that the parent comment was discussing as a way to justify huge amounts of HTTP overhead too many times however.

Thanks for taking the time to share this - because it's exactly what I feel is happening to webdev as a whole. We're adding unnecessary complexity trying to put everything on the user's browser vs. rendering a sane and functional blob of HTML that just gets the job done + sprinkling in the JS when needed for more interactive needs!

> 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 agree with everything you say. What does Imgur have to say about it? When it's a business the question in mind is not what's best for the user, but what's best for the business and the user. After all that's the reason you do whatever it is you work for right? They are providing a service.

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?

Modern Google apps (Gmail, etc.) are incredibly bloated and buggy compared to the ones from 10 years ago, without any (to me) useful new features, so while I laud one engineer’s principles, it’s not clear they are succeeding at following them as an organization.

The new Gmail was a slap in the face vs. what they had. The older version was so much quicker and performant.

It goes deeper than that. They actually do have plenty of tags in the generated source directly linking to an image, like twitter:image, og:image, image_src, they just don't want you to load the image before you load all their javascript crap.

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

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.

Reply on news.ycombinator.com