10 ms·

>The more modern style of heavier client-side js apps lets you use software development best practices to structure, reuse, and test your code in ways that are

• aryonoco 6y ago
  Code that is easier to read is easier to maintain and easier to debug. Code that is easier to read and more intuitive will, more often than not, result in a better product and better experience for the users.
  • _jal 6y ago
    A: "Your restaurant's food tastes terrible." B: "Nutritious, healthy food will ensure the longevity of my customers, thereby maximizing lifetime customer revenue."
    • d3nj4l 6y ago
      That's an awful analogy
      • bb88 6y ago
        I just logged into nest for the first time on a new laptop. It took 15 seconds to load and get to the screen to change the temperature on the thermostat. Then I refreshed the page and it still took 10 seconds to reload. I'm sure their code is also relatively bug free.
      • pc86 6y ago
        It's actually pretty good analogy, when you're searching for an analogy of something being technically accurate while missing literally the entire point. Making your code "more intuitive" does not result in a better product. Making a better product does. The argument is that software development is one of the few jobs where the employees' experience seems to be equal or more important than the client experience. Sacrificing a restaurant goer's experience (taste) because it makes the restauranteur's experience (customer LTV) better is a decent analogy.
    • lyjackal 6y ago
      I think a better analogy might be telling a restaurant to cut down their oversized menu so that they can actually make at least one good meal
    • newsbinator 6y ago
      A: "I enjoy your restaurant's food but my chef friend said your kitchen is inefficient". B: "As long as you enjoy it, and we can keep making it for you at the same quality you enjoy, we don't care how inefficient our kitchen is".
      • nybble41 6y ago
        A: "Okay, but the new place next door serves identical food with a more efficient kitchen, at lower prices you can't match without making significant changes. If you don't improve efficiency somehow you'll start to lose customers."
  • r0b05 6y ago
    I wholeheartedly agree. Maintainable code can quickly and easily be extended into new features for the customer. Unmaintainable code usually results in a ton of support tickets and late nights hunting and fixing bugs that originated from deploying into production that day. This leads to heartache and frustration for the customer. The customer comes first, yes. Good maintainable code, is a way to achieve this goal.
  • bananaface 6y ago
    I disagree with the premise. "Readability" is an excuse people use for writing slow code. It's not an inevitable tradeoff. Like, most of these people are not saying, "we could do this thing which would speed up the app by an order of magnitude, but we won't because it will decrease readability." They have no idea why their code is slow. Many don't even realise it is slow. My favourite talking point is to remind people that GTA V can simulate & render an entire game world 60 times per second, 144 times on the right monitor. Is that a more complex render than Twitter? Computers are really fast, it doesn't take garbage code to exploit that.
    • adamsea 6y ago
      IMHO it’s in part because of what I assume are different business models between a game like GTA and many / most businesses where a website / web app is core to their product. Different business models result in different environments in which to conduct software engineering; different constraints and requirements. IMHO constant and unpredictable change (which I assume happens less for games like GTA) is one of the big differences, as is the relationship between application performance and profit. But I like what you’re saying and would love to see that world.
    • hkt 6y ago
      GTA V has graphics card requirements that, I suspect, may be quite large compared to Twitter. Although it is worth noting that GPU acceleration in the browser is increasingly a thing: https://support.mozilla.org/en-US/kb/upgrade-graphics-drivers-use-hardware-acceleration https://support.mozilla.org/en-US/kb/upgrade-graphics-driver... That being said, I don't think it addresses the problems with client side applications, although it may allow more complex ones.
      • peacefulhat 6y ago
        Websites like Twitter are not render bottlenecked. Even a software rendered game from decades ago like doom is doing more on the screen than Twitter.
    • gowld 6y ago
  • syats 6y ago
    The article this thread is about clearly shows that your second statement is not true.
    • ictebres 6y ago
      Page loading speed is not the only concern the users have.
  • deleted 6y ago
    [deleted]
  • AnIdiotOnTheNet 6y ago
    Then please explain why the increasing trend in developer convenience is correlated with the decline in user experience.
    • aeontech 6y ago
      It’s a false correlation. Because the universal rule is that 90% of everything is terrible, including software. Corollary rule is that work expands to fill all available time, and software expands to fill all available resources. If you go back to before the ascent of age of front-end frameworks, you would find that there were still tons of sites that were slow and poorly performing, despite running entirely in server-side technologies. Something that made Google incredibly appealing when it first came out was it’s instantly-loading front page with a single search box and a single button. This was in drastic, shocking contrast in the age where every other search engine portal had a ton of content on it, including news, stock tickers, and the kitchen sink. In the end, unless the developers of the sites make performance a priority, it makes absolutely no difference what the tech stack is. The problem is that companies don’t prioritize it.
  • midrus 6y ago
    Tell this to Reddit developers
• octodog 6y ago
  I find this comment a bit odd. It seems clear to me that code that is easier to write, reuse, test and maintain saves time and money that can then be spent on building a better product. Do you disagree?
  • pjmlp 6y ago
    How does that help sell more pizzas per day? Blunt example, however that is what matters to a customer that just commissioned a web site for pizza delivery.
    • laumars 6y ago
      It’s even more important in that case because writing a pizza delivery website isn’t a complex nor new problem so doesn’t need a complex solution. But to answer your question, if you write clean code then when that company expands it’s operations it is easier for you (or whoever next gets commissioned) to later expand on that site to add more restaurants, thus then allowing your customer to sell more pizzas.
      • pjmlp 6y ago
        That is definitely not a feature that requires JavaScript, if you now want to pick on my example.
        • laumars 6y ago
          > That is definitely not a feature that requires JavaScript You’re right it doesn’t but I thought the context had drifted from that topic and onto code quality. If we’re talking strictly about JS heavy sites then I’m definitely in favour of the less is more approach. There’s times when it makes sense having JavaScript trigger restful APIs rather than have the entire site rendered on the server side. The problem is JavaScript often gets overused these days. I could write an essay on where I think modern tech has gone off the rails though. > if you now want to pick on my example. That’s a strange comment to make considering you presented the example for discussion. Of course people will then “pick on” the example, in fact you’d be the first to moan about a straw man argument if people cited a different example.
• john-shaffer 6y ago
  > I'll just use a list for everything: the users will eat the slowdown "Premature optimization is the root of all evil." You often should use a list until you've identified a specific performance issue. The list isn't the problem. Not actually optimizing is.
  • account42 6y ago
    Choosing the right data structures and algorithms is not premature optimization.
    • john-shaffer 6y ago
      I agree if you know, e.g., that the list is going to contain thousands of items or is going to be iterated over in your inner loop. That's not premature optimization, that's just common sense. Hence the qualifier "premature".
  • pdimitar 6y ago
    > You often should use a list until you've identified a specific performance issue. Identifying a JS performance issue is something that almost no company ever does unless revenue is obviously threatened (and even then many fail to act). So IMO it pays off to do a little bit of premature optimization in JS land.
• almostdeadguy 6y ago
  One of the truly differentiating factors for good software engineers is being able to recognize when your habits are in harmony with the objectives of the project you're working on. And on the meta-level, developing the sense for how to keep them in harmony with the trajectory of a project which will likely prioritize different things at different points over its lifespan. Propensity to change is one of the most common features I've found in software projects I've worked on in my career and most software engineering "best practices", as conceived by the authors of opinions about these things, are usually strategies for managing rapid change. i.e. structuring code so it's amenable to change, understandable to the maintainer who inherits your code, has guardrails around important invariants and guarantees via assertions and tests, etc. The details of how (and to what degree) these things should be done are highly contextually sensitive, and that is where the dogma of "best practices" can start to interfere with creating a good user experience. But I find it a little eye-rolling when people talk about hygienic software development practices and user experience as though they are in opposition. Tests, legible code, flexible structure, etc. are enablers of good user experience, because they're what allow us to change products to fit the needs of our users. They're what allow us to ship things that people can use without them exploding. The tendency toward asset bloat on the web and just the general use of cheap-in-development-costly-for-the-user solutions (scripting languages, inefficient data structures, verbose serialization formats, piles of dependencies) is definitely an industry problem, but I think its naive to attribute these decisions to lazy devs or devs trying to make their jobs more convenient. In my experience there's two common causes for this state of things: 1. In all seriousness, the nature of capitalism. In reality, most businesses don't actually care about the majority of prospective users. They care about a couple narrow segments of users, and if those users happen to be equipped with hardware to handle this kind of inefficiency (i.e. if they're first world clients on desktop or high end mobile devices with 4G access), the business largely doesn't care. Responsiveness, low resources consumption, low energy impact, etc. are fungible engineering goals if they don't negatively affect your sales objectives. 2. The org hasn't figured out how to incentivize responsiveness, low resource utilization, etc. as objectives. Software developers get requests to focus their efforts on all different manner of criteria, and the without designing incentivization schemes and feedback loops that orient toward these objectives, there is no particular reason why they'll be inclined towards them.
• hazz99 6y ago
  > "It makes code more readable and intuitive" is NOT the end goal. Making your job easier or more convenient is not the end goal. Making a good product for the user is! I think the end goal is more about balancing the value you can create with the budget you have. It's an optimization problem. If I can deliver 80% of the value for 20% of the price, I will do that.
  • foepys 6y ago
    Until somebody comes around and sells the 100% product for a 50% markup and enough people value completeness and UX more than their money. See Apple's MacBook Pro and iPhone. Another example: I absolutely hate Amazon Prime Video for its UX and bugs they didn't fix for years (like asynchronous audio). So even though Prime is significantly cheaper in Germany, I rather pay for the more expensive Netflix instead.
    • hazz99 6y ago
      Yes, but low end notebooks would still exist. Different customer segments.
  • bananaface 6y ago
    Slack has a budget of multiple millions, RipCord has a budget of zero, and one programmer who works on it in his spare time. Which is faster? Polishing RipCord so it looked indistinguishable from the Slack client wouldn't be that expensive. I would argue its much more "they don't know how" than "they are making a business decision not to."
    • hombre_fatal 6y ago
      That should only remind you that people care about a lot more than just performance.
      • bananaface 6y ago
        Why would I assume this particular failure is a choice?
• heisenbit 6y ago
  > Making your job easier or more convenient is not the end goal. Making a good product for the user is! This is a very limited perspective. Let me give you an enterprise software perspective: 1) Software maintenance costs. Better maintainable software allows more services to be delivered with a smaller budget. 2) Software is never finished. Ability to respond to new or changing user requirements matters to users and is perceived as part of the quality of service. 3) Software is going to be maintained by someone else. If they can not maintain it then users have to go through another iteration done by another team (best practice: fewer features, but at least the implemented features have more bugs).
  • austincheney 6y ago
    > 1) Software maintenance costs. Better maintainable software allows more services to be delivered with a smaller budget. Better is not the same as easier. This is such an equivocation fallacy since both of those terms are highly subjective. Maintenance costs are measured in numbers and not some imaginary developer ideal of job security.
• lowwave 6y ago
  One can make code more readable and intuitive and making a good product for the user. I have done both in heavy server side rendering using templates and SPA rendering on the client side. It all comes down to your user base and the devices/browser they are using, if they have an aversion toward running JS in the browser. By using JS on the server side, you can maintain quite bit of logic on both server and client side. If you are doing web development, why not make it the same. Yes, one shall not trust the client validation, but many people find JS validation to be more user friendly than a form submit.
• brailsafe 6y ago
  Which engineering discipline's primary concern is user experience?