Comment by austin-cheney

Comment by austin-cheney 5 hours ago

8 replies

Everybody complains about performance. Slow software feels like poison.

Except, anything written with a large JavaScript framework is allowed to be slow. In fact slow as syrup is strongly encouraged. To prove it just ask the developers. Mention it could be 8-50x faster just by not using their favorite framework and note the response. Even better, show them a proof of concept and take note of their unemotional objectivity.

viraptor 3 hours ago

This has nothing to do with the frameworks though. Almost every listed step of delay there is due to specific software design choices, not JS level stuff. For example search - why isn't every possible next letter prefetched before you even select it? It's trivially cacheable at local nodes anyway. Why isn't the first few seconds buffered by the time you open movie description? How is the UI even possible to be laggy - there are way larger services using react without issues.

moring 4 hours ago

Non-constructive reply: Developers have been burned too many times by snake oil vendors and "solutions" that only work for toy examples. Also, I've never seen being slow to be encouraged anywhere. Most consider it an acceptable tradeoff though.

Constructive reply: What would be an approach to writing a large web frontend (large as in, many pages and controls) without using a large framework?

I'm asking this because I know how to do it in React but also how to do it "the old jQuery way" (or equivalently, using today's standardized builtins). Productivity is easily 100x larger with React.

edit: Ideally, together with a link to an example open-source application that does it that way, to understand how it works and feels at (code) scale.

  • austin-cheney 2 hours ago

    > without using a large framework?

    I have explained this countless times. It rarely sinks in and quite often is met with hostility, so I don't bother any more. The problem is simple: its where people stake their career. Do they build their career upon writing original applications or upon using a tool? This difference is rather extreme.

    By the way, without React shouldn't default to jQuery. If that is your perspective of reality you are already at the maxim of your potential.

  • seszett 2 hours ago

    > link to an example open-source application that does it that way

    My experience is with this: https://github.com/Dolibarr/dolibarr (what I currently work on is quite similar, but it's not open source).

    It works fine. Clients don't complain about the interface. The project has been going on for 20 years or so now, and doesn't need big refactors every time a dependency gets updated because it avoids dependencies.

bayindirh 5 hours ago

In short, user experience and efficiency is sacrificed everywhere for development velocity, time to market and monies.

This is embodiment of worse (for the customer) is better (for the business) adage.

  • austin-cheney 4 hours ago

    That is a rather generous comment. As a former JavaScript developer I can tell you the qualities of concern are not the business concerns of delivery. Delivery will increase just as dramatically by reducing the tech debt imposed from unnecessary code. All that really matters is solving for developer anxiety.

    • bayindirh 4 hours ago

      > All that really matters is solving for developer anxiety.

      This is a new and interesting insight to me. Can you please elaborate it a bit further, if you wish?

      • austin-cheney 4 hours ago

        Imagine if you were an Uber driver and that is your full time job. Imagine it pays more than double the national average income. Also imagine you cannot navigate without a digital map and cannot work the car without AI assistance. If someone suggests taking the AI and the digital map away to increase road safety and driver performance you would likely lose your job for failure to perform. The very first thing you would do, as that driver, would make excuses and attack everything that threatens your career identity.