4 ms·

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

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

core-questions 7y ago
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.
- folkhack 7y ago
  > 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 =)
hakfoo 7y ago
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.
- folkhack 7y ago
  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.
kjr247 7y ago
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?

core-questions 7y ago

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.

folkhack 7y ago
> 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 =)

hakfoo 7y ago

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.

folkhack 7y ago
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.

kjr247 7y ago

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?