On the topic of tables and JavaScript and using vanilla HTML:
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.
To me, I think this is where HTML standards went off the rails.
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
> Where's our OOTB carousel, date picker, rich drop-down with icon/subtext, form elements supporting AJAX state, modal windows? etc etc.
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.
Exactly my point — compare the feature set of this, vs the experience you'd expect from an airline or hotel booking site. Stuff like entering a date range or showing additional info inline is impossible (colour-coded availability or price details, say).
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.
The general purpose solution is for the browsers themselves to implement the equivalent of virtualization and table sorting features and for authors and publishers to stay out of it and stick to sending the right bytes, making sure everything is marked up correctly. A Web developer is never going to be able to ship a JS blob that makes tables work the way his or her users want them to, only the way that he or she thinks works well (if that). So just put a table on the page and add links to educate people about which browsers and/or add-ons make viewing tables a good experience. If you have some compulsion to be involved in this any further, then write your own add-on and link to that.
This is where HTML/DOM differs from all other UI frameworks. Everything else has collections with custom datasets and scrolling windows. HTML does not, because it is winword derivative.
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 found it way easier to keep table logic on the server since that's almost certainly where the data lives. Any filtering, sorting, pagination, etc in the client should just trigger an AJAX call PR similar (HTMX works great here) to request an updated table and swap in the new markup.
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.
This feels like the complete opposite in terms of performance. Plus it fails to cover any case where we’re just not reporting database records. Eg. Client-side data generation and analysis.
Performance is a whole other ball of wax. A comparison can be done, but you have to set context first with regards to the size and shape of the data set, network conditions, filtering/sorting features, etc. You'd really want to factor in database bandwidth limitations at that point, as any fully client-side table library will need to load all the data first.
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.
> If you are a user of github.com, consider how it has changed since 2020.
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.
In my opinion it’s gotten worse in favor of cost savings. Two biggest examples: if you leave more than 10 code review comments on a PR, it hides them under a “show more” link. Time and time again my reviews get ignored, so I’ve started subconsciously picking my battles when doing a one. That might be good on small PRs so that you don’t go into the weeds nit-picking, but on a big gnarly one it’s an anti-feature. And in any case, I don’t want Microsoft’s cheap UI to inform the code review etiquette of my team. Second example: if a file in a PR has a large diff, it will not be loaded, you have another “show more” link. That file is probably the part of your PR most in need of review, but again, on my PRs my teammates often skip right past it because it’s hidden by default.
That's a fair complaints. However, it's clearly a design decision, whereas the author is trying to imply that it's gotten generally worse because they switched to using a frontend framework.
I agree with her. I appreciate the new code navigation stuff a bit, but not at the cost it’s imposed on my workflow. A pull request used to be a regular web page. I could refresh it, search it with ctrl-f, reliably link to a specific line, etc. Now it’s a crapshoot. If you refresh there’s no guarantee you’ll land anywhere near where you were. Page loads take forever so I can’t easily open multiple tabs to cross-reference the code I’m reviewing. If you link to some code that was within a diff that you had to “show more” to open, well, who knows where the link will land you.
I looked a bit into the JavaScript loaded when going to GitHub and my best guess as to what it’s using react for is the copilot chat.
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.
some frontend frameworks - the React like ones - make that kind of design decision so easy to do that you might just do it without arguing if it was a good decision or not.
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.
Indeed, being able to click on a variable in code and get a panel on the right that lists every occurrence of the variable including the definition is such an improvement over how it used to be. That feature alone makes GH2024 superior.
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 use an alternative Github front-end called Graphite that is faster and more reliable than GitHub.com, and it’s a React single-page app.
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 :-/
Ironic that this person claims GitHub UI was something to be proud of when it’s far from good UX when it comes to browsing code.
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.
browsing code is one usecase. opening issues (and having many tabs of issues open), discussing pull requests is another one. I don't think an SPA would be suited for that kind of content. Discourse might be a counter-example, but they had to do strange things for SEO, and some of its UX choices are also controversial.
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.
While I have learn web development when blink was still trending, I have had my period where I tried to force every frontend into becoming a react app. I have since then wisen up, and tend to agree that for frontend - best to start with as simple as possible and increase complexity and add dependancies as it is needed. "Write JavaScript like it’s 2005" is good advice.
I mostly share the author’s position, but to be fair, GitHub’s UI did massively improve over the past decade. So much so that the rest of my company — even non-developers — were happy to drop Jira and do all product management in GitHub.
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).
To be fair, switching from Jira to just about anything else would be an improvement. :-) Source: about 2-3 years working on a team that used Jira extensively.
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).
I thought Jira's slowness was just me, because our server is in the US and I'm in Asia and they designed it so that any lag in communicating with the server gives you a terrible experience in their frontend. Turns out no, it's slow for everyone: https://ifuckinghatejira.com/57/
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).
I notice the website now redirects to the path /no-yc apparently our presence has been felt. It's using a redirect based off the referrer, you can strip the path off the URL and browse to the article. I agree that JavaScript should be used sparingly, but you can't deny there are amazing things done in JavaScript and the list keeps getting larger.
> 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.
It shows clearly that Flutter for web is hot garbage. It is flaky (Safari on iOS 18, iPhone 15 Pro Max), it doesn’t let me select text or copy-paste anything. Rendering the UI in a Canvas works only for niche apps.
More precisely Safari is quite behind on its WebAssembly implementation.
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/
On the topic of tables and JavaScript and using vanilla HTML:
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.
To me, I think this is where HTML standards went off the rails.
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
> Where's our OOTB carousel, date picker, rich drop-down with icon/subtext, form elements supporting AJAX state, modal windows? etc etc.
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...
[2] https://chromestatus.com/feature/5112013093339136
[3] https://open-ui.org/components/carousel.research
Here:
Exactly my point — compare the feature set of this, vs the experience you'd expect from an airline or hotel booking site. Stuff like entering a date range or showing additional info inline is impossible (colour-coded availability or price details, say).
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.
We’ve had date pickers and modals, and scroll snapping gets you halfway to carousels.
IMO "virtual rendering" in general is one of the biggest weaknesses of the web platform. I would love to see a general-purpose solution to this.
The general purpose solution is for the browsers themselves to implement the equivalent of virtualization and table sorting features and for authors and publishers to stay out of it and stick to sending the right bytes, making sure everything is marked up correctly. A Web developer is never going to be able to ship a JS blob that makes tables work the way his or her users want them to, only the way that he or she thinks works well (if that). So just put a table on the page and add links to educate people about which browsers and/or add-ons make viewing tables a good experience. If you have some compulsion to be involved in this any further, then write your own add-on and link to that.
This is where HTML/DOM differs from all other UI frameworks. Everything else has collections with custom datasets and scrolling windows. HTML does not, because it is winword derivative.
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.
Have you tried Tanstack, they have a headless solution that is pretty neat. Also work with vanilla.
I've found it way easier to keep table logic on the server since that's almost certainly where the data lives. Any filtering, sorting, pagination, etc in the client should just trigger an AJAX call PR similar (HTMX works great here) to request an updated table and swap in the new markup.
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.
This feels like the complete opposite in terms of performance. Plus it fails to cover any case where we’re just not reporting database records. Eg. Client-side data generation and analysis.
Performance is a whole other ball of wax. A comparison can be done, but you have to set context first with regards to the size and shape of the data set, network conditions, filtering/sorting features, etc. You'd really want to factor in database bandwidth limitations at that point, as any fully client-side table library will need to load all the data first.
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.
I love tansack but even better is inertiajs, no need for an API. You get the benefits of spa without paying the tax of writing api
> If you are a user of github.com, consider how it has changed since 2020.
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.
In my opinion it’s gotten worse in favor of cost savings. Two biggest examples: if you leave more than 10 code review comments on a PR, it hides them under a “show more” link. Time and time again my reviews get ignored, so I’ve started subconsciously picking my battles when doing a one. That might be good on small PRs so that you don’t go into the weeds nit-picking, but on a big gnarly one it’s an anti-feature. And in any case, I don’t want Microsoft’s cheap UI to inform the code review etiquette of my team. Second example: if a file in a PR has a large diff, it will not be loaded, you have another “show more” link. That file is probably the part of your PR most in need of review, but again, on my PRs my teammates often skip right past it because it’s hidden by default.
That's a fair complaints. However, it's clearly a design decision, whereas the author is trying to imply that it's gotten generally worse because they switched to using a frontend framework.
I agree with her. I appreciate the new code navigation stuff a bit, but not at the cost it’s imposed on my workflow. A pull request used to be a regular web page. I could refresh it, search it with ctrl-f, reliably link to a specific line, etc. Now it’s a crapshoot. If you refresh there’s no guarantee you’ll land anywhere near where you were. Page loads take forever so I can’t easily open multiple tabs to cross-reference the code I’m reviewing. If you link to some code that was within a diff that you had to “show more” to open, well, who knows where the link will land you.
Doesn’t github use Rails and web components? They definitely gotten more frontend heavy though…
https://github.blog/engineering/architecture-optimization/ho...
The Github frontend appears to be React now.
That said, most (not all) of it still works with Javascript disabled
I looked a bit into the JavaScript loaded when going to GitHub and my best guess as to what it’s using react for is the copilot chat.
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.
some frontend frameworks - the React like ones - make that kind of design decision so easy to do that you might just do it without arguing if it was a good decision or not.
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.
Indeed, being able to click on a variable in code and get a panel on the right that lists every occurrence of the variable including the definition is such an improvement over how it used to be. That feature alone makes GH2024 superior.
I don't want to have to clone a repo every time I want to browse code with a better experience than Notepad.
It’s completely unusable on iOS. Back and forward functionality only work intermittently among a bunch of other problems.
I’ve noticed the same with YouTube.
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 just tried YouTube And back and forward works just fine. Exactly how I would expect. Can you expand more on what you see?
Safari on macOS, it randomly happens throughout the day. No real details beyond that.
I use an alternative Github front-end called Graphite that is faster and more reliable than GitHub.com, and it’s a React single-page app.
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 :-/
Ironic that this person claims GitHub UI was something to be proud of when it’s far from good UX when it comes to browsing code.
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.
Have to disagree
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 didn’t know about that! Thanks, would have saved me hours over time.
browsing code is one usecase. opening issues (and having many tabs of issues open), discussing pull requests is another one. I don't think an SPA would be suited for that kind of content. Discourse might be a counter-example, but they had to do strange things for SEO, and some of its UX choices are also controversial.
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.
The fundamental differences is that the old GitHub was trying to be git's web UI, and the GitHub under MS is trying to be an IDE.
While I have learn web development when blink was still trending, I have had my period where I tried to force every frontend into becoming a react app. I have since then wisen up, and tend to agree that for frontend - best to start with as simple as possible and increase complexity and add dependancies as it is needed. "Write JavaScript like it’s 2005" is good advice.
a sortable table needs only a dash of JavaScript
On the wall of naive sentences, this one deserves to be framed.
if the arrow up/down click just fetched the appropriately sorted table from the server and replaces the dom, I guess it’s true.
I mostly share the author’s position, but to be fair, GitHub’s UI did massively improve over the past decade. So much so that the rest of my company — even non-developers — were happy to drop Jira and do all product management in GitHub.
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).
To be fair, switching from Jira to just about anything else would be an improvement. :-) Source: about 2-3 years working on a team that used Jira extensively.
I completely agree[0].
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).
[0]: https://ifuckinghatejira.com/
I thought Jira's slowness was just me, because our server is in the US and I'm in Asia and they designed it so that any lag in communicating with the server gives you a terrible experience in their frontend. Turns out no, it's slow for everyone: https://ifuckinghatejira.com/57/
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).
I notice the website now redirects to the path /no-yc apparently our presence has been felt. It's using a redirect based off the referrer, you can strip the path off the URL and browse to the article. I agree that JavaScript should be used sparingly, but you can't deny there are amazing things done in JavaScript and the list keeps getting larger.
Increasingly you can avoid JavaScript altogether with WebAssembly if you're making an application more than a set of hyperlinked documents.
Here's a demo of Dart and Flutter in WebAssembly: https://flutterweb-wasm.web.app/
How accessible is it? Does the performance remain if you enable Flutter’s “accessibility mode”?
(Hint: it doesn’t, and isn’t fit for purpose for applications with users)
> 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.
It shows clearly that Flutter for web is hot garbage. It is flaky (Safari on iOS 18, iPhone 15 Pro Max), it doesn’t let me select text or copy-paste anything. Rendering the UI in a Canvas works only for niche apps.
More precisely Safari is quite behind on its WebAssembly implementation.
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.