[sokoloff]

As someone who has probably wasted more time than optimal agonizing over performance (I used to be a game dev for console and PC), what you say is absolutely true, but I think engineers have a tendency to think about Facebook scale before they have triple-digits of users. That is usually a mistake.

[GlitchMr]

A web application doesn't have to be scalable. Stack Overflow for instance could run on a single web server (source: https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...), and this is a very popular website with Alexa rank of 39.

[hinkley]

It’s fundamentally about choosing features based on what can be done well versus done at all. Lots of server bloat is caused by loading our applications up with features that are not cheap resource-wise. If you think about the billions of calculations and the hundreds of millions of bytes you can ship from one machine, we should be able to do something like stackoverflow in one rack with room to spare.

15 years ago we could sustain 1/10th the traffic on 1/40th of the hardware of my current project, and the old one was badly architected. If we fixed that and added all the redundancy and telemetry of today they might just about cancel out. But factor in all the hardware improvements and this is not a good look.

[saagarjha]

Hacker News runs on a single machine, apparently.

[karatestomp]

Your average "web scale" cloud system with Node and lambdas and VMs and distributed databases galore feels slow and clunky as hell before it's even under load, to those of us who remember "bad" old LAMP stacks running on a 1U server.

Not that I want to go back to that, exactly, but our performance expectations have gotten really screwy.

[EDIT] or, hell, take "Web 2.0". Piles of code and frameworks and shadow DOMs and shit all chasing and touting "performance" while full-page-loading low-JS sites like Craigslist and Basic HTML Gmail (or HN) leave them in the dust. Know what those are doing? Handing HTML to the browser and letting it render it. No JS render step, no fetching JSON then passing it through Redux and then making twenty function calls to eventually modify a shadow DOM to later apply to the real one. The browser is fast. Your JS is what's fucking slow and eating all my memory.

[adossi]

I would argue JS is a lot faster than you think, and the sluggishness you feel is due to the massive number of files being downloaded. Dozens of JS libraries (think jQuery, Bootstrap, etc.), several CSS stylesheets, and a hundred images or more. If each one of those files is even a few kilobytes each, there is still a 10ms (or even 100ms) download time on each of them, and unfortunately its very common for these files to be downloaded sequentially. JS on its own is quite performant.

[karatestomp]

Whatever some benchmarks (probably involving handing control off to C or C++ as quickly as possible, like any interpreted language benchmark aiming to demonstrate its "blazing fast" speed) say, real world experience demonstrates the opposite. Web 2.0 "webapps" are slow as dripping molasses and eat memory like they own my whole machine. Input lags, "loading" bars galore for the simplest thing, and that's even when supposed geniuses at Google or wherever are involved. That's Javascript's fault, not HTML and CSS, since those demonstrably still work just fine and aren't that much more memory hungry than they were years ago.

[EDIT] to be fair to Javascript, there are few or no similarly-robust scripting languages that'd fair much better at half-assedly reimplementing features of their host environment (the browser, in this case). I dislike it for other reasons but it's not because it's slower than its peer languages. And I have plenty of complaints about HTML and CSS for modern "app development" since they've been ill-advisedly pressed into service for that purpose, but speed's not one of them—my browser renders a plain webpage in no time flat.

[FridgeSeal]

Whilst JS might be somewhat fast, you know what’s even faster?

Designing your application so that it doesn’t need it. If I never have to download, parse and execute the JS, I’m already way ahead. With better privacy to boot.

[adossi]

I understand the appeal of rendering websites on the serverside, in their entirety (HTML and CSS), before the response is returned to the user's browser, which is what would need to happen if we all decided to stop using JavaScript today. However, using JavaScript in the user's browser to compute things like dynamic construction of the UI, animations, etc. has its benefits. For one, using the user's machine via JavaScript leverages their CPU and reduces the CPU consumption of the server. This can save cost, and when done correctly provides an overall better user experience. Things like AJAX (or XMLHttpRequests) are also a blessing and vastly improve the usability of websites. I'm comfortably sitting on the fence - I agree JS is used too often for things that don't need to be done on the user's machine, and anything that can be done on the serverside easily should be done there, but there are times when it is useful. Because of that I disagree with disabling it or not using it entirely.

[VBprogrammer]

I don't even think that is the problem. In my career I've seen full blown arguments over loops which, as a worst case, could only ever contain a handful of items, or are only executed once per user action. That's not facebook scale or not, it's just worrying about the wrong things.

[thrower123]

Fundamentally, some people are allergic to actually profiling things and collecting data. I don't understand it, but there are lots of people who would rather spend hours talking over things in the theoretical sense, rather than spending a half hour coding it both ways and benchmarking it to get some actual data to make a decision on.

[gpderetta]

On the other hand you can't benchmark every single line of potentially problematic code and even if you could, syntetic tests are not reliable.

If by experience you know that a certain solution can be problematic and there is a different solution which has reasonable implementation costs, you should do what your experience tells you especially if fixing it after the fact would have significantly higher implementation costs.

[jcelerier]

> engineers have a tendency to think about Facebook scale before they have triple-digits of users.

I don't think number of users is what matters except for web services. If you make for instance a photo or audio editing software, there will never be enough performance.

It isn't acceptable to say to your users that your software works fine until, say, 8192*8192 images : if you want to compete against other software, you have to consistently be the fastest at every task that artists may throw at you (else you will get bad reviews on specialist & prosumer press / forums / blogs which can kill your business pretty efficiently... as it takes hundreds of people saying "it's fast" to offset the effect of a single press article saying "it's slow as shit" in art communities).