It was my reason for switching to React when I learned TypeScript after getting more into JS frameworks via Vue.JS.
My starting point was Vue 2.7, and I started out using string templates haha :)
Even wrote some reactive custom code (without Vue, just regular DOM code) in a customer widget that utilized Object.defineProperty et al, inspired by Vue.
And today, while I'm using React at $job, I also think Vue 3 is probably a solid framework as well.
Last time I checked, they improved on DX of their component and templating system. But I'm not even sure whether they still recommend the v-if etc helper tags.
For what it's worth, even Vue 2 always also supported JSX and later TSX
Only if you work in a hospital. And who would be crazy enough to build hospital IT on Windo.. oh, wait.
I haven't tried Win11 on personal hardware so far, but since Win8, boot times are not much of an issue in my experience.
Making the whole OS the vehicle for a rent-seeking vendor lock-in scheme built to make you pay more and more to keep up the same set of functionality is more of a problem I think.
When people claim that there is such a thing as "X% accuracy in reasoning", it's really hard to take anything else seriously, no matter how impressive.
AI (and humans!) aside, claiming that there was an oracle that could "answer all questions" is a solved problem. Such a thing cannot exist.
But this is going already too deep IMO.
When people start talking about percentages or benchmark scores, there has to be some denominator.
And there can be no bias-free such denominator for
- trivia questions
- mathematical questions (oh, maybe I'm wrong here, intuitively I'd say it's impossible for various reasons: varying "hardness", undecidable problems etc)
- historical or policital questions
I wanted to include "software development tasks", but it would be a distraction. Maybe there will be a good benchmark for this, I'm aware there are plenty already. Maybe AI will be capable to be a better software developer than me in some capacity, so I don't want to include this part here. That also maps pretty well to "the better the problem description, the better the output", which doesn't seem to work so neatly with the other categories of tasks and questions.
Even if the whole body of questions/tasks/prompts would be very constrained and cover only a single domain, it seems impossible to guarantee that such benchmark is "bias-free" (I know AGI folks love this word).
Maybe in some interesting special cases? For example, very constrained and clearly defined classes of questions, at which point, the "language" part of LLMs seems to become less important and more of a distraction. Sure, AI is not just LLMs, and LLMs are not just assistants, and Neural Networks are not just LLMs...
There the problem begins to be honest: I don't even know how to align the "benchmark" claims with the kind of AI they are examinin and the ones I know exist.
Sure it's possible to benchmark how well an AI decides whether, for example, a picture shows a rabbit.
Even then: for some pictures, it's gotta be undecidable, no matter how good the training data is?
I'm just a complete layman and commenting about this; I'm not even fluent in the absolute basics of artificial neural networks like perceptrons, gradient descent, backpropagation and typical non-LLM CNNs that are used today, GANs etc.
I am and was impressed by AI and deep learning, but to this day I am thorougly disappointed by the hubris of snakeoil salespeople who think it's valuable and meaningful to "benchmark" machines on "general reasoning".
I mean, it's already a thing in humans. There are IQ tests for the non-trivia parts. And even these have plenty of discussion revolving around them, for good reason.
Is there some "AI benchmark" that exclusively focuses on doing recent IQ tests on models, preferably editions that were published after the particular knowledge cutoff of the respective models? I found (for example) this study [1], but to be honest, I'm not the kind of person who is able to get the core insights presented in such a paper by skimming through it.
Because I think there are impressive results, it's just becomimg very hard to see through the bullshit at as an average person.
I would also love to understand mroe about the current state of the research on the "LLMs as compression" topic [2][3].
I see your point. But accidental complexity is the most uncomfortable work there is to me. Do programmers really find so much fun in creating accidental complexity?
Removing it, no matter whether I created it myself, sure, that can be a hard problem.
I've certainly been guilty creating accidental complexity as a form of procrastrination I guess. But building a microservices architecture is not one of these cases.
FWIW, the alternative stack presented here for small web sites/apps seems infinitely more fun.
Immediate feedback, easy to create something visible and change things, etc.
Ironically, it could also lead to complexity when in reality, there is (for example) an actual need for a message queue.
But setting up such stuff without a need sounds easier to avoid to me than, for example, overgeneralizing some code to handle more cases than the relevant ones.
When I feel there are customer or company requirements that I can't fulfill properly, but I should, that's a hard problem for me. Or when I feel unable to clarify achievable goals and communicate productively.
But procrastrination via accidental complexity is mostly the opposite of fun to me.
It all comes back when trying to solve real problems and spending work time solving these problems is more fun than working on homemade problems.
Doing work that I am able to complete and achieving tangible results is more fun than getting tangled in a mess of unneeded complexity. I don't see how this is fun for engineers, maybe I'm not an engineer then.
Over-generalization, setting wrong priorities, that I can understand.
But setting up complex infra or a microservices architecture where it's unneeded, that doesn't seem fun to me at all :)
Normally the impetus to overcomplicate ends before devs become experienced enough to be able to even do such complex infra by themselves. It often manifests as complex code only.
Overengineered infra doesn't happen in a vacuum. There is always support from the entire company.
"Do programmers really find so much fun in creating accidental complexity?"
I certainly did for a number of years - I just had the luck that the cool things I happened to pick on in the early/mid 1990s turned out to be quite important (Web '92, Java '94).
Now my views have flipped almost completely the other way - technology as a means of delivering value.
Edit: Other cool technology that I loved like Common Lisp & CLOS, NeWS and PostScript turned out to be less useful...
I see what you mean, sometimes "accidental complexity" can also be a form of getting to know a technology really well and that can be useful and still fun. Kudos for that :)
Modern urban car infrastructure is neither space- nor energy-efficient, but urban planning is long-term, and decisions shift all efficiency considerations in the long-term in a way that's hard to undo.
For example, transportation of people with the modern extensive net of streets would be most convenient and efficient if there was some kind of public transportation in small buses, available on demand and price being determined by regular market mechanisms. The difference between what I imagine and things like Uber would be a strong integration with existing train and bus lines, and public funding and legislation. Maybe self-driving will get us there, but there are also many political hurdles that make the less efficient option (high coefficient of cars pp) more attractive than the alternative that could provide better efficiency (and, ideally, also great user experience).
On demand is bad! People have places to be and they need to be able to depend on arriving on time. on demand means they can't be sure when the transport will detour to pick someone else up thus making them late. what we need are reliable fixed routes that are predictable.
making on denand reliable means that there are more vehicles driving around than we now have cars - as empty vehicles reposition just in case someone else wants to go someplace right after you.
> making on denand reliable means that there are more vehicles driving around than we now have cars - as empty vehicles reposition just in case someone else wants to go someplace right after you.
I was explicitly refering to buses because of that, or had in mind something like modern IT plus ride sharing: to use cars more efficiently.
And, in opposition to the other comment thread, my opinion is that this would improve the quality of life for people in the long-term (in urban areas, even in the relatively short term).
But without FSD, it requires drivers, so it requires more complex considerations than "just" directing cars to where there needed.
At this point, the discussion becomes tiresome and political.
But to me, the convenience of personally owned vehicles combined with the public infrastructure needed for them is inefficient in a way that affects people negatively in urban spaces.
"Space efficiency" to me would also mean to stop making life worse for people who, for whatever reason, happen to be outside but not in a car or, god forbid, need to get to places without owning a car.
I'm not dreaming of a world without cars, but I detest the concrete wasteland that I have to live in for having destroyed quality of life in favor of an excess of parking and driving areas. So I'd certainly like a world with way fewer cars and certainly I am against further increasing excess cars per person. But, like I said, to use cars efficiently, there needs to be a consensus.
Because cars require public space, and lots of it.
I would not deny this, and I don't judge people for enjoying to drive. It doesn't prevent me from thinking about alternative worlds / cities though, or in this case, just a stronger focus on establishing public car-based transportation (such as buses), in addition to train lines, which take very long to be built or are currently lacking space to be built altogether, where they would be most needed.
There is absolutely nothing less pleasing than sitting in traffic in a major North American city with aggressive drivers all around you constantly breaking laws because they think they are more important than everyone else.
In contrast European trains are down right relaxing.
Until you see the expected delay going up and you have to start doing the maths of whether you can run from X to Y in under a minute, frantically googling for a second connection and how much a taxi would cost.. (my DB experience since I usually travel by train for flights)
That is stupid. people have places to be. Only a tiny minority are on transit for fun. Everyone else just wants to be there. you do these people a massive disservice by not making their ride efficient.
and the minority who are for the ride will figure out how to make it work.
Even with a job I'd rather spend an hour on a train than 35 minutes in LA traffic. (30 minutes... I guess I'd prefer the stress + a little more time for breakfast. But I'd put a 2x multiplier on not having to drive myself)
Your goal is still being there though, not riding the train. After a few trips you have seen the scenery out the window and just want the trip over with (though maybe you can enjoy the book you are reading most days or whatever you are doing and call it relaxation)
Reading a book is being productive. You can also write, work, or nap. In contrast driving is the biggest waste of time in a persons life. I feel so strongly about this that I’d accept a vastly smaller house just to minimize time travelling. Second best to that is not driving so that I can make use of my time.
What I can't do is start making supper for my family. I can't play games with my family. I can't practice my drums. I can't make chips on my lathe. There is a very long list of things people want to do in life that cannot be done. If what you happen to want to do at the moment is something you can do on transit good for you - but for many they are doing that as a second best because they can't do whatever it is they want to do.
Time matters in the above. If your trip is 15-20 minutes time to unwind seems to be universal and so almost nobody really has anything they want to do. If you trip if an hour that is cutting into other things in life. (Note that I didn't mention how you take the trip in this part, people who drive fast the same time concerns for longer trips)
I ride the train kind of recreationally. Not just to ride it but to go into town, have a coffee and check the scene, then go back, so basically recreational.
I think a lot of the non rush hour usage is like that.
The train itself is pleasant off peak - table, wifi, I drink coffee and websurf. It's a bit squished in during rush hour though.
Hello, fellow LA traffic sufferer! I used to do the 210 to the 2 to surface streets to Century City, and the 210 to the 118 to the 405 to Santa Monica. There was no transit that was going to tame those beasts :-) but a commuter motorcycle in Los Angeles is a wonderful thing.
I'm not sure. I want to see public transport in a city done with rollercoasters. The amount using it for fun would go up dramatically. It would change overnight from just another utterly boring city not worth visiting into a tourist hot spot. Similarly, people who need to be places will make it work.
Life is about the journey. All those roads and other boring means of transportation are just places no one wants to be.
A roller coaster would be fun. I've always kind of wanted a city to city flight that you could just jump out of with a parachute and land at your destination without the airport faff.
On the more realistic end of things, ebikes are fun.
>e-biking over a bridge, preferably at night — has developed its own ardent following. Liberated for the most part of any physical exertion, e-bikers can instead focus on the texture of the road vibrating up their arms, the wind streaking across their cheeks, the speed heightening their consciousness. “You do it in the evening, with the sunset — hell yeah,” https://www.nytimes.com/2025/06/05/nyregion/eric-adams-nyc-s...
Fun is good and all, if you enjoy it I won't argue. I enjoy a sunset myself from time to time. However most people are not enjoying in the moment. They want transportation only for the purposes of getting someplace so they can get something else done (or enjoy something else). Fun is good, but not everything is fun. I need to get home from work so I can get supper done in time for the evening activities (by coincidence I've been asked to make my homemade pretzels tonight - that takes 2 hours so I need to get home as soon as work is done)
I've had countless conversations with a friend of mine who thought not all things are supposed to be fun. Earning a living for example needs to involve a certain amount of suffering. If it lacks that quality he wouldn't be happy to be home and being home should be more appealing than working.
I ask him things like, what about working from home? That would be terrible! He replied with a sour face.
But the knife cuts both ways. If you hate the rollercoasters you will be so happy when it is finally over. The pretzels will taste even better.
Some will feel your suffering when they see it, some will enjoy seeing it.
Most people would have every other city in the world where they can be practical, sober or boring, depending on who you ask.
Most people can't always have what they want and they shouldn't. It wouldn't be good for them :-)
I love this. As another poster brought up, plenty of people buy enjoyable cars and motorcycles for the pleasure of driving. Why not add a little spice to life?
Spice is fine - but you still need to get places and that is the primary goal of most cars. People who have the car/motorcycle for fun only nearly all have some other vehicle they use as the "daily driver" to get places. I might take a train on a sunday drive myself once in a while.
The majority of uses should be for people trying to get someplace. If the trip is also fun that is a bonus, but if it is only fun but otherwise worthless (that is something else is enough better) your system won't get many riders.
I'm not sure, the thing is, a vehicle is also a place. I had a great time working for a company using camper vans. You get almost everything a brick house offers.
A lot of people have recreational boats. They go places but the destination isn't half the fun. With cruse ships the destination is perhaps 5-10%?
Maybe we got it all wrong. Perhaps trains should have lan gaming. Have some exclusieve game that one can only play in the train with some exclusive content for the specific trip.
One could also do exclusive interactive educational material. There is a lot to learn before you become a train driver, train manager, mechanic, engineer, cleaner, etc etc
That is great for the first week or two, and then it is common place and you just want to be there. It will be old faster if you happen to ride at the same time as someone who gets motion sickness. (or worse if you are the person with motion sickness)
As far as I'm concerned, transportation is solved. I live in Paris, there are 14 (soon to be 15) metro lines covering the city in a dense underground mesh, and you never have to wait more the 5 minutes to hop into one.
Paris doesn't have the best transit in the world, but they get credit for being very good and useful. Most of the world has a lot to learn from them. Most people don't live in places with transport anywhere near that good.
Don't get complainant. There is still a lot Paris needs to improve on. Please show the world what the next level looks like.
I think citymapper tried to execu this as a pivot. They had an idea to do it in London and other countries and did trial it for a while. Not sure why it (presumably) failed.
I'd note that startup money of the is much harder to get in London, so a US startup might be able to force the idea from experiment to profitability.
This doesn't work in cities. The vast majority of peoples movement are not immediately necessary. They can wait 10-15 minutes (or plan ahead) for efficiency. This also cuts down on costs for everyone.
On demand is bad but not for that reason. people have places to be and are bad at planning. You should be running every 5 minutes so even if they are running late it still isn't very long until you get there.
every 10-15 minutes is cheaper and so because of cost you are often forced to be this bad (or worse) just to be affordable, but it isn't what anyone wants and people who use such systems will dream of ways to make a car work where they are
Nothing weird about it, you see people arguing right here whether a site should add a new history entry when a filter is set.
Interacting with the URL from JS within the page load cycle is inherently complex.
For what it's worth, I'd also argue that the right behavior here is to replace.
But that of course also means that now the URL on the history stack for this particular view will always have the filter in it (as opposed to an initial visit without having touched anything).
Of course the author's case is the good/special one where they already visited the site with a filter in the URL.
But when you might be interested in using the view/page with multiple queries/filters/paramerers, it might also be unexpected: for example, developers not having a dedicated search results page and instead updating the query parameters of the current URL.
Also, from the history APIs perspective, path and query parameters are interchangeable as long as the origin matches, but user expectations (and server behavior) might assign them different roles.
Still, we're commenting on a site where the main view parameter (item ID, including submission pages) is a query parameter. So this distinction is pretty arbitrary.
And the most extreme case of misusing pushState (instead if replace) are sites where each keystroke in some typeahead filter creates a new history entry.
All of this doesn't even touch the basic requirement that is most important and addressed in the article: being able to refresh the page without losing state and being able to bookmark things.
Manually implementing stuff like this on top of a basic routing functionality (which should use pushState) in an SPA is complex very quickly.
> But that of course also means that now the URL on the history stack for this particular view will always have the filter in it (as opposed to an initial visit without having touched anything).
I would have one state for when the user first entered the page, and then the first time they modify a filter, add a 2nd state. From thereon, keep updating/replacing that state.
This way if the user clicks into the page, and modifies a dozen things they can
1. Refresh and keep all their filters, or share with a friend
2. Press back to basically clear all their filters (get back to the initial state of the page)
3. Only 1 more press of back to get back to where-ever they came from
Abandonware is a clickbait title insofar as it normally refers to licenses, not standards.
The idea of the author seems to be that this part of the DOM API that could benefit from backwards-compatible additions. So, by "abandoned", he hints at the headroom for building more table capabilities into the platform.
He compares it loosely to the form element API and the additions it received over the last decades.
In the case of tables, I could think of things such as a sorting, filtering API, but I can't tell whether that's what he means.
Yea, but that's pretty much irrelevant as long as the effect is exactly the same. Which brings us back to the point of the article: seeing this and feeling inspired to imagine interface extensions that go beyond syntax sugar.
I was replying to the wrong comment, because I was responding to this:
> I still use this pretty much everywhere to create HTML tables. Do people use something else now?
Regarding React: what would be the benefit for using this old syntax sugar in its vDOM implementation?
Page reflow is not an issue for vDOM as it batches such updates anyway?
And using syntax sugar without benefits in the DOM reconciliation would be pointless.
React also doesn't locate form input elements using document.forms.[name]?.[name] because... why should they?
Just because they can...
Regarding the creation of tables, the most common way to do it would be... parsing initial document's HTML?!
It was my reason for switching to React when I learned TypeScript after getting more into JS frameworks via Vue.JS.
My starting point was Vue 2.7, and I started out using string templates haha :)
Even wrote some reactive custom code (without Vue, just regular DOM code) in a customer widget that utilized Object.defineProperty et al, inspired by Vue.
And today, while I'm using React at $job, I also think Vue 3 is probably a solid framework as well.
Last time I checked, they improved on DX of their component and templating system. But I'm not even sure whether they still recommend the v-if etc helper tags.
For what it's worth, even Vue 2 always also supported JSX and later TSX
reply