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’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 didn’t know about that! Thanks, would have saved me hours over time.

> 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:

    <input type=”date”>

We’ve had date pickers and modals, and scroll snapping gets you halfway to carousels.

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.

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.

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

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/

> 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.

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.