Not OP but I don’t really care if it was or not. All I know is that I’ve been using the Spotify app 10+ years and it works well. I don’t know if this random app works, and if it hasn’t been supervised I doubt it does.
There are a lot of large projects where X.1 is newer than Y.0. You release a new major version for breaking changes, but you backport security changes to previous major releases as well.
gist was certainly not implying that it was not possible to do it or that some people won't continue doing it but the point was rather that the pool of such people or such projects will significantly decrease because software has now (mostly) reached the abundance state where all of these technical details start to matter less and less for general consumption.
are you saying that you can do a better job than frontier models from OpenAI and Anthropic and Google when it comes to coding something that is free from zero days and exploits while matching its ability to ship feature at the rate a competent SWE with agents can?
not sure why you are being so cynical, lot of seasoned SWE use AI assisted development now.
I think a lot of people still have this caricature vibe coder image but competent and serious engineering companies and big and large have embraced agentic coding.
you certainly would not get hired and would come across as highly egoistical if you insisted on writing every piece of code by hand in 2026.
Frontier models from OpenAI/Anthropic/Google make tons of mistakes. I work with them every single day and you really have to verify everything if you don’t want to end up with overengineered spaghetti code full of bugs.
This is… not obvious. It's only easy if you want the simplistic approach of sorting lexicographically or numerically. But in more complex tables, you will often encounter cases where the data representation for sorting is different from data representation for display.
Of course most JavaScript-based tables get this wrong, too.
I had always thought that table sorting seems like the perfect job for HTML, given its data-driven nature, and the possibility of implementing sort information into the attributes of table cell elements.
But thinking about it: Is there a precedent for HTML to be able to include information that instructs the device to present the DOM out of order? Maybe it's out of scope for HTML to have information about presentation order, when the order is supposed to be implied strictly by the DOM hierarchy itself.
Of course, CSS can visually reorder stuff (e.g. `order` on flex/grid items), but MDN has accessibility warnings regarding the use of `order` and visually presenting the data in an order not reflected by the DOM. So, maybe sorting is best done by reordering the DOM after all.
CSS now also has `reading-flow` to instruct the browser to change the reading order to match the visual order created by Flex or Grid. Unfortunately, not all browsers support it and it has some limitations.
And related to that, native cell recycling for long lists would be nice, particularly with cases where the cells are on the heavy side.
Yes, it can be done with JS, but nothing is going to beat the browser engine for frequent DOM manipulation of that sort. It's also just one less dependency to have to pull in.
> Want sortable tables? Get a jquery plugin and spend five minutes, done.
I want sortable tables without having to rely on a third-party plugin to a third-party library. HTML describes content, not just layout. It would be a `sortable` attribute on the table, just like you already have attributes that have nothing to do with layout such as `autocomplete` or `aria-*`.
Everyone already complains that browsers are too bloated and now you want to have every browser support sortable tables when a single, simple JS file would work?
The overwhelming majority of web pages are static documents, and it's a document format, so basic document primitives make sense. Same with something like line charts or pie charts. Bloat is things like USB APIs that present obnoxious security surfaces.
It's all fine and dandy until marketing bros decide to shove all kinds of shady modals into that JS file. The JS side is not exclusive to trivial interactivity.
It's open source software. You can see what it does, and you just put it on your server. We're talking about pre NPM javascript here, no continuous deployment, everything is vendored and local and no one is going to change that file without your knowledge and permission. And if someone does, you have much bigger problems on your hands.
What you can't own and control is the browser vendors and how they choose to implement things, or not to. You can edit a JS file to your specific needs, but you're stuck with whatever the browser decides.
My point was, people block js of websites by default. Why? Cause website devs abuse js and don't exclusively use it for basic interactivity of stuff like sorting table columns.
There is an incentive to use HTML for common interactivity purposes.
HTML has done interactivity before JS existed. No reason to not add support for sorting tables. JS is better suited to only handle non-standard cases where no native functionality exist as browser vendors can afford to spend infinitely more time to make sorting better than you can spend on doing it for one website.
> explicitly and implicitly describe the layout of an HTML document.
No, this doesn't happen.
> In fact, "HTML" itself is an acronym (HyperText Markup Language)
Duh.
> in which the "Markup" describes the function of HTML to "mark up" text in a similar way that editors once did in the print industry, describing which parts of the text should be bold, italicized, etc. or divided up and in what way.
This statement is mendacious, at best. I have explained that HTML has fuck-all to do with layout. I can explain it to you, but I can't understand it for you.
Here, check out what the W3C has to say about it:
> Because HTML conveys meaning, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. ... But it goes further than just differences in screen size: the same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g. using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.
Also, check out the ACID series of specifications which require and always use CSS, because otherwise, there is no mandate on how a browser should display stuff.
And, just for completeness, here are a couple of quotes from Tim Berners-Lee:
> HTML should convey the structure of a hypertext document, but not details of its presentation. This was the only way to get it to display reasonably on any of a very wide variety of different screens and sizes of paper.
> The separation of presentation from structure is a fundamental principle of the Web. HTML documents represent the logical structure of the document; style sheets provide formatting instructions.
Now, I will grant you during the browser wars of the 90s when everybody was trying to get ahead, some layout elements were stupidly added to HTML, and copied by other browsers. But these came nowhere near close to being definitive layout descriptions, and since at least 1997, the W3C has advocated for separating content into HTML, and presentation into CSS.
I used to do this in the early 2000s! Some folks back then would ask whether i was afraid that clicking a link (which loads a "new" web page) would slow things down and create an awful experience for users...but, my team and I would really focus on keeping web pages slim/lightweight to begin with...so it rarely was a problem. I don't think we were geniuses or anything like that, but keeping things light (always and from the beginning) enabled us to "cheat" (like this "hack" of the links in the column headers) in ways that were beneficial but with very low risk. Sometimes it took an extra moment or two at the beginning of an effort...but it ALWAYS paid off down the road, and in many different ways.
So instead of using JS to sort the table directly, now you make a JS fetch() request to sort the table?!
It does make sense in one situation, if the table is a large server-side paginated one and the sorting is really an ORDER BY clause. But for a basic table that fits entirely on the client, it doesn't make sense at all. There are tiny JS libraries that will make
> Did you know that we name around 2,000-3,000 new products every year?
I find this surprisingly high; I guess it’s _products_ and not _names_, meaning that five colors of the same product count as five new products but only one name.
They don't just sell furnitures, there is all the small accessories like cutting boards, plates, bowls, towels, cushions... Everything they're selling at their lowest floor before you reach the self-serve warehouse.
Also they insist on replacing perfectly good products to sell inferior ones (for bigger margins I guess).
Every visitor rave about and ask us where we bought our corkscrew but we can only reply it was in IKEA but they decided they are too good for us so replaced them with inferior ones. Same happened wuth a vegetable peeler that I let go when I divorced but should have fought for because I never found one as good and IKEA enshittification made sure I can't buy it again.
