Working on a project right now with htmx, hyperscript, tailwindcss (all new to me) and it's impressive how low the cognitive load is in a lot of cases.

htmx and tailwindcss are great but hyperscript looks crazy evil. I hate mixing html and js though, even jsx rubs me wrong.

This looks like pug/slim and other templating to remove xml from pages but instead of just something like

    body
      p
        |
          This is a test of the text block.

you get something like:

    var h = require('hyperscript')
     h('p', "This is a test of the text block")

and I want to know why would you want the entire page in JS objects?

personally I like the way htmx, vue, alpinejs do things with basically embedding actions/events on the existing xml structures. It's more an abstraction over existing html, than totally redoing or replacing html. That seems like a case of 'we knew we could do it, but never stopped to ask ourselves if we should' ...

Turbolinks + stimulusjs is also another great stack for mini-frontend frameworks. Also super fast.. turbolinks can go well w/ anything though including htmx or alpinejs, but there's a lot of tutorials on stimulus+turbolinks.

Hyperscript (https://github.com/hyperhype/hyperscript) is actually quite nice when you get used to it, and I actually prefer it over JSX. Pair it with something like microh[0], and it gets even better.

[0] https://github.com/fuzetsu/microh

When I first saw hyperscript in the HTMX docs (they're made by the same person), it also struck me as an unholy abomination. But in practice, it's been pretty nifty. It provides a concise way to perform common actions that adheres to the idea of locality of behavior that HTMX and Tailwind both offer as well. I still think I might come to regret it, but it doesn't seem like it would be hard to rip it out and replace it with plain JS. For example, I'm mostly using it to do stuff like:

on click toggle .hidden on .modal

I believe you are talking about this hyperscript: https://hyperscript.org/

Whereas the parent post is talking about: https://github.com/hyperhype/hyperscript

Unfortunately, the creator of https://hyperscript.org/ hijacked the name even when the term "hyperscript" is still used to refer to dominictarr's project and the `h('p', 'hello world') API of declaring templates in JavaScript (as seen in React, Preact, Mithril, etc.).

I'm still learning modern web development but here's a simple demo app that I wrote using only plan vanilla HTML/CSS/JS: https://tgflynn.github.io/AlgoVis/ (github link: https://github.com/tgflynn/AlgoVis).

The fact that this works, didn't take long to write (though I'm very much still learning this stuff) and is very fast leads me to question your statement that "The imperative DOM api just sucks".

Ok, but surely you see the difference between this very simple/straightforward "demo app" and a real webapp? Something like Zillow, Facebook, Doordash, Spotify, etc. I looked at your code and you had to write your own render loop to accomplish this which would break down if you had interactive stuff that you were rendering out (I know, I've done this before). As it stands your interactions ("New Data", "Run", "Step", "Reset") are completely separate from the rendered data. Once you start combining those it gets harder. It's still possible but you are reinventing the wheel.

For a small demo like this vanilla JS might make sense but scaling this up does not work (once your rendered HTML reaches a certain size it's jarring when it re-renders, same deal if you have interactive UI that you are rendering out) and if you need to make 10x of these demo sites you are copy/pasting a bunch of code versus leveraging a framework that handles that stuff for you. Yes, frameworks raise your "floor" of code-size but they provide an excellent foundation to build on and skills you can reuse across projects instead of them all being one-off or having to copy/paste a bunch of code.

> Ok, but surely you see the difference between this very simple/straightforward "demo app" and a real webapp? Something like Zillow, Facebook, Doordash, Spotify, etc.

Yes and no. What are those apps really doing that's fundamentally so much more complicated ? Obviously there's a lot more to their UI's and you'd need to be careful about doing full re-renders. I suspect anything that affects global page layout could become problematic. But I think it should be possible to predetermine the page layout (unless the viewport size changes, then you'd need to re-render everything, but that should be uncommon) and only re-render within div's of preset size.

> I looked at your code and you had to write your own render loop to accomplish this which would break down if you had interactive stuff that you were rendering out

You mean like generating forms/controls ?

I have some other code I'm working on that does that and also doesn't seem particularly hard. For example I'm working on a chrome extension with an options page that updates another page and the local storage as soon as a user changes an option setting.

> Yes and no. What are those apps really doing that's fundamentally so much more complicated ?

They have more views, more data, more data that needs to be kept in sync across multiple views. You cannot rerender (and inject/replace) every time the underlying data changes. It works up to a point but once you cross that rubicon it because very painful. I don't know how better to say this or explain it. I write webapps professionally and for side-projects, maintaining any of them in vanilla js would be a non-starter. I have even tried that for "smaller" webapps that "don't need a build step", it doesn't work. SCSS is vastly superior to CSS, TS is superior to JS, and templates that support things like `v-for="item of items"` or `v-if="condition"` or `@click="doTheThing"` are superior to HTML templates with event handlers, loops spitting out html, and conditional rendering of blocks.

> You mean like generating forms/controls ?

Yes. Those things make this all more complicated. I've built exactly what you have in the past and at a certain point it falls down hard. There is a noticeable lag when you change data and go to re-render. If the user is focused on an input and you re-render they lose focus unless you make sure to reset the focus after the render. If you wanted to do something like "As the user types re-render an element to show what they typed" (think example/preview, or even something like putting the name you are typing into the UI as a header) it gets really gross really fast. So you might start having smaller render areas "I'll just re-render this 1 part" but that also gets complicated very quickly and at the end of the day you are just building a worse framework without the benefit of the community.

I remember trying to do this with jQuery and localstorage, and was amazed it work, but so frustrated the many times it broke or caused issues. Built an entire shopping cart w/ a team in jQuery and localStorage as the store with some handlebar templates. In retrospect it was horrible code. This was in 2015 though, so react/vue were less wide spread and I was much more junior.

Now it's so much better/easier to use Vue, or react or even Svelte or the smaller similar stacks like alpine, htmx, etc that at least make state management easier than it ever was dealing with jQuery. the only thing jQuery had going for it was the ease of using selectors, honestly I think a jquery lite package that just has all the selector stuff would be nice, I sometimes forget all the document.getElementById stuff, but $('#id') is a much (imho) better syntax anyways. There probably already exists something like that - haven't looked but maybe I will later now that my interest is piqued.

I never used jquery since I never got very seriously into web development until recently but document.querySelector() seems to be about a nice a function for querying DOM elements as you could want.

> items"` or `v-if="condition"` or `@click="doTheThing"` are superior to HTML templates

The html syntax as a matter of taste is horrible, but that doesn't need a whole turing complete language to fix

> You cannot rerender (and inject/replace) every time the underlying data changes.

OK, so how do the frameworks do it then ?

They do pathing/differential rendering. They don't all do it the same way but one example is they build the DOM "in memory", render it out, and then when they re-render they compare they old/new html and inject only the diff. They also have built in things to make sure you don't lose focus when you add an attribute to the input (or change it in some way).

There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?

> There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?

You can even avoid a shadow DOM or vDOM entirely and differentially render using the DOM itself:

https://github.com/WebReflection/domdiff

https://github.com/WebReflection/uhtml

The JS framework benchmark shows these two are among the top performers.

> There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?

Mainly because I prefer working with my own code to working with other people's. Another advantage is reducing the amount of new information I have to learn (which with the whole vanilla HTML5 stack is already vast), but maybe I'm hopelessly out of date.

Thanks for the insights though, I wasn't aware they were doing all of that.

> Mainly because I prefer working with my own code to working with other people's. Another advantage is reducing the amount of new information I have to learn (which with the whole vanilla HTML5 stack is already vast), but maybe I'm hopelessly out of date.

The problem here is - if you need to bring in other developers. Finding react/vue devs, or devs w/ htmx, alpinejs, etc - it's going to be super easy to onboard, a custom framework you built yourself - not so much. Maybe it's easy, maybe it isn't but you will have to train new devs who work on your stuff, where otherwise you could save time/money by not having to train on things, plus is your framework well tested using jest or other testing frameworks? There could be lots of bugs that some of the bigger more established frameworks have already worked out, and especially security issues.

Right now my favorite stack is laravel + alpinejs + livewire + filamentphp (admin dashboard) -- i can prottype in a week what used to take 3 months.

> I prefer working with my own code... Every programmer prefers to work with their own code. This is the biggest dilemma, it boils down to a lot of "make/buy" decisions. Rule of thumb after 20+ years of experience : do not reinvent frameworks. The framework you are thinking of already exists, and, even when not perfect, solves a lot of problems you hadn't even thought of.

I disagree vehemently. Every time I reach for a JS framework, my fans spin and I get concerned that my notebook is going to take off to the moon.

Writing my own, or better yet, staying away from JS altogether, has resulted in more stable, maintainable and profitable software.

Then you exist as a very skilled and rare software developer. Or what's more likely is that your lens of software development and software maintenance is quite different to the majority of web developers.

Think about it, are you the one that maintains said code? If so, can you really call that maintainable (as in, reusable, expandable by others while you are on vacation)? If not, you are a very skilled framework maker. Then other people are using your framework and hence, not reinventing the wheel, which is my point.

This is a good start:

https://reactjs.org/docs/faq-internals.html

https://reactjs.org/docs/reconciliation.html

Thanks.

I suspect some of the JS frameworks started with a set of JS functions, etc. to do things dynamically on a page. And it grew. And then someone comes by and says "hey we're building a new app, mind if we use that?". And it was cloned and morphed. And it grew. Maybe that repeated a bit, and then someone created a framework of generic tools.

Then this happened in multiple places. Or hackers didn't like how something worked so they came up with their own spin. I believe React came out of or is strongly influenced by FB, which makes sense - a Single Page App is the design and progressively loading more ads, ahh I mean content.

And here we are building client/server apps with a technology invented for document sharing.

There are 2 frameworks solving the "keep track of state" problem on the server and allowing for dynamic/reactive UI via web sockets instead of XHR: Ruby/Rails 7 and Elixir/Phoenix LiveView. They still use JS but you can limit it to client-side things and maintain state and validations on server.

This is hilarious. Those web apps are single page applications, more application than page. The most of what face book does in the background has nothing to do with what the user can see, for example. A chat might require interactivity, but static designs with push and pull work well enough for many use cases, with sparse scripting. The bespoke tutorials might rather target a geocities homepage, admittedly.

It's funny to see how responses in this thread jump immediately to reactivity or "skills you can reuse across projects" but without making the case: why?

Why what?

Facebook is pretty complicated already, once you factor in: * infinite scroll

* different sorting algorithms (top vs new, do they even still have that?)

* real-time commenting and post updates, with responses, reactions, edits, deletions

* dynamic image uploads, resizes, rotations, captions, etc.

* auth

* multi-device sync

* real-time customizable notifications

* real-time sharing

And then it gets even more complicated when you throw in other features like:

* ad management, posting, analytics, event tracking

* chat

* marketplace

* page management and all the permissions and delegations that involves

There's nothing really "static" about Facebook. And even it was designed as a mix of PHP and clientside JS, probably due to its history... if they started from scratch today, who knows what architecture they'd use, but probably not vanilla JS and HTML...

I think the "why" should be aimed more at vanilla, as in "why would you want to reinvent the wheel when there are so many battle-tested solutions to choose from, each made by a team hundreds of times more resourced than you"

Why go vanilla? Because it's less complex, often smaller over the wire, nearly SEO ready, etc. Of course if you can anticipate needing a lot of interactivity which cannot wait for separate page loads then consider the FE frameworks. Maybe even go hybrid if only one or two pages need app-like components.

Right tool for the job is hard to know before you've done a similar job, so I can relate to wanting to start with the most robust hammer.

The thing is, most web sites are not Facebook. React is usually an overkill; you don't have so many moving parts in a typical web UI.

Well, Facebook was the example provided, and I was just saying that there's a lot of nuance to what (at first) might just look like a static list of posts but really isn't.

I don't think it's a matter of React or not, but how much clientside interactivity & loading you want. If you want more than trivial interactivity -- immediately or in the future -- then a framework makes it a lot easier. Even something like jQuery existed because the DOM was so hard to work with, and thankfully ECMAScript has absorbed some of jQuery's features. React and node are doing something similar, forcing the standardization of ES6 Modules and Web Components, for example. They come up with ideas, implement them, see them adopted, and THEN the standards bodies absorb them.

Nothing stops you from using vanilla JS across your whole project if you want to; many devs just consider it an unnecessary pain that prioritizes purity of ideology over real-world concerns. I disagree that there aren't many moving parts in a typical web UI. Everything today from basic ecommerce to dashboards to maps to search to comments use clientside JS to enhance interactivity and AJAX loading. If you're building something simpler, there's probably no reason to code your own site anymore vs using Wordpress/Shopify/Bootstrap/whatever.

For the more complex cases that full-time devs actually get paid to build, using a framework and dealing with its performance/bundle size considerations is usually easier than using vanilla JS and dealing with its shortcomings, or you end up having to invent a lightweight framework yourself.

That's especially true when you have (or want) a team larger than one person. With a conventions-based framework, any new dev can be pretty quickly onboarded by observing your usage of common patterns in that framework. See a "useState" and "useContext" and they know its intent immediately. If you roll your own system in vanilla JS, without any standard patterns or naming conventions or directory hierarchies, even the most trivial change requires teaching or a deep investigation -- especially once you get into sharing state across more than one component/page.

I mean, this isn't even a hypothetical... the web evolved from basic DHTML-era JS to jQuery to Angular to React and its peers because more and more people saw a need for these frameworks. Nobody forced it on the web community, we just saw how they helped solve problems we had. Many jobs had me rewriting old PHP + JS apps into modern frameworks because, well, it just works better and is easier to maintain afterward.

Facebook itself is an example of that progression. If you remember Facebook when it first launched, it was pretty limited and much slower (in terms of interactivity). (It was also a lot cleaner and not so ad-ridden and toxic, sadly). I think they invented React out of real needs, not "how do we add more overkill to our app".

Sorry... I guess that's just a longwinded way of saying I disagree that there aren't moving parts in a typical web UI anymore, at least in the space of full-time jobs. Small local businesses and whatever, well, they can just use any of the DIY frameworks (Wix, SquareSpace, Square, etc.). But for those of us actually building SaaS or similar products, vanilla just doesn't cut it. Really the only time I can see vanilla JS paying off is simple one-off blogs or lone marketing pages, etc. And most paying dev jobs aren't doing such simple things anymore...

From my experience as a developer, they rewrite frontends in React because it's cool or because their boss said them to do so. Nobody asks if React is really needed in this project and what would be the best solution.

For example, my bank now has an online banking written in React. It's more buggy than the previous version (e.g., the back button does not work; the payment UI is quite chaotic), but they can boast that they use a modern technology. I doubt that a single page application provides any benefit for this task. Their competitor still uses HTML forms and they work perfectly.

This also reminds me of VB6 era. Back then, many programs were distributed with the runtime and/or an installer that was larger than the actual executable. The history repeats now with the bloated web frameworks.

That sucks. I'm sorry you had that experience =/

For the last few projects I worked on, we first built super basic prototypes in different frameworks (React, Next, Vue, Svelte, Drupal, Wordpress, jQuery, Symfony, Angular back in the day, etc.) before choosing one to settle on, trying to balance concerns like DX, hireability, UX, hosting & infra costs, whatever.

If I were instead just forced to use a certain framework without doing due diligence, I'd be pretty annoyed too.

Undoubtedly there are people chasing the "new fancy", but also, by now React is considered pretty old and mature and (probably) kinda lame to anyone really wanting the newest edgy framework.

To your point, though, the SPA routing system (and how it interacts with browser history and URLs) is a pain indeed. React Router, in particular, handles it pretty terribly, IMO (it's much better in a system like Next).

This is still besides the point entirely. Somebody looking to learn web programming is not going to start running a bank.

html is on the representation layer, not a programming language. Modern web apps go much deeper and are using js as as a programming language for web programming that can go much deeper. As an extreme example, Quake Live implements an entire transfer protocol over TCP/IP. In the standard OSI model, there are a few layers between this and that. But there is a reason that purely representative documents still prefer PDF.

> simple demo app

I don't think you can judge if the DOM api sucks if you are using a "simple demo app" as your baseline, though.

All software is built from simple primitives. If the fundamentals are solid scaling up should be just a matter of managing complexity in your own code. I'm aware that performance problems that I don't have direct control over could occur at some point, but would that be the fault of the DOM API itself ?

If the DOM api is not expressive enough, you end up having to wrap it with your own custom abstractions. At that point, is it not better to use a battle-proven abstraction?

Only if they're clearly better than the abstractions I would come up with. Which is rarely the case, especially if most of these frameworks were developed in an ad hoc manner without deep consideration of what the fundamental problems are that need solving, and even more so if they had to incorporate workarounds for browser issues that are no longer very relevant in 2022.

sounds like someone has a bad case of not-invented-here

Sounds like someone had a bad case of framework chasing and hype driven development. I support the original poster as developing your own is always better than reusing, no exceptions.

I've worked on codebases like your's before, where in-house 'we can do it better' reigned. In my experience it never was better, and when the grand wizard holding it all together got hit by a bus, everyone was blocked.

Frameworks are a common understanding that people can plug and play into. And yes, that's a critical part of maintainable code, the ability for a person to quickly get up to speed and fix things.

Do you work alone though? Do all people in your team agree with your technical decisions? If you left the team, would someone be able to maintain and improve your hand-rolled framework?

This from someone who can’t comprehend why government mandated hard hat safety standards might be good. It all fits.

so, yes, you are not wrong. the issue here is the differential of 'managing complexity' with regards to time.

as the functionality of the app progresses beyond a certain complexity (admittedly, this is nebulously defined), increasing changes to complexity require more time to effect.

beyond a certain point of functionality, the need for a a framework to manage these things becomes emergent. at that point, a single coder can resume making more complex changes with the aide of the framework, than she could do without it.

you're not wrong, you just are not considering a big enough scope over which to evaluate what the manual manipulation of software primitives is worth.

in the end, frameworks aide results beyond the ability of a single coder to implement on their own.

I'm always amused at people who spend like a month learning something new and all of a sudden have opinions on the entire state of software development.

They are of course the valid opinions of a neophyte but don't expect anyone to take you seriously.

Being a neophyte at HTML5 web development doesn't make me a neophyte at software development, I've been doing that for well over 20 years.

I'm always amused at people who make assumptions about who they're talking to online.

Well done! Much better than any framework already. A few suggestions!

Look how slow the text renders when you hit reload.

The content of the <code id="code-container"></code> is not going to change. Just put it inline:

   <code id="code-container">
   <li>async function n2sort( data, view )  {</li>
   <li>    const n = data.length;</li>
   <li>    for( let i = 0; i &lt; n; ++i )  {</li>
   <li>        for( let j = 0; j &lt; n; ++j )  {</li>
   <li>            if( data[i] &lt; data[j] )  {</li>
   <li>                swap( data, i, j );</li>
   <li>            }</li><li>        }</li>
   <li>        await view.addRow( data, `Step ${i + 1}` );</li>
   <li>    }</li>
   <li>}</li>
   </code>

(As a joke you could put the actual <script> tag there and style it like script{white-space:pre;display:block} )

The external <link rel="stylesheet" type="text/css" href="style.css"> can also be pasted inline between <style></style> tags.

Same for the script at the end of the page, just put the content between <script></script> tags.

All the way at the top a document type would be useful <!DOCTYPE html>

If you want the steps could be replaced by rendering the entire table and hide each line with css. Pressing step only has to reveal the next line.

I personally consider it a good habit to have the buttons update the location.search part of the url then listen for url changes with window.addEventListener('locationchange', function) and modify the page accordingly. It's not particularly useful for this app but its nice to have an url that represents the state of the application.

https://tgflynn.github.io/AlgoVis/?step=2&array=1-2-3-4-5

I have a suspicion that your entire comment was intended as some kind of joke, but I'll address your points as if you are being serious.

> Much better than any framework already.

I doubt that. If my first attempt at a dynamic web app in like 10 years is better than the current frameworks than the state of web development must be much worse than I realized.

> Look how slow the text renders when you hit reload.

You're right, there is a noticeable rendering glitch that I hadn't noticed before, thanks. Maybe this is already an early indication of the limitations of the approach I used here, or at least one of the trade-offs.

> The content of the <code id="code-container"></code> is not going to change. Just put it inline:

One of my goals with this demo was to display the exact same code in the blurb on the left as was being run on the right. Another goal was to minimize the amount of change needed to the basic algorithm implementation to update the display. I was able to get it down to one extra line, but maybe there's a way to avoid that entirely.

> All the way at the top a document type would be useful <!DOCTYPE html>

It's there, you must have missed it (in chrome "view page source" colors that line with very low contrast).

Your other comments about inlining go against most advice I've seen on best practices (with which I happen to agree). For one thing it's much nicer to edit files that are written in one language than in 2 or 3.

> I personally consider it a good habit to have the buttons update the location.search part of the url

Interesting, I'll have to give that one some thought.

> > Much better than any framework already.

> I doubt that. If my first attempt at a dynamic web app in like 10 years is better than the current frameworks than the state of web development must be much worse than I realized.

The state of webdev is indeed terrible, there is progress being made but its hard to tell where and if it is real progress. There was a fun article the other day onhere that explained why React became popular and how that no longer necessarily applies but the popularity persists because it is well known. I cant objectively tell how true that is. What is the better stuff is like... peoples opinion? Frameworks are there because html/css and js have their shortcomings (what those are is more opinions) but I much prefer working with those over hiding them. An abstraction on top of something bad doesn't make it great.

People can glue code fantastic things really fast nowadays but when it stops working it takes a wizard to fix things. With many components of your thing getting updated it is easier for conflicts to arise.

Perhaps the question is: How much performance and stability can you exchange for fast development? Guessing how much performance you are going to lose is not easy to guess, it might be completely irrelevant for the use case, it might be horrific. Will you be around to fix things in the future? Will others have to work on your code? A reasonably sane standard way of doing something is going to be a huge advantage there.

> Your other comments about inlining go against most advice I've seen on best practices (with which I happen to agree). For one thing it's much nicer to edit files that are written in one language than in 2 or 3.

Nah, its all the same. You are gaining nothing. You could ask : how much editing files are you going to do vs how many times are people going to load the page? A http request takes time, the browser doesn't know it has to load a css file and 2 scripts until it receives and parses the html, a new request is made which takes time again. Depending where the user and the server are located a request may take a long time.

I find it quite silly how we need a gaming pc to parse websites nowadays. The user is also in some remote corner of some remote country on ancient hardware.

You should absolutely have external css and js if the user is likely to browse multiple pages. Inline they would have to load it for every page view.

People may also block external js and css files. Add blockers may get rid of your code section and if your app is many files spread out over many folders it is much more likely to break than a single file that contains everything.

The single file will either load and work or the server is not working.

In an ideal world we could have things inline on the front page and tie it to an url so that it can be cached and used on other pages.

I would never accept poor code organization as a trade-off for performance. If using linked resources becomes a performance issue I would probably use a server side bundler, or write my own.

HTMX is incredible, I adore it. Typically, my stack for a web app is a Golang webserver using Fiber[0], HTMX, SCSS, my own (experimental) templating engine [1] and SQLite. It's a sufficiently hype-free stack, in my opinion, and one that's been fairly well battle tested (bar the templates) and is pretty simple. It's a joy to use!

[0]: https://github.com/gofiber/fiber

[1]: https://github.com/codemicro/go-neon

Goneon looks interesting.

Is it trying to provide compatibility with quick templates etc or aim to reach jinja level features parity ?

The aim is to be just as functionally similar to QuickTemplate, though not compatible.

I like the idea of QuickTemplate a lot but the I find it lacking and annoying to use in various ways. For example, I find its syntax is annoying to write, I don't like having to re-declare the types of my variables whenever I use them and it's error reporting is near useless.

Currently, Neon is just barely at MVP. I'm dogfooding it and adding to it as I find I need things.

Try to release boiler plate template that uses these tech, if possible and convenient.

Good idea! I'll remember that for when Neon is suitable for people other than myself to use, thanks :)

We developed El to be as minimal as possible, while still solving the problem of keeping state and interface in sync:

https://github.com/frameable/el

It's just ~150 lines / 2kb, and leverages existing browser functionality to accomplish most of the hard parts. Has observability, reactive templates, scoped CSS, no need for a build process, etc.

I have been reading into it for some time now, since I do not want to dive into a big framework with a huge learning curve for a side project that I have.

I just feel afraid to run into a problem that has already been solved in a big framework and get stuck.

Interesting - looks pretty similar to Framework7 components

https://framework7.io/docs/router-component

This looks very interesting, I'll give it a go

If you like hyperscript, it's worth checking out mithril.

https://mithril.js.org

What about adamant? I heard that is the next level above mithril.

This sequence of comments is the JS ecosystem in a nutshell.

Hear about something new, then immediately hear about its multiple successors/replacements.

Lol, to prove you're point even harder, your comment is not even the at the end of the list of successors/replacements.

Mithril uses hyperscript as its foundation, it builds upon it as opposed to replacing/succeeding it :)

Check it out, it's the kind of framework you pick and stick with for 20+ years. Zero bullshit compared to its peers.

And in a month or two the new hotness’ll be something else built on top of Mithril, or something “like Mithril but a bit different”.

Good frameworks are good, and I love a good hobby project in some new hotness, but ecosystems, developer tooling, backward compatibility guarantees, large corporate backing, developer conferences, and community are what makes frameworks adoptable are what makes them stick.

Mithril has been around for 7 years. How old does it need to be before it's not "the new hotness"? Just because you haven't heard of something doesn't mean it's new, and it would behoove you to not immediately dismiss things that are new to you as things that are new in general.

Your heuristic that a large ecosystem is what makes a framework good precludes you from ever again touching any new project. It's a short-sighted approach.

At some point, you have to grow up as a developer and try to understand the real world problems that modern declarative web frameworks have solved. I stated that mithril will be my tool of choice for hopefully 20+ years, so your framing this as me getting lost in the new hotness doesn't even hold up. This is about real tools, which are useful today and tomorrow, and which have slow API churn to facilitate longevity. It's just a bonus that mithril is also faster and far more terse than React and friends.

Nah. orichalcum.js is the hot new thing. It's a fork of adamant with support for monads, generics, and native blockchain integration.

For anyone wondering what are these new JS frameworks:

- mithril.js is an actual web framework. I’ve not tried it myself. - the next comment referenced adamant as being better. There is an MMORPG called RuneScape in which weapons and armour can be smithed of various metals, and treats adamant as 1 tier better than mithril. - similarly orichalcum is a couple of tiers above mithril.

Don't give anyone any ideas!

https://unpoly.com/ is a good choice - it's description is true:

"The unobtrusive JavaScript framework for server-side web applications Unpoly enables fast and flexible frontends for server-rendered HTML views. It has no dependencies and plays nice with existing code."

On top of these options, with modern browsers, it's quite easy to make reactive components in plain vanilla ( https://benoitessiambre.com/vanilla.html ). I find this approach very usable for smaller simpler projects where you don't need a full framework.

Vue is right in the sweet spot for me doing solo stuff. Get all the reactive stuff with minimal additional complexity.

I was about to use Vue for a new project but got pulled by the siren call of svelte. The other popular frameworks look ugly as hell by comparison.

How is svelte? Heard someone give a talk about it a few years back, sounded like it was pared down/elegant. I wrote a project in Angular back when I was using it in my day job and shudder now looking back at the code. It's so bloated by default!

It appears as just another framework but once you dig in and start using it the elegance is ridiculous and addicting.

wow thanks for this, I'm fullstack with tons of vue exp but have been 90% backend for the past 6 months or had my head in a hole or something -- this is the first i've heard of petite-vue. Looks pretty cool, maybe somewhat akin to alpinejs, which I have been using more lately also. I'd also put that on the list as it's a nice framework with a bit less footprint than vue/react etc.

I guess the original issue is that HTML/CSS is desgined for creating documents and standard forms not apps.

I'll throw in https://caldom.org/

If you want to stay close to vanilla, I'd recommend lit: https://lit.dev/

I sometimes use an even closer to vanilla option based on just the Lit templating engine: https://benoitessiambre.com/vanilla.html

Or https://github.com/WebReflection/uhtml