4 ms·

>When on a 1Mbit/s WiFi connection in Greece, my vanilla app loaded in 4 seconds and started rendering after ~2 seconds, while the React/Redux app took 50 secon

>When on a 1Mbit/s WiFi connection in Greece, my vanilla app loaded in 4 seconds and started rendering after ~2 seconds, while the React/Redux app took 50 seconds to first render! This never ceases to puzzle me. I thought yuppie framework jockeys love to travel. Don't they ever find themselves at some remote locale, try to check in on things, and realize that their site runs like pure ass outside of costal North America? Do they just not care? Simplicity really can be a class issue. Lots of developers seem to write code with their own demographic in mind, rather than the real people who have to put up with their bullshit.

rlonn 8y ago
Yeah, it's very useful to try out your own code on the crappiest infrastructure possible and see how it works. In this case the developers of the React app were inexperienced students so I think they may be forgiven, but having worked with performance the past 15 years I really agree that far too few developers make the effort to verify the performance of their code. And like you say it's probably just a case of not eating your own dogfood.
- jplayer01 8y ago
  > it's probably just a case of not eating your own dogfood. I agree, though I'd qualify it because I'm sure they're testing the site, but it's on a fat pipe with low latency that easily hides any performance issues. It doesn't seem limited to web development though - game development seems to have the same issue, where it's clear devs are playing and testing on overpowered rigs with little regard for low-end systems.
  - TeMPOraL 8y ago
    In gamedev there's a much higher awareness of performance, because in most cases, low performance creates a literal cut-off point - anyone with specs lower than what your game maxes out can't play, thus won't pay. Web developers get away with more bullshit, because monetization is more indirect, and quite often the site is not just entertainment, so users have stronger reasons to bear with it, frustration and battery life be damned.
ng12 8y ago
I haven't written a line of code that ran outside of a corporate network in years. Comments like this show how ignorant HN is about what "framework jockeys" actually do.
- joshstrange 8y ago
  Amen, my code mainly runs outside my company but this 1000000x over. SOOO many people on HN seem to think the entire world works exactly like they do on the same kinds of things. It seems outside of most people's understanding that, maybe, just maybe, the business conditions where someone else works are.... different GASP. It's not the same thing but it's a pet peeve for me when people make comments like "How could a developer skip X or not do Y?!?" Well not all of use can pick 100% what we work on and are sometimes forced to cut corners. We aren't happy about it but we are more happy with taking home a paycheck that being right 100% of the time. My go-to is "Is this this hill I want to die on?" when this stuff comes up.
- rlonn 8y ago
  Sorry to hear that! I consulted a year for a large financial company and their trading platform consisted of a million lines of C code. I've always loved C, but looking at the code it was actually hard to tell which language it was. They were using internally-developed libraries to do everything. Practically every line of code was a macro or library call, or a macro calling a library. I guess it makes sense to standardise, modularize, abstract away things to a ridiculous degree when you're working on very large codebases, with many people. I'm happy I don't have to do that anymore though!
- TeMPOraL 8y ago
  Not really. GP's comment is borne out of frustration with public-facing Internet, built by those framework jockeys. It doesn't mean the same problem isn't happening over at corporate. Speaking of which, having worked a bit in corporate setting, I have my own extra point of hatred here too: I saw perfectly good, if crappy looking, server-side, plain HTML intranet apps replaced with most recent JavaScript framework shitfest, making my life extra miserable as I suddenly had to deal with some apps I was forced to use stealing computing resources from the very job I had to do.
andy_adams 8y ago
I'm on rural (satellite) internet sometimes, with decent bandwidth but terrible ping times (500+ ms). Certain JS-heavy pages just don't load! It's like the dev set a timeout on AJAX of 400ms, and when it doesn't return, I just see empty boxes everywhere. If you build websites, come spend some time in rural Idaho - it'll change how you develop!
- kevin_thibedeau 8y ago
  This is a browser problem. I get the same issue working on IoT devices with limited number of inbound connections. If they can't open up their 6 sockets, all of the mainline browsers fail to consistently reuse existing connections for missing resources.
georgefrick 8y ago
I do love to travel. I will write your app in Backbone, Angular, or React, or ??? depending on what we're building. It's hard to reply in a mature and productive way here; since you've called what some people do... bullshit. There is no silver bullet here that is the correct technical choice for all situations, and using some bad choices to say we're all making bad choices is short sighted. You could write a similar article about how people don't test, performance test, security test, or many 'tests'. We could have the same discussion. Not every situation is the same, and not every user is in a remote locale with no connection; but when they are we have to take that into account. If our app is for a north american bank in the midwest; then yes - why would we care about performance in the middle of Australia? Out in the real world, projects have priorities; from the customer, business, security, and even team (someone will have to take care of it). I don't appreciate the constant Slashdot style negativity going on in this and many other threads these days on HN. I wish you'd reconsider adding something constructive to the discussion.
- happy_man 8y ago
  I also work in the "real world", that doesn't mean I will build an inefficient untangled mess just because I am told the users of this software will have the computing power of NASA. Professional ethic.
woah 8y ago
I’m very puzzled. You are operating from the assumption that 34 kB would take 50 seconds to download on a 1mbs connection? There was clearly something else at play, maybe related to the fact that the people who built his react codebase had never programmed before.
- rlonn 8y ago
  I'm not operating from any assumptions, I am just stating observations. The observations were: - ~6MB JS file produced by `npm run build` compared to ~400KB page weight for all items in my vanilla app - Page load times from that Greek WiFi was ~4 secs for the vanilla app and ~50 secs for the React app, which told me the throughput was on the order of 1 Mbit/s. The React app didn't load many things (about 3 resources, if I remember correctly) while my app had more to do. This means network or server delay will have mainly affected load time of my app. Of course, this whole performance/page weight thing wasn't the main point of the article (for those who happened to read it), nor did it very much affect my decision to go vanilla. I am surprised it became such a big issue here, but I've stated that I too think it was due to inexperienced developers. I guess my mistake was thinking that my lack of front-end experience would make it a viable comparison - I'm probably a lot more performance-conscious than most, and especially compared to someone who is just learning to program.
bouncing 8y ago
Framework jockey here. I spin Vue bullshit. I also sold all my crap a few years ago and started traveling full-time, mostly in South America. Something to consider: 1. If the server render is slow, everyone notices. 2. If the client download is slow, only people on slow connections notice and only then if it's not cached. So in other words, your CUSTOMER on a fast connection might notice #1, but probably won't notice #2. I'm not defending unoptimized code exactly -- I'm just pointing out that if the person paying the bills doesn't notice a problem, it's far less likely to get fixed.

rlonn 8y ago

Yeah, it's very useful to try out your own code on the crappiest infrastructure possible and see how it works. In this case the developers of the React app were inexperienced students so I think they may be forgiven, but having worked with performance the past 15 years I really agree that far too few developers make the effort to verify the performance of their code. And like you say it's probably just a case of not eating your own dogfood.

jplayer01 8y ago
> it's probably just a case of not eating your own dogfood. I agree, though I'd qualify it because I'm sure they're testing the site, but it's on a fat pipe with low latency that easily hides any performance issues. It doesn't seem limited to web development though - game development seems to have the same issue, where it's clear devs are playing and testing on overpowered rigs with little regard for low-end systems.
- TeMPOraL 8y ago
  In gamedev there's a much higher awareness of performance, because in most cases, low performance creates a literal cut-off point - anyone with specs lower than what your game maxes out can't play, thus won't pay. Web developers get away with more bullshit, because monetization is more indirect, and quite often the site is not just entertainment, so users have stronger reasons to bear with it, frustration and battery life be damned.

ng12 8y ago

I haven't written a line of code that ran outside of a corporate network in years. Comments like this show how ignorant HN is about what "framework jockeys" actually do.

joshstrange 8y ago
Amen, my code mainly runs outside my company but this 1000000x over. SOOO many people on HN seem to think the entire world works exactly like they do on the same kinds of things. It seems outside of most people's understanding that, maybe, just maybe, the business conditions where someone else works are.... different GASP. It's not the same thing but it's a pet peeve for me when people make comments like "How could a developer skip X or not do Y?!?" Well not all of use can pick 100% what we work on and are sometimes forced to cut corners. We aren't happy about it but we are more happy with taking home a paycheck that being right 100% of the time. My go-to is "Is this this hill I want to die on?" when this stuff comes up.
rlonn 8y ago
Sorry to hear that! I consulted a year for a large financial company and their trading platform consisted of a million lines of C code. I've always loved C, but looking at the code it was actually hard to tell which language it was. They were using internally-developed libraries to do everything. Practically every line of code was a macro or library call, or a macro calling a library. I guess it makes sense to standardise, modularize, abstract away things to a ridiculous degree when you're working on very large codebases, with many people. I'm happy I don't have to do that anymore though!
TeMPOraL 8y ago
Not really. GP's comment is borne out of frustration with public-facing Internet, built by those framework jockeys. It doesn't mean the same problem isn't happening over at corporate. Speaking of which, having worked a bit in corporate setting, I have my own extra point of hatred here too: I saw perfectly good, if crappy looking, server-side, plain HTML intranet apps replaced with most recent JavaScript framework shitfest, making my life extra miserable as I suddenly had to deal with some apps I was forced to use stealing computing resources from the very job I had to do.

andy_adams 8y ago

I'm on rural (satellite) internet sometimes, with decent bandwidth but terrible ping times (500+ ms). Certain JS-heavy pages just don't load! It's like the dev set a timeout on AJAX of 400ms, and when it doesn't return, I just see empty boxes everywhere. If you build websites, come spend some time in rural Idaho - it'll change how you develop!

kevin_thibedeau 8y ago
This is a browser problem. I get the same issue working on IoT devices with limited number of inbound connections. If they can't open up their 6 sockets, all of the mainline browsers fail to consistently reuse existing connections for missing resources.

georgefrick 8y ago

I do love to travel. I will write your app in Backbone, Angular, or React, or ??? depending on what we're building. It's hard to reply in a mature and productive way here; since you've called what some people do... bullshit. There is no silver bullet here that is the correct technical choice for all situations, and using some bad choices to say we're all making bad choices is short sighted. You could write a similar article about how people don't test, performance test, security test, or many 'tests'. We could have the same discussion. Not every situation is the same, and not every user is in a remote locale with no connection; but when they are we have to take that into account. If our app is for a north american bank in the midwest; then yes - why would we care about performance in the middle of Australia? Out in the real world, projects have priorities; from the customer, business, security, and even team (someone will have to take care of it). I don't appreciate the constant Slashdot style negativity going on in this and many other threads these days on HN. I wish you'd reconsider adding something constructive to the discussion.

happy_man 8y ago
I also work in the "real world", that doesn't mean I will build an inefficient untangled mess just because I am told the users of this software will have the computing power of NASA. Professional ethic.

woah 8y ago

I’m very puzzled. You are operating from the assumption that 34 kB would take 50 seconds to download on a 1mbs connection? There was clearly something else at play, maybe related to the fact that the people who built his react codebase had never programmed before.

rlonn 8y ago
I'm not operating from any assumptions, I am just stating observations. The observations were: - ~6MB JS file produced by `npm run build` compared to ~400KB page weight for all items in my vanilla app - Page load times from that Greek WiFi was ~4 secs for the vanilla app and ~50 secs for the React app, which told me the throughput was on the order of 1 Mbit/s. The React app didn't load many things (about 3 resources, if I remember correctly) while my app had more to do. This means network or server delay will have mainly affected load time of my app. Of course, this whole performance/page weight thing wasn't the main point of the article (for those who happened to read it), nor did it very much affect my decision to go vanilla. I am surprised it became such a big issue here, but I've stated that I too think it was due to inexperienced developers. I guess my mistake was thinking that my lack of front-end experience would make it a viable comparison - I'm probably a lot more performance-conscious than most, and especially compared to someone who is just learning to program.

bouncing 8y ago

Framework jockey here. I spin Vue bullshit. I also sold all my crap a few years ago and started traveling full-time, mostly in South America. Something to consider: 1. If the server render is slow, everyone notices. 2. If the client download is slow, only people on slow connections notice and only then if it's not cached. So in other words, your CUSTOMER on a fast connection might notice #1, but probably won't notice #2. I'm not defending unoptimized code exactly -- I'm just pointing out that if the person paying the bills doesn't notice a problem, it's far less likely to get fixed.