Maybe we could tone down the JavaScript (2016)
eev.ee
eev.ee
The most interesting part was the Quirks.cpp file [1] that contains literally randomized css classnames inside the web browser code because a major website was so shitty and spec violating in their implementations.
I mean, fixing a website in a browser source code...this shit got out of hand real quick yo.
The problem with all those drafts is that Google keeps doing their own thing, and others are forced to try to catch-up or implement the same bugs/quirks that chromium does. Everything is rushed so QUICly that even Microsoft gave up at some point. And at some point in the past google realized that they can own the web if they own the Browser. And that's what they effectively do now, because the competition isn't really a competition at all anymore.
[1] https://github.com/WebKit/WebKit/blob/main/Source/WebCore/pa...
https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
Config files are like code, but even more shit. You never get the full set of functionality that you get with code, the compiler doesn't check your work, code navigation can't help you, and there's no debugger.
Regardless, I don’t think Dhali was around at the time Quirks.cpp was created.
Funny story, my first exposure to ruby was using it to write ant (or was it maven) config files (EJB nightmares) because the XML config sucked pretty bad (around Rails 1.0 era). It was far more concise and easy to work with, being an actual language and English readable, but I was never sure it was a good idea in a large team environment. If Java hadn’t been so cumbersome I would have used it for config as well instead of the hot garbage XML config was (is still?). I’ve seen a bajillion attempts at config languages since then. Most not great.
|| domain.endsWith("hulu.com");
[0] https://github.com/WebKit/WebKit/blob/ce237483d034e41eff8cc5...
this is also why video card drivers are so huge; the fixes to games made at the driver level. this kind of thing happens a lot.
Wow I thought you were kidding.
I mean, imagine a developer trying to fix their code behaving completely different on iOS and they cannot have a single clue why that is the case.
Additionally, WebKit is released very late to the public (sometimes even after fixes have been rolled out to iOS)...and before that nobody from the outside can even know what's going on.
From a maintainability point of view things like this should be - in worst case - a Web Extension, but definitely not be inside a Browser source codebase.
Youtube is even worse once you dig through the Apple internal plugin replacement, which effectively implements a native C++ decoder for youtube streams on iOS because otherwise you could not watch videos there. This was done before as a WebCore plugin but has been moved around into the PluginProcess source-code wise over the last two months (and currently blocks me from merging in changes, so I have to backport fixes after I removed all legacy plugin APIs).
// FIXME: Remove after the site is fixed, <rdar://problem/75792913>
bool Quirks::shouldHideSearchFieldResultsButton() const
if (topPrivatelyControlledDomain(m_document->topDocument().url().host().toString()).startsWith("google."))
return true;
I use uMatrix and a hardened Firefox profile so I notice pretty quickly if websites are poorly made. Spoiler: the vast majority are, and the big players like Twitter, Facebook, Google, etc. are absolutely the worst offenders.
But Twitter is so frustrating because of exactly what the article's author says: they re-invent everything, including the text in the Tweet box. As soon as you start typing a tweet it gets converted into some horrific swamp of HTML elements which starts to break really fast if you limit JS as I do.
At some point the concept of "graceful degradation", which used to be taught as an essential part of high-quality web development, was totally abandoned.
I feel like I'm transitioning into "old man yells at cloud" more and more every day, but the web's going down the shitter real fast.
These are businesses - they write code to generate profit. Their support of limited javascript has no impact on profit, so they won't do it.
It feels more domain to the browser. Have some sort of required flag.
The rest of us don't want to be fired.
Speaking as a web developer, blocker of JavaScript by default, uMatrix user, and extensive user script writer: limiting is vastly harder to deal with than blocking; your “even” is unjust. “No JavaScript” is easy to detect and cope with (even if it’s just to respond “nah, dude; JavaScript me, bro”), but coping with blocking some JavaScript requires you to consider what could be blocked and what to do about it in each case.
If you’re talking third-party scripts, then sure, developers should handle failure to load scripts/XHR/fetch, simply for normal people’s sake; for analytics especially there are well-trodden paths, though certainly occasionally you encounter sites that don’t tread them. (Note that when I say “third party” I mean the social concept of third party, not “different origin”, because it’s common to load first-party scripts from different origins—CDNs, &c.)
If you’re blocking things at a finer grain than first-party/third-party divide, then you should expect things will often blow up. It’s not particularly reasonable for them to detect and work with your meddling.
A few years ago I had to use Dropbox from time to time. It was always fun whenever it dropped my session (never for any obvious reason) and forced me to log in again, as I had to tweak my whitelists almost every time as they’d have shifted their CAPTCHA thing around or added a new CAPTCHA service (they had three or four going at once!) or something. It would take literally twenty seconds after pressing the submit button before it would decide to actually let me in, even with no intercepted requests. Not sure what was going on with that. And if anything was blocked, then it’d probably just hang indefinitely, often even without any exception ever being thrown in the console! Definitely not a good experience, and they should detect that a necessary script failed to load and notify you, but eh, I reckon I brought it on myself by using fine-grained blocking.
Then there are the sites that are kinda/mostly broken until I enable a couple of obvious exceptions I should probably have universally enabled. That's fair.
Then there are the sites that it takes a minute or two of messing around to get to work..I have to whitelist 10+ different domains for them. That's irritating.
Then there are the sites that I can't seem to get working properly at all, and eventually give up and just open in a private mode tab in Safari, because I trust that combo the most.
Parent commenter was right: Twitter is a dumpster fire that throws a hissy fit at the drop of a hat, in way very few other sites do; it's almost like they do it purposefully out of spite.
It's a fucking glorified PLAIN text messenger. There is no excuse for the level of complexity and unreliability of the code they throw at browsers, from such a large organization with such supposed high-level engineering talent.
<style>
#dropdown {
display: none;
}
#dropdown:target {
display: block;
}
</style>
<a href="#dropdown">Show dropdown</a>
<div id="dropdown">
Dropped down!
<a href="#">Close</a>
</div>
Product managers and designers don't care about reducing JavaScript, so that really has no weight against the things I've mentioned plus more. They want it to work the way they want it to work.
The better hack that has been long available is invisible checkboxes, :checked and a sibling selector. That’s almost certainly what “you could fake it with CSS too” was describing back then.
But the proper solution now would be <details>. As an example of this, many dropdowns on GitHub work without JavaScript, by using <details>.
I would note that with all of these alternatives, you tend to want a little JavaScript to enhance the functionality, e.g. manage ARIA states and focus.
The web is an application platform, it stopped being about documents years ago. Whatever you may feel about Xforms, its spec was published nearly 20 years ago and even now HTML forms still cannot do something as basic as a PUT request without JS or workarounds.
It's clear that browser vendors expect you to use JS for basic functionality, and for document distribution you'll be using PDF anyway so why try to pigeonhole the web onto something it is not? What's to be gained by pretending otherwise?
This is true and it makes me really sad. HTML in particular, and the web broadly, is really good at document presentation and distribution. I see PDFs every single workday that should have been a tiny, readable, mobile-friendly-by-default HTML file.
No, it's both. The problem is people not knowing which type of site they're creating and making an app when all they need is a page.
I do. I stopped "upgrading" most applications years ago because they only became worse with each version. Excel probably peaked in 2003, arguably 2010. Anything beyond that is frustrating ribbon-UI garbage IMO.
I do! Yes, let's talk about native apps and documents!
https://news.ycombinator.com/item?id=21347067
https://news.ycombinator.com/item?id=21639043
https://news.ycombinator.com/item?id=23607320
etc...
----
Can you imagine how great it would be if nearly every graphical native app on your computer had a pure-text representation of its state that you could query/extend/manipulate? Or if you launched an app and it was missing a dependency and it launched anyway and just disabled a small amount of functionality related to that dependency? Some applications already kind of do this with their dependencies (Firefox will launch even if you don't have a GPU or video codecs installed), but it would be great if they did it even more.
The divide between applications and documents has always been a lie. Most (not all, but most) native apps are interactive documents, they are documents that change when you do something to them, and that are just styled to be displayed in 2D space instead of as pure-text trees. There are very few native app interfaces on my computer that couldn't render out to HTML or something similar. And it would be amazing if native apps were rendered out as pure-text XML/tree-based documents, that would be so useful. It would be even better if there were system-wide conventions for things like links/buttons inside of that tree that could be specified declaratively and that were user-inspectable. That would be a big improvement to accessibility and extensibility for application UIs. It would be like having CLIs for everything, but even better.
Applications are documents, and documents are often interactive. There is no actual distinction, it's just a gradient of how complicated the document is and how often it updates.
This is my pet-cause and at some point I'm going to finally snap, sit down, and write an extensive manifesto about it. Basically every single native app on my computer should work headlessly, should implement progressive enhancement, and should split out declarative representations of state that can be styled and intercepted by other programs.
Native app developers have gotten hung up on the bad parts of the web and the bad parts of HTML/CSS/Javascript (admittedly there are a lot), and it's caused them to completely miss the revolutionary idea that Unix already proposed all those years ago -- that most apps should output human-manipulable text formats that users can inspect, restyle, and pipe into other programs. HTML is the next evolution of that idea, and native developers are so hung-up on the details of the web that they've missed the broader picture and are stuck in the past in how they think about UX presentation. Even worse, they've started to push those outdated ideas onto the web; instead of taking a step back and trying to think about how to make more modular and more inspectable interfaces, instead of thinking about what a better implementation of HTML for native apps could look like, instead they argue that the web itself should do away with these concepts and just render out blobs of pixels compiled in WASM threads.
And this is when I realized this article was written a long time ago. Now if you attempt read a text post on twitter you get nothing at all unless you execute javascript first. The entire screenshot would be red in 2021.
I’ve yet to see a real guide from someone building an even moderately complex site and moving away from these terrible frameworks and “unnecessary JS”.
In the end most of these boil down to “I wish other people would build their sites the way I want them to” without much consideration of how / why a site is the way it is in the first place.
Plus, even if you're really careful and make something that is judicious with JS, phone users come in and blow everything up. For example, leaving a review could be done JS free buy opening a dedicated review view, and if the end user needs to refer back to the product, they can open a new tab. It's not so easy with a phone, unless they have really strong phone browser kung fu.
I would have thought that by now we would have settled on broad conventions for most things so nobody would be inventing all new ways of doing the basics. Instead is seems like things are proliferating. If there are any standards, they're top-down things from Big Corporations like Twitter or Google, because they have the muscle to force everybody to use their conventions and like it.
And it's a pretty big and functional site.
I've looked at the source code and it's very straightforward Flask apps and Jinja templates, and hand-written JavaScript.
https://sr.ht/~sircmpwn/sourcehut/sources
For people who don't remember, the result is very similar to how Google looked ~15 years ago -- Google News, Froogle, search results, etc. The underlying tech was different, but the result is the same. Google just used C++ and the "google-ctemplate" language.
----
I wish that every food ordering app was written like this.
I mean all they are doing is displaying a list of pictures and then providing a checkout experience -- it's literally eBay from 1998, but 1000x slower.
It would also be like 10x faster than a native app on phone if it were written like that.
In fact Google has a lightning food ordering app right on the search results page that proves the point! However I tend not to use it because I don't think it's good to let the search provider "hijack" the traffic intended for restaurants. i.e. presumably the restaurant will put their preferred vendors on their sites, which is almost never Google, and is instead some really slow and janky app :-(
The difference between the server-side option and the outsourced one is that the outsourced one is probably also going to soak up and resell a lot of data that you probably wouldn't have captured yourself.
From the article:
> Accept that sometimes, or for some people, your JavaScript will not work. Put some thought into what that means. Err on the side of basing your work on existing HTML mechanisms whenever you can
As you have observed, disabling JavaScript does not make the site stop working entirely for no reason. It degrades meaningfully, and the author put thought into what that means
Moreover, enabling JS does not break browser functionality you're used to.
That's the entire point.
Such is the case for most JS sites, the site typically doesn't break "entirely", but I consider being unable to post or even read comments to be a major functional breakdown. Comments are non-interactive text, there's no justifiable reason why I should need JS to read them.
For a blog? I disagree, because the point of a blog is to read the author’s comments, not those of third parties.
> Comments are non-interactive text, there's no justifiable reason why I should need JS to read them.
I kinda agree. The issue is that it is very rare to find a static site generator which can interface with a dynamic comment storage. To be honest, I don’t know that one exists, although of course it is completely possible. I can understand as a pragmatic matter why someone might have a static blog, want to add comments and not be willing to run his own dynamic comment system, esp. if that would entail writing said system.
All that being written, it would be awesome to have a static site generator which were called by a hook in a dynamic comment server. I actually would like to write one someday!
The author has posted several comments in the comment section, so even by your definition the blog fails to meet functional standards. However, IMO, the distinction between the author's comments and user comments is arbitrary, both are text meant to be read by readers, and those readers without JS are missing a ton of discussion that's happening in the comments, including discussion with the author. There's actually more to read in the comment section than in the blog post itself.
> All that being written, it would be awesome to have a static site generator which were called by a hook in a dynamic comment server. I actually would like to write one someday!
I have actually seen a system like this implemented at company I used to work for. A posted comment would be stored in a sqlite database before a request to rebuild the comment section is fired (as a partial, to avoid re-rendering the whole page/site), subsequently dumping the new build into the CDN (with some debounce logic to throttle high comment traffic). The rebuild was typically sub-second and performed very well.
Though I wonder if the prevalence of programmable edge networks will leapfrog that before it becomes really mainstream, and allow site owners to add a small bit of edge dynamism to pull dynamic content in without client-side JS.
[0] - https://disqus.com/home/discussion/veekun/maybe_we_could_ton...
I'd say that's more impressive than loading the counterpart of multiple novels for mostly the same functionality.
The problem are most other sites that often don't even load or show any content without JS support, or break in many creative ways. Although for weirdness you only need to disable custom fonts in the browser, and suddenly Reddit's notification button shows the Paypal logo and many websites have random chinese symbols scattered around the UI. And Google Translate looks like you need a translator to use it.
Everything else on the site seems to uphold to his principles.
Any time I tried doing that, 99.9% of comments were spam. Seriously.
[ ] i am not a robot
Product Designer: "No system controls; we want our users to have the Full Brand Experience, therefore, custom controls." Also Product Designer: "Why don't our custom controls work as well as system controls?"
We created this problem ourselves by not having the tools to meet designer needs while doing it right. Pontificating about how they should just change their notion of right misses it completely.
I don’t think telling developers “just do it right” is a scalable solution, the platform has to make the least effort path the one that works best.
Use the system tools. But make the look of the system tools customizable.
System tool. Customizable look.
That's what should be available. But even today you can't consistently change something as simple as a scroll bar or a checkbox.
Which, even worse, are by default styled differently on different browsers.
Separating look&feel from functionality isn't that easy. In any kind of UX, they are bound to various degrees, depending on the use-case.
So if they're _exactly_ getting the point, they're pretty unobservant.
There already is no consistency.
https://en.wikipedia.org/wiki/Windows_Presentation_Foundatio...
Everyone, literally everyone is running their own thing. Name me big company that doesn't roll their own design system.
Preaching purism really doesn't help anyone, let's just accept reality as it is, and stop chasing some utopian dreams that just won't ever materialize (and if only because it would make a lot of jobs and professions useless, overnight, and there's too much inertia for that to happen).
We will never live in a world where an abstract concept like a checkbox can have an 'assigned' specific visual affordance that doesn't allow for adjustments. Such thinking is stuck in the past and won't allow for new/better UI paradigms.
To think that there's no room for variation in the design of form controls, given the broader context of a design system for app, is just a lack of imagination. I guarantee you that the people who design the operating system form controls (which change every couple years) have all sorts of ideas, and they end putting out one possible, relatively minimal option from many good designs they considered.
> Pontificating about how they should just change their notion of right misses it completely.
The ask isn't to change their notion of right, but to understand that (yes, sadly) there is a tradeoff between "usable but ugly system components" and "pretty but janky" bespoke components, and they're making the wrong choice.
If what feels like the vast majority of them are making the same "wrong" choice, we should probably think about ways to make that choice more "right", because clearly, the current approach isn't working
At some point we have to climb out of the trenches and introspect why the most treaded path in web design is the one with the rickety bridge and spike pits when we the software engineers are the ones who lay the bricks.
If youve only designed/“Ideated” for iOS or Android, you have no business designing for web. Entirely different platform with different capabilities.
Embrace reality and build simple effective products. Literally no one gives a shit about the arrows on your carousel or the border radius animation on a button. I just want to scroll and click and open new tabs.
And lest it be overlooked, the appearance of those widgets themselves, is a feature. They are easily identifiable by users of that platform as being something they can interact with and expect a predictable set of outcomes.
Would it be great if everyone on the frontend could get together and agree what the native-to-browser widgets should look like and how they might be customized? Yes. Would the three warring browser manufacturers change their platforms to make web development easier and lighter for everyone, at the cost of platform uniqueness? No.
This would not be great at all. I want widgets on web pages to look like macOS system widgets on macOS, and to look like Windows system widgets on Windows. I want designers to lose the notion that it is their system style, and respect the fact that the browser is _my_ user agent, and therefore must respect _my_ preferences.
Don't."
-- https://web.archive.org/web/20021009021738/http://www.iarchi...
Problem is, most leadership doesn’t care about usability unless it affects marketability, which is less and less likely as people (users) become more comfortable with and accustomed to hopping between needlessly proprietary workflows and abstraction of crucial processes.* Often (usually?) designers also don’t, to be sure, but those like myself who do care are, like devs, up against unreasonable speed demands and interruptions that make it difficult to do our best, most thoughtful work. And though it may seem like design is higher up the totem pole, perhaps because it’s usually upriver from dev, in my experience, most companies see designers as whiny graphics monkeys, just as they may see devs as whiny code monkeys.+
It’s significantly more difficult and time-consuming to design novel functions and flows that conform to or complement existing standards than it is to draft a new system that need only make internal sense and may wantonly disregard the environment around it. This is why people like Electron, right? This is why people liked the internal combustion engine.
* I’d like to see a study on how this kind of acontextualization of work tasks might exacerbate burnout.
+ How many companies are actually defined by great design these days (versus, say, great functionality)? Not even Apple seems to care about that anymore, as they seem eager outpace their software with their hardware, rather than creating any iconic or lasting designs. As “product design” has evolved to include software products, the discipline and its output have become just as mutable, and therefor disposable, and therefor ‘not worth’ the effort necessary to make good things, let alone great things.
> I think the Web is great, I think interactive dynamic stuff is great, and I think the progress we’ve made in the last decade is great. I also think it’s great that the Web is and always has been inherently customizable by users, and that I can use an extension that lets me decide ahead of time what an arbitrary site can run on my computer.
> What’s less great is a team of highly-paid and highly-skilled people all using Chrome on a recent Mac Pro, developing in an office half a mile from almost every server they hit, then turning around and scoffing at people who don’t have exactly the same setup.
And later on:
> I’m not saying that genuine web apps like Google Maps shouldn’t exist — although even Google Maps had a script-free fallback for many years, until the current WebGL version! I’m saying that something has gone very wrong when basic features that already work in plain HTML suddenly no longer work without JavaScript. 40MB of JavaScript, in fact, according to about:memory
This is a really common problem in tech. Smaller companies adopt large company strategies that require more resources than the small company has to do correctly.
Except for autocomplete, do you have any examples where user experience is increased a lot?
On this site, for example, if up vote your comment.. the status will just be updated. Without JS, it causes the page to reload, and I will briefly lose my place.
Inline images and hyperlinks are neat though.
I honestly think the problem with JS reimplementations is that develoeprs assume that they are their audience, or that people like them are the only people that matter.
It is for sure easier to do things wrong, but if you check at most of the major libraries for front-end (drag-and-drop, routing, dropdowns...), accessibility is built-in, and a critical selling point (e.g react-router, downshift...).
I think the proportion of front-end developers knowing about accessibility is just low, and the result is more visible for JS-heavy websites/webapps, but this is imho an education problem, not an ecosystem issue.
Having worked in agencies, accessibility was always treated as a second-class citizen (by clients or managers, not by developers, trying to push for it), and clients would often say "let's go live without it", then would come back to us asking to finish the job once they saw their competitors got sued for having an inaccessible website.
So JS may be a catalyst, but not the root of the problem. It's our job to push for the importance of it, as we pushed for responsive websites a while ago.
If you make a form with HTML and style it with CSS, then you're 85% of the way there with accessibility, and chances are it will be usable if you screw the rest up. With JS, even if you're working from a checklist, you're much more likely to get somethign wrong. And then there are regressions. I kind of believe that you know what you're doing, because the kinds of people that hang out on HN often do. But will your second-generation successor, four years from now, know how to update your work without breaking accessibility? Empirically, based on the low level of accessibility on the web (improving, but still pretty tough going), I'd say "no."
I'm still not convinced it is worth everything we lost:
- Instant loading
- Sane page sizes
- Cross browser compatibility by default, including text based browsers
- Every page is reasonably safe by default
- CPU is idle after initial page load
- Battery life is great by default
and probably a few more.
I guess a good middle road might exist but I wonder if the current situation doesn't mostly serve ad pushers and bored developers ;-)
Edits: yes, a number to clarify my points and to make it clear that I am open to change my views, at least slightly.
https://blog.teamtreehouse.com/creating-autocomplete-dropdow...
I wouldn't say I'm a "purist" about this stuff, but I do feel like at least scripting should make the site feel better, not worse. A lot of these sites are really unpleasant to use, Youtube swapped over to this single-page model that I'm sure was very difficult to build, but sometimes it just breaks navigation for me. What fixes it is I reload the page. So it feels like, to me, even as someone who has Javascript enabled on Youtube, we have gone from an experience where navigation never broke for me on Youtube, to a situation where sometimes Youtube loses track of the fact I'm online and I need to refresh the page, or I hit the back button and it reloads the same video. That's a lot of extra Javascript for an experience that feels like a step backwards. The old Youtube designs all used Javascript, but they also had working back buttons and felt just generally snappier.
I went on Google maps recently and tried to quickly copy a number of website links for businesses into a text file: right-click copy link doesn't work. I can't copy a link for an external website, Google Maps is no longer using hrefs for literally the primary thing they were designed for.
And for what? It's not faster for me to open the external websites, they don't load quicker. I don't get URL previews or some crud. It's a link that doesn't work as well, all that's happened is there's a click handler that has fewer features than the link used to have, and maybe it's easier for Google to get a pingback? This isn't an improvement.
Some, yes. This was in the spec sheet for a large ecommerce website I helped rebuild with modern(er) technologies.
> If a Twitter textbox is lagging while someone types
That's an implementation issue.
re Youtube, I haven't had the experience you describe, but having had to develop the framework side of SPA navigation into something robust and useable, keeping the current page on screen after the a new url was history.push'ed while preloading the data necessary for the next render and managing the scroll position, I can confirm it is a pain. I expect Youtube has the right kind of resources for the task but it happens, probably at a higher rate of bug incidence than regular frontend button-broke-the-site issues.
Implementation issues are going to happen whether you use JS or not, but I find building with JS and with modern frameworks a joy (although a lot of things can be improved) compared to server side alternatives. As with everything though, this is a matter of preference.
The app were replacing with this page is heavy react and there’s a long visual stutter during the show hide because it has to render them all. Not simply show/hide. They actually load more bits to lazy load the posts in JS than to simply send the html and hide/show.
Right, but like I said, I'm not a purist about this, I just think that maybe SPAs should only be rolled out if the implementation actually works.
To circle back around to Google Maps, this is an app that had working links, and the introduction of more Javascript made them worse. So I'm not saying get rid of all Javascript, I'm saying that if you swap out `<a>` tags and it results in broken browser functionality, that's a scenario where just using native tags would result in a better experience.
Twitter/Youtube/Maps are choosing to go down this route even though the implementation is worse. If they didn't have implementation bugs and navigation didn't break on sites like Youtube, and I could copy and paste links from Google Maps, and I didn't have laggy text input on Twitter -- well, then I wouldn't be complaining about any of this.
It's not really about Javascript being bad, but we can both agree that if a company tries to rewrite a website as an SPA and it results in a more buggy experience, then they should hold off on that and they shouldn't just plow forward with the implementation anyway. That has nothing to do with SPAs in general being evil, but even the act of saying "a Javascript-heavy SPA solution should only be pushed if the experience is better than the normal one" feels like I'm saying something revolutionary, and I don't really get what would be controversial about this opinion. Only push a Javascript heavy solution if your solution works, if it results in more breakage than the site had before that solution, then the engineers are moving in the wrong direction.
I don't know if this is a controversial thing to say, but I would say, "only push an SPA if you don't have a bunch of implementation issues". And I think that's where sites like Youtube and Twitter are falling over, in those cases their implementations are either broken because of tracking or just complexity, or something -- but it would have been better for them specifically to have not turned their sites into SPAs, because they can't seem to get rid of the implementation issues and their older sites didn't have as many showstopping bugs or performance issues.
I agree with you that sometimes this kind of partial updating can result in great, quick apps. But in practice, Nitter is faster Twitter is for reading tweets. So if I go to Twitter and I'm not signed in, and I'm just reading Tweets, that's an experience that Nitter is just flat-out better at providing in a more performant way. So it's not that all SPAs are evil or that they should always be avoided, but clearly in Twitter's case the introduction of an SPA didn't make the site faster or better, the low-JS solution ends up outperforming it on multiple key metrics.
Since when do large companies do anything that isn't user-hostile and abusive? Of course FAANGs are trying to keep their walled garden more walled by reducing outgoing links, and Twitter's incompetence is legendary
The real question should be if this type of thing is improving the web at large or the capabilities we can develop "efficiently" on it, and while I would be willing to hear arguments either way, I can tell you I use JS/HTML/CSS in combination to introduce capabilities that would not be palatable without the JS component of that, putting aside whether I would be able to develop them as a bunch of standalone capabilities. Model editors, graph layouts, plugin architectures; we can leverage client machines to do more and more, and in a business setting delivering internal tools this is a great method of reducing costs across the stack - the laptops were already going to be purchased.
You could have used the same argument with flash. It looked and ran the same everywhere, offered features totally unavailable with HTML/CSS and Js.
The point being is that it might work fine on your machine, but its not fine for the rest of us. I am lucky that I have a 2013 retina with a GPU, but even still, there are more and more websites that are slow as shit, for no real reason.
when I'm out and about, small website mean faster loading. this means that more people can use them without tearing their hair out.
Of course a static html file will load instantly and likely not cause any issues, but apples to apples would mean comparing dynamic server side rendered websites to dynamic client (or hybrid) websites. In both cases, inexperienced developers can make a mess of it, including by picking the wrong kind of tools to do the job.
I think JS gets part of its bad reputation because of the ads (and ad networks) it empowered and the bad practices they turned into status quo (reflows, cpu usage, to say nothing of in-your-face overlays and that kind of stuff).
Almost. Most JS (caveat Google Docs etc.) creates the kind of experience users have come to expect. That's orthogonal to "improving" the user experience. Because of the keeping-up-with-the-joneses effects of frontend engineering and design patterns as spearheaded by giant, framework-authoring, standards-setting companies, there are strong incentives to converge on bad outcomes. For example, consider the common trend of replacing built-in controls with equivalents made out of "div soup" for the sake of providing consistent styling. This is done because it is thought that styling controls is a table-stakes necessity for interactive websites. Many studies indicate this, and many users request/demand it.
It's also misguided.
That's not to say that the studies--or the users--are wrong. But "this is how it is done and this is how we want it" is a norm, not some objectively superior optimum, and it's a norm that was created by many years of development. Some of that development was necessary, and advanced the state of the art. But much of it was fad/hype-driven, poorly thought-through, and slipshod. The end result is a bunch of tools/patterns/user expectations that bear little relation to what actually improves user experience.
In other words, JS often only improves things if you grant that the currently accepted definition of "improved" is actually an improvement over using other tools; often, it is not.
> at the expense of annoying purists
In other words, engineers. Engineers more interested in delivering quality than complying with norms or maximizing marginal click revenue by adding the 157th tracking library to a 50MB bundle.
> CSS/HTML gymnastics
Engineering.
For me problem is with pages/documents where I simply want to read stuff, maybe have some basic filtering options and that does not require loads of JS.
Like webshops where I am customer probably don't need 80% of JS that they drop in there for browsing just products.
I understand they need JS heavy content editor side where people add/remove/modify products.
That's what articles like this are pointing out: this well-intentioned thing we're doing has negative consequences. Let's do it more moderately and deliberately to mitigate the side effects.
I used Huel's site earlier and it even had a splash overlay saying what it was loading, it was one reticulating splines away from being The Sims
Edit: ah it was posted in 2016, I don't think anyone (but do wish) cares about limiting their JS usage anymore
I really am not a fan of JS for all of the reasons that have been retread a million times over the years, but honestly the war is long lost and I don't really see the need to annoy people about it anymore.
Or, in the words of Upton Sinclair, 'It is difficult to get a man to understand something, when his salary depends on his not understanding it.'
Also lol I've been Upton'd https://news.ycombinator.com/item?id=27771186
I've also not seen any recently aside from the one we're in (published 2016), what was the most recent one you recall seeing outside this?
E: just realising this comes off a bit snarky after the group quip, apologies. Asking out of legitimate interest not as a gotcha or anything.
At this point I've just given up worrying about it thinking it's an outdated opinion and I've not seen much recently to inform it in any direction other than towards JS support being expected
https://news.ycombinator.com/item?id=29661935 (This page is designed to last, 5 days ago)
HN is also my procrastination tool of choice, so it might be I can see articles and manifestos urging for the return to the glory of blogosphere and web 1.0 before they sink down into oblivion.
It's like you may grow an impression that on HN, there are always endless debates about notetaking in software and paper. Sure they are there. There's good stuff, too, at least every other day.
Specifically, the articles of how graphical fidelity is ruining video games and the ones about doom and doom mapping
They by default aim to make building JS less apps super easy through their framework. And of course you can progressively enhance your app with JS if available.
I generally try to do as much as I possibly can using pure CSS because half the time I regret using JS for things unless it is absolutely necessary
No one says JS has to be used for weird and creepy tracking purposes.
Let me tell you, it was a gas. So many broken pages. Such a wide range of performance and "user experience". Browsing with Dillo was like looking at the internet through an abstract art painting, which was even more striking because I still remember when I could actually browse most websites with Dillo, and now links2 -g (remember how Links has graphics mode?) is literally more usable for browsing the web.
Turns out Epiphany is extremely minimal, fast, and renders pages well (and even supports Firefox Sync? that's cool), so I'm gonna try that as a daily driver.
It doesn't help if like Eevee you do have an account and are actually tweeting, but if all you're doing is browsing then it runs completely Javascript-free.
----
In regards to the actual content of the article, it's an eye-opening experience to dig into how a lot of these pages are constructed and to realize that sites like Google search, Facebook, Twitter are not really designed around having the simplest most performant implementations.
There is some dark eldritch magic that happens behind the scenes on a lot of these sites that keeps them working with accessibility readers and nothing else: trying to make it harder to find hrefs, trying to get rid of right-click open in new tab commands, trying to make it impossible for browser extensions to identify parts of the HTML. And I think it's really easy at first to say, "this is a complicated problem we don't understand, of course this must be a super-performant hyper-optimized way of doing everything." But it just becomes harder and harder to justify that over time. The link wrapping that Google search does really doesn't have anything to do with performance, it's designed to close holes around how people open links without sending pingbacks to Google servers.
There is a real incentive battle between tracking/control and simplicity/performance/flexibility, and the performance side doesn't always win, it seems that big companies are actually willing to introduce a huge amount of engineering complexity for an outcome that's almost as good as a normal href but that allows them to accomplish other goals as well.
The level of complexity in these sites sometimes gets used as an excuse to avoid criticism, but I think that sometimes the complexity is there purely because sites are actually fighting with browser technology; Google's setup for link wrapping is very complicated, Twitter's text entry is very complicated, because they're trying to take control of a process that they don't normally have control over. So they build very complicated houses of cards that fall over in weird situations, and the complexity of the house of cards becomes the defense against criticism that the house of cards keeps falling over.
I look at projects like Nitter; Nitter is not a full Twitter replacement, but in regards to the parts of Twitter that it does replace, it's better engineered. It's less complicated, the engineering is less impressive, but impressive engineering is not the same thing as good engineering. For the features it's replicating, Nitter works better than the real thing, and I think the reason is that it's less complicated and that it's fighting less with the browser.
This is why I "print" web pages to PDF these days instead of saving as HTML.
With no amount of client-side javascript could you ever hope to build something that brings fresh business data to a customer's eyeballs faster than if the server simply delivers the final DOM on the initial page request.
Our Blazor web apps are running in server-side mode, and they are some of the fastest web applications that we use on any given day. Server-side doesnt necessarily always mean full page reloads upon interaction. Websockets are pretty cool.
Hackernews is the only other website that feels approximately as fast to me.
I'm thinking o using blazor server in a production app, but the latency and higher costs may be a problem. Wasm is not ideal for me because of the high initial payload.
I am taking a look into htmx. It looks way closer to what html is and it is more than enough for my purpose at least.
https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
HN usually hates on misuse of JS pretty hard.
With webassembly we might start seeing compiled websites and we’ll miss the good old days of simple JavaScript.
The tools we have available today to optimize JS and build for progressive enhancement are light years ahead of 2016 because the smartest minds in the industry have optimized for it. The rise of batteries-included server-side-rendered React apps like Remix and Next massively cut down on time-to-first-paint and React 18 makes it easier than ever to defer rendering of async or interactive portions of the page (e.g. the Like count, the reply form) in favor of getting static content on the screen as fast as possible.