JavaScript dos and donts Mu-An Chiou
muan.co
muan.co
Lately I’ve felt especially frustrated that I’m wasting so much time dealing with performance for data tables, a concept that has been so thoroughly solved for decades in desktop applications. Feels like there should be a vanilla html option for a table that:
- supports massive collections (“virtual tables”)
- sortable, filterable by header
- overflowable cells
- user resizable column widths
- user show/hide columns
- freeze columns/rows
- performance!
- no strong opinions on style
I struggle to find one solid option that fits all of that. Usually I have to make a sacrifice and then wrestle with the library of choice for that missing feature.
Tanstack table, and really any table library running in the browser, is extremely heavy and complex to manage and maintain. You either end up with a copy of your entire dataset living in the browser memory or any changes to the view still requests to the server, getting back JSON instead of HTML. That JSON has to be parsed, merged with the current state, and run through client-side rendering logic to update the DOM to end up with the HTML that could have been rendered on the server directly from the original data source.
My primary point was on the simplicity of the stack and ease of maintaining. I would expect a performance gain in most cases as well, though there are definitely cases where client-side would perform better.
Rather than working on, say, the vibration API, give us built in web components that are stylable but also accessible by default.
In 2024, half of the things in Bootstrap or Tailwind UI should be obsolete. Where's our OOTB carousel, date picker, rich drop-down with icon/subtext, form elements supporting AJAX state, modal windows? etc etc.
All of these things should be as foolproof as an unordered list for devs to implement & the quality of websites in terms of performance & accessibility would be lifted massively
You might want to take a look at what browsers have been working on lately, because a lot of what you're asking is either already here or actively developed. Some of it driven by the Open UI working group (https://open-ui.org).
- Modal: see the <dialog> element, with its focus trapping out of the box, stylability through the top layer, entry and exit animations through @starting-style and the ability to transition discrete properties like `display`, etc.
- Rich dropdown: browsers now support popovers, which allow you (without any JS) trigger a popover that overlays the screen in the top layer, and with automatic focus management. See also the work being done on stylable <select> elements, there's a great episode of Off The Main Thread that goes deep into all the work being done to make this happen [1].
- Carousel: see the recent work on stylable <details> elements [2], and in general the carousel project at Open UI. After <select>, the carousel is one of the main focus areas.
[1] https://offthemainthread.tech/episode/stylable-select-elemen...
<input type=”date”>Then you get onto `type="datetime-local"` and there's just no input for times at all apart from typing manually in the input field.
Google make the browser & even they don't use `input type="date"` on Google Calender — the gap is too far between the desired look & feel/functionality vs what's possible so people end up reimplementing it, which is a complete waste of everyone's efforts.
From there it all went downhill and regular html developers didn’t even realize it.
It’s not only about tables, but all lists, grids, trees, icon views, tiles, etc.
No amount of frameworks and code that re-enables that can convince html to implement it.
I've been a GitHub user since around 2016. My overall impression is that it's gotten slightly better over the last couple of years but not really changed that much.
https://github.blog/engineering/architecture-optimization/ho...
That said, most (not all) of it still works with Javascript disabled
It’s still using turbo rails and doing full ssr reloads. Something very at odds with react router which it’s also loading.
It’s still loading catalyst (their homebrew web component lib) which from what I understand doesn’t seem to offer react bindings. It even loads lit (another web component lib), which I couldn’t find the react bindings for.
If it’s just for the copilot chat I’d still say GitHub is mainly rails based though would love to hear if anyone has any more / better insight.
Not that it is particularly difficult with Vanilla JS etc. but maybe slow enough you think, hey why are we doing this?
React it's 5 seconds to do, you are done so quick with the actual code you might not consider the implications.
I don't want to have to clone a repo every time I want to browse code with a better experience than Notepad.
Yes, these are obviously separate properties - I’m moreso noting that it’s absurd that multiple large separate properties with well compensated engineering teams have shipped messed up basic back/forwards functionality in 2024.
I typically try to find the most charitable take on something but this kind of thing is consistently blowing my mind.
I’ve always thought of GitHub’s turbolink repo tabs as flaky and their full-page navigations as slow. It’s much better as an app (Graphite) than as a series of websites. The UX of GitHub.com has evolved at a glacial pace :-/
I do think it was very impressive in terms of functionality especially without relying on JS, possibly the most powerful and well crafted UI on the web, but still it was deeply flawed from a UX standpoint.
They lacked many critical features for viewing source code, like linking function definitions, or expanding directories without relying on a load.
I’m sure that the GitHub front end team was of the opinion that users should just clone every repo they interact with and use their own editors instead of the GitHub website. However this has always been a bit of a hassle compared to using the website, so I very rarely find myself doing this.
These critical features you mention are just nice-to-haves for me and I imagine most people as well. I am able to read and navigate fast on github.com. I think majority of code I read happens there and not in my IDE.
The shortcuts to navigate fast can be quite obscure but the capability is there, out of the box. In particular I like the t hotkey for the repository filesearch (this more often than not removes the necessity to click through directories) and the codesearch is just impressive.
I was mildly intrigued when github.dev launched and I could just open vscode in my browser. best of both worlds in a sense, just not very well integrated into each other.
On the wall of naive sentences, this one deserves to be framed.
That’s not going to strictly be down to how the JavaScript is written, but even as someone also in the anti-JS camp, I don’t think I would want to write a file explorer and code editor without something like React (or in my case, Elm).
My point however is that for a long time, GitHub was seen among business people as a tool just for programmers. The product has matured enough that it’s now generally approachable for non-nerds (although business people still find Markdown weird and hard).
And Markdown is weird and hard once you want to do anything more advanced than basic bold/italics, links, and bulleted lists. Mostly because there was no formal syntax and every site implements slightly different extensions so there's like half a dozen different "flavors" of Markdown. We devs just forget about that because we've gotten used to the GitHub flavor. But it is indeed a weird syntax; its only advantage is that HTML is even weirder and harder to type. (Which is a big advantage, don't get me wrong).
Here's a demo of Dart and Flutter in WebAssembly: https://flutterweb-wasm.web.app/
This implementation of Visual Basic 6 written in C# compiled to WebAssembly also works better in Chrome, Edge, and Firefox than it does in Safari: https://bandysc.github.io/AvaloniaVisualBasic6/
Safari must catch up.
(Hint: it doesn’t, and isn’t fit for purpose for applications with users)
Of course it is. It's being used for real world applications right now.
You shouldn't worry that WebAssembly will displace JavaScript for application development on the web. That's coming. WebAssembly brings all languages to the web.
Don't fear it, embrace it.