5 ms·

Bad software development slows the web down This is an empty statement and another overly simplistic answer. Of course bad software development slows the web d

Bad software development slows the web down This is an empty statement and another overly simplistic answer. Of course bad software development slows the web down, because you're defining slow web sites as being badly developed.

hansel_der 6y ago
> because you're defining slow web sites as being badly developed whats wrong with that? living throu the computers/internet/web for 25 years i can attest that there is truth in wirth's law, if only that folks are lazy.
- vlovich123 6y ago
  Op is pointing out the argument is tautological and doesn’t add anything insightful to the discussion. All tautological statements are true. You could similarly write: “Lazy software development is why websites are slow because slow websites are caused by lazy development.” “Greedy business practices are why websites are slow because advertising slows down the web and advertising is the result of greedy business practices”. These are feel good statements that don’t actually provide any insight on the market forces at play nor provide any path to improving things.
  - dimitrios1 6y ago
    It's a misreading of the point I was making. I was refuting the claim "javascript slows the web down" by qualifying it with "bad javascript slows the web down"
    - nightski 6y ago
      Right, but then you conclude that it is just incompetent engineering. That may be true in some cases, but in a lot of cases it's because it's not worth it to the business in terms of time or resources to do good engineering. Great engineering is not just about having great engineers, but a huge budget because it's very, very expensive.
      - dimitrios1 6y ago
        Whatever the causes may be, the end result is poor engineering. I didn't say incompetent, but rather lazy and lower quality. Reading further into my point, I mention that often time this carelessness comes as a result of businesses pressing without giving attention to proper resources. But nonetheless, the end result of all of a businesses choices: hiring decisions, budget decisions, scheduling decisions, feature prioritizations, all the same result in the root cause of poor engineering.
        Xevi 6y ago
        > "Whatever the causes may be, the end result is poor engineering. I didn't say incompetent, but rather lazy and lower quality." The engineering might be perfectly fine if you take into account the deadlines, budgets and requirements from the clients/managers. If you pay someone to build a house on a short deadline with a small budget, then you'll obviously get a crappy house. But the skill that went into building that house in such a short time, and on such a low budget, might be extremely high. Good engineering doesn't mean a perfect product. It just means you managed to deliver the best possible one out of the situation you were in. It's up to the owner of the product to decide if it's good enough.
    - chriswarbo 6y ago
      No true scotsman would slow the Web down
      - dimitrios1 6y ago
        argumentum ad logicam. And around and around we go.
        chriswarbo 6y ago
        Nope. From https://en.wikipedia.org/wiki/Argument_from_fallacy https://en.wikipedia.org/wiki/Argument_from_fallacy > Argument from fallacy is the formal fallacy of analyzing an argument and inferring that, since it contains a fallacy, its conclusion must be false. Nobody here is claiming that the parent's statement is false. We're saying it's true! However, we're also saying it's useless (i.e. "vacuously true" or "tautologically true"). The parent is saying that many Web sites contain JS; the slow ones are due to "bad JS" (and implicitly, that the non-slow ones have non-bad JS). How can we tell whether some JS is "bad"? By checking if it's slow. Let's say we do that, and find that the site is slow, and hence our JS is "bad". How can we improve it, to get non-bad JS? No idea; maybe getting a bunch of developers to make random refactorings, measuring the speed of each, using that to tell whether the JS is still "bad", and stopping once it's no longer slow and hence no longer "bad"? In which case, the whole notion of "bad JS" is irrelevant; it's conceptually indistinguishable from "slow page", and hence adds nothing to the discussion (i.e. if we followed the above steps, we would get exactly the same result if we ignore all the stuff about "bad JS" and just use the timing measurements directly). Note that the concepts of "slow page" and "page with JS" are not vacuous, since we can measure them (with a clock, and by parsing the page source, respectively) and hence make falsifiable predictions about correlations and causal relationships between them.
  - hansel_der 6y ago
    i see. thx for explaining and sry for the noise
dimitrios1 6y ago
Touché -- I am attempting to make a distinction between the general statement of "javascript slows the web down" to a certain type of Javascript slows the web down, namely lazy and careless Javascript slows the web down. We reach for the dependency first instead of carefully analyzing our requirements and making an engineering decision. I've seen it countless times, fallen victim to it a few times myself. It's really easy to do. No one stops to ask, "perhaps we do not need a hard dependency, and need to include that 15kb library, but rather just need a few functions from it?" or "perhaps a simple algorithm would indeed suffice." We mindlessly reach for complex regex engines to solve simple parsing problems, try to garner "functional programming cred" by reaching for a series of collection functions from our favorite 50kb utility package when a simple c-style for loop would have not only sufficed, but indeed got the job done much faster. All this results in bloated, unoptimized javascript bundles. To top it off, we under cache, and aggressively cache bust, and ship unminified bundles with oodles of source maps because of "developer experience" I can't tell you how many times I see, to this day, a fortune 500 company bundling an entire unminified javascript framework. Wirth's law indeed. Hope this was a little less empty. These are my observations having done this for a few decades now and managing developers these days.
- joosters 6y ago
  I agree with all you are saying, but I wonder how much this actually comes down to software developers. I suspect (but have absolutely no data!) that for many sites, the pressure to add extra stats, tracking, advertising, monitoring, etc etc, comes from 'above' and it's not the developers' choice to add these mountains of javascript libraries to their sites. Perhaps they should push back, but what leverage do the developers have?
- trhway 6y ago
  pretty much like enterprise software. The similar situation allows for an obvious for many conclusion - there is no money in performance, or more exactly the opportunity cost of performance is higher than benefit.
TimPC 6y ago
I'll try and offer the more controversial point. Good software development can slow the web down. People are often optimizing for code reusability, code quality, ease of debugging and other advantages of some heavyweight frameworks rather than raw load time. Often this is the right call as engineering is a cost centre. Where it goes wrong is when things get too slow and too bloated to the point you're actually having people abandon the site before load but most of the major frameworks used properly don't offer that extreme a tradeoff. I also have no idea what % of these sites have reached that level.

hansel_der 6y ago

> because you're defining slow web sites as being badly developed whats wrong with that? living throu the computers/internet/web for 25 years i can attest that there is truth in wirth's law, if only that folks are lazy.

vlovich123 6y ago
Op is pointing out the argument is tautological and doesn’t add anything insightful to the discussion. All tautological statements are true. You could similarly write: “Lazy software development is why websites are slow because slow websites are caused by lazy development.” “Greedy business practices are why websites are slow because advertising slows down the web and advertising is the result of greedy business practices”. These are feel good statements that don’t actually provide any insight on the market forces at play nor provide any path to improving things.
- dimitrios1 6y ago
  It's a misreading of the point I was making. I was refuting the claim "javascript slows the web down" by qualifying it with "bad javascript slows the web down"
  - nightski 6y ago
    Right, but then you conclude that it is just incompetent engineering. That may be true in some cases, but in a lot of cases it's because it's not worth it to the business in terms of time or resources to do good engineering. Great engineering is not just about having great engineers, but a huge budget because it's very, very expensive.
    - dimitrios1 6y ago
      Whatever the causes may be, the end result is poor engineering. I didn't say incompetent, but rather lazy and lower quality. Reading further into my point, I mention that often time this carelessness comes as a result of businesses pressing without giving attention to proper resources. But nonetheless, the end result of all of a businesses choices: hiring decisions, budget decisions, scheduling decisions, feature prioritizations, all the same result in the root cause of poor engineering.
      - Xevi 6y ago
        > "Whatever the causes may be, the end result is poor engineering. I didn't say incompetent, but rather lazy and lower quality." The engineering might be perfectly fine if you take into account the deadlines, budgets and requirements from the clients/managers. If you pay someone to build a house on a short deadline with a small budget, then you'll obviously get a crappy house. But the skill that went into building that house in such a short time, and on such a low budget, might be extremely high. Good engineering doesn't mean a perfect product. It just means you managed to deliver the best possible one out of the situation you were in. It's up to the owner of the product to decide if it's good enough.
  - chriswarbo 6y ago
    No true scotsman would slow the Web down
    - dimitrios1 6y ago
      argumentum ad logicam. And around and around we go.
      - chriswarbo 6y ago
        Nope. From https://en.wikipedia.org/wiki/Argument_from_fallacy https://en.wikipedia.org/wiki/Argument_from_fallacy > Argument from fallacy is the formal fallacy of analyzing an argument and inferring that, since it contains a fallacy, its conclusion must be false. Nobody here is claiming that the parent's statement is false. We're saying it's true! However, we're also saying it's useless (i.e. "vacuously true" or "tautologically true"). The parent is saying that many Web sites contain JS; the slow ones are due to "bad JS" (and implicitly, that the non-slow ones have non-bad JS). How can we tell whether some JS is "bad"? By checking if it's slow. Let's say we do that, and find that the site is slow, and hence our JS is "bad". How can we improve it, to get non-bad JS? No idea; maybe getting a bunch of developers to make random refactorings, measuring the speed of each, using that to tell whether the JS is still "bad", and stopping once it's no longer slow and hence no longer "bad"? In which case, the whole notion of "bad JS" is irrelevant; it's conceptually indistinguishable from "slow page", and hence adds nothing to the discussion (i.e. if we followed the above steps, we would get exactly the same result if we ignore all the stuff about "bad JS" and just use the timing measurements directly). Note that the concepts of "slow page" and "page with JS" are not vacuous, since we can measure them (with a clock, and by parsing the page source, respectively) and hence make falsifiable predictions about correlations and causal relationships between them.
- hansel_der 6y ago
  i see. thx for explaining and sry for the noise

dimitrios1 6y ago

Touché -- I am attempting to make a distinction between the general statement of "javascript slows the web down" to a certain type of Javascript slows the web down, namely lazy and careless Javascript slows the web down. We reach for the dependency first instead of carefully analyzing our requirements and making an engineering decision. I've seen it countless times, fallen victim to it a few times myself. It's really easy to do. No one stops to ask, "perhaps we do not need a hard dependency, and need to include that 15kb library, but rather just need a few functions from it?" or "perhaps a simple algorithm would indeed suffice." We mindlessly reach for complex regex engines to solve simple parsing problems, try to garner "functional programming cred" by reaching for a series of collection functions from our favorite 50kb utility package when a simple c-style for loop would have not only sufficed, but indeed got the job done much faster. All this results in bloated, unoptimized javascript bundles. To top it off, we under cache, and aggressively cache bust, and ship unminified bundles with oodles of source maps because of "developer experience" I can't tell you how many times I see, to this day, a fortune 500 company bundling an entire unminified javascript framework. Wirth's law indeed. Hope this was a little less empty. These are my observations having done this for a few decades now and managing developers these days.

joosters 6y ago
I agree with all you are saying, but I wonder how much this actually comes down to software developers. I suspect (but have absolutely no data!) that for many sites, the pressure to add extra stats, tracking, advertising, monitoring, etc etc, comes from 'above' and it's not the developers' choice to add these mountains of javascript libraries to their sites. Perhaps they should push back, but what leverage do the developers have?
trhway 6y ago
pretty much like enterprise software. The similar situation allows for an obvious for many conclusion - there is no money in performance, or more exactly the opportunity cost of performance is higher than benefit.

TimPC 6y ago

I'll try and offer the more controversial point. Good software development can slow the web down. People are often optimizing for code reusability, code quality, ease of debugging and other advantages of some heavyweight frameworks rather than raw load time. Often this is the right call as engineering is a cost centre. Where it goes wrong is when things get too slow and too bloated to the point you're actually having people abandon the site before load but most of the major frameworks used properly don't offer that extreme a tradeoff. I also have no idea what % of these sites have reached that level.