Skill.md here: https://github.com/dunctk/rasx-app-framework

I'm not sure why so many people seemingly fall into the trap of trying to find one tool and then use that absolutely everywhere. I mean, I'm familiar with it as in "it's fun" as I used Nix as a framework for a static website builder, but I keep seeing people making those sort of choices professionally too. Like when React first became popular, then suddenly people try to jam it into absolutely everything, until they slowly walk back and then after some years agree that maybe it's good for some things, not for everything and not as a default.

> Different tools for different jobs. (Me? I honestly love React, just a more minimal stack. Zustand and TanStack and Vite. No Redux or Next.JS)

My concern with is that i build line of business applications for a living, and literally, every project i work on ends up growing in scope such that even the simplest ones, reach a point where the customer asks for items that are just much simpler to do with a front-end framework. And these are often cross cutting concerns, such that it is not as easy as simply adding some js to one page.

Example: "i want to be able to reorder all the columns of all the tables of the website, and hide some columns, with my preferences remembered for each table". Customers pull that kind of thing off their hat every time, such that even "basic websites" can move out of the trivial territory any time. And this is just the most trivial example i can think of.

I want the tech stacks i use to be future proof, as in not having to rewrite everything when requirements become more complex (as it is also typically a time where we aren't given much time budget, as they need it for yesterday).

For something for which i fully control the roadmap, i may consider htmx (but even then, even my own products grow in ambition rapidly) however for customer projects i find this choice way too risky.

I need to be able to capitalize on the tech infrastructure i've built as requirements get complex, both due to customer time constraints and because this is where we get some of the highest profit margin from our work. Having to rework most of what i've done every time a complex requirement comes up, would be inefficient with this regard.

To me it's a case of knowing your tools in depth, to make meet most requirements (including from a performance perspective). Maybe erlang or go would have been more suited for a project from a philosophical perspective but since i specialize in .NET + angular, unless there is hard blocker, i'll use this tech stack, and everything is fine from the perspective of the customer. But i gain that the project is future proof and i won't need to reengineer it when it moves of its initial sweetpot.

I mean sure, things like Next, Gatsby, etc can theoretically create the best of both worlds - static site for search engines and no-js users, content first, and very fast client-side rendered content afterwards. But that's a lot of extra engineering, considering a good server-side rendered website is also fetched and rendered within milliseconds.

"let us rething how extensions can and should work,"

I think you meant rethink here.

Disagree. The RoR front end was way more stable and usable than the mess they have made now.

If you have 1/5th the context to consume, that's going to generate better code than the comparable typescript, even if the language is an esoteric one.

They love htmx! Claude will independently suggest using it instead of more general js frameworks for smaller projects. A gpt model told me, and I wrote this down because it was striking, "htmx won the argument it was making."

It's the same thing with rust. I'm an ocaml expert and ocaml genuinely fits a lot of the problems I work with better regardless of that. But because of when the models were trained and what they were trained on, a certain sort of alt-consensus opinion is frozen into them, and it believes rust is a better choice for nearly everything!

I think you're good for the next few years at least. It's an open question what happens after that dead internet theory recursive loop of llms trained on llm output etc so who knows you might be good forever.

I think that, combined with Htmx it can be a really powerful thing for lots of deployments (basically most things that do not need API/Json talking).

I let the llm write components which are independent to each other. This works great and keeps everything clean. The times that llm would only generate unmaintainable code are long gone with OPUS, Fable and sol 5.6

That doesn't mean do dumb / complicated / bloated stuff for no reason. If the best thing for your users is static html, use that.

Typo of "a"?