People misuse and abuse JS all the dang time. Take Twitter: you follow a link to a tweet from somewhere else, but first thing you see as the page loads is not the tweet — it's everything but the tweet itself. There's a spinner instead of it, because rendering it server-side would've made too much sense, I guess. Gotta make an API request from the client and render it client-side just because that's so trendy.
In other words, there are too many websites that are made as "web apps" that should not be web apps.
Which is made way worse by the fact that tweets are 280 characters of text. It's absurd that Twitter has a higher delay than a few round trips when they aren't reloading any structural content. Wtf are these people on 300k salaries doing all day?
His point is it's just 280 characters of text to download to the client to show the tweet. The client have downloaded probably 1,000x that much text before he can even see what he wants to see.
Ah - but here you're hitting a wall. You could build a very lean twitter with minimal advertising and a more sane tweet presentation order - but nobody on the business side of things actually wants you to build that. They want you to build a social media platform that can be leveraged with synergies and RoI to maximize user retention and hopefully get a bit of Ad money out of the process somewhere along the way.
It is. And I think this is because customers aren't valued they're commoditized, now personal information is a commodity with a fair bit of value and society has failed to properly punish the misuse of that value so it's sort of an ever lasting font of money.
I wholeheartedly believe that when we solve the issue of undervaluing personal information... that's when Ads become nearly worthless (like they are in print media) and software salaries deflate to the point where those useful by humans tools become the primary product again - instead of tools to use harvesting from humans.
But, I'm quite an optimist - and a cynical one at that.
This is entirely speculations but I think that may come from a very interesting factor - it's not what the engineering team views as a core competency. There may be a big divide in how the business is perceived between marketing and devs and optimizing Ads (this throw away side-component) isn't viewed as a tech priority by the team.
A more reasonable reason might just be that trying to be a platform of everything is a complex proposition and they've accepted so much complexity that all their labour at this point is being poured into maintaining that complexity rather than making improvements.
I disagree with "responsiveness never". Imagine you have a "tabs" component on a page, each tab has some text (for example [1]). With javascript, you can hide the content of the first tab and show the second tab on click, almost instantly.
Without javascript the second tab would be a link to another HTML page where the second tab is shown. Exact same behaviour for the user, however the one with a few lines of javascript will feel way more responsive than the one without, where the user has to wait for a new page to load.
Without Javascript, the tab can be a label that activates a radio button next to a hidden div that also has a input:checked~div { display: block;} CSS on it. No Javascript required.
Yeah, you're right that simple tabs can also be implemented using css, but I still disagree. Another example: how about a simple search on a table [1].
In this case the search is instant. Without JS you would have to have a submit button and wait for the request. Even if you also added a button the JS version it would still feel more responsive, as again, you're not waiting for the request.
I'm not sure I've ever seen a case where I have a data set that's small enough to be quickly searchable (and quickly re-renderable) using client-side JS but big enough that I need dedicated and app-like sort, search, or query functionality. And where such a set of data to exist, that data set would almost certainly be _growing_ with time, meaning even if it started out as something where I can have snappy JS search, as time passes the JS search grows heavier and slower through time.
Additionally, when it comes to client-side spreadsheets I have seen far more terrible half client-side, half server-side implementations (being only able to sort within a page, instead of across all pages of results). If I had to choose one, I'd choose a world were all we had were server side spreadsheets.
I’ve implemented front-end (fuzzy) search in multiple projects over the years. When the dataset is known to be small enough it’s great.
I have also seen the horrible half/half implementations you mention where it should have just been implemented on the server side, and I totally agree with you there.
However it was just an example to show that a unsubstantiated blanket statement like “responsiveness never” is just wrong. I’m not saying doing search in JS is always (or even often) better, but it can be sometimes if done well.
And no, complexity generally doesn't negate this. Earlier this year I built a series of complicated medical forms for a healthcare web site that are all HTML + CSS + < 2K of jsvascript, and they all respond instantly because I did't lean on JS to do everything.
The pages are fast, responsive, work on any device, almost any bandwidth (think oncologists in the basement of a hospital with an iPad on a bad cellular connection), and the clients are thrilled.
JS in of itself is not a performance issue in many cases. It can even improve performance in terms of speed/responsiveness.