htm VS lit

Because AI-UI is a JavaScript module, you specify the layout as a series of function calls. However, it also fully supports JSX and htm, so you can use a more familiar markup at the cost of the loss of some type safety. There's more about these choices in the AI-UI guide here.

I know what "MVC" _stands_ for, but I'm asking what _context_ you mean that in. Are you talking about how to define your server-side data models and endpoints? How you're organizing client-side fetching and caching?

Normally "MVC" as a concept doesn't get used in the React ecosystem (the way it did with Backbone.js).

FWIW it's certainly _possible_ to use React as a script tag, but it's extremely rare. It's normally expected that the frontend _is_ actually bundled and compiled, whether it be using a pure-SPA build tool like Vite, or one of the full server-side frameworks like Next or Remix.

Note that the SPA build output is just a set of static HTML/JS/CSS files, which do not require a separate Node server process for hosting - they can be served by any HTTP server.

My own advice would be to use Vite and build as an SPA.

_If_ you absolutely want to use React as _just_ a `` tag with no build step, I'd recommend also using <a href="https://github.com/developit/htm">https://github.com/developit/htm</a> to at least give you JSX-like syntax for writing your components.

The preact team also dislikes transpiling jsx so they've developed an alternative using tagged template literals: https://github.com/developit/htm

So getting this to work without bundler magic is very hard. It's not surprising why NextJS is investing in a bundler. Though one thing that really sticks out is how much complexity we add for just miniscule dev ergonomics. Not using JSX and using something like htm would make all this easier (removing the bundler entirely), it's a lot of overhead to avoid a couple of quotes. React should really have a tagged-template mode. Also all of this is indirection is actually bad for dev ergonomics too! One of the reasons I did this is because I'm absolutely sick of magic caches and sorting through code that's been crushed by a bundler into something I don't recognize and can't easily debug. While we can't get rid of this completely (ts/jsx) this preserves the module import graph completely on the client-side making it easy to find things as you are working and preserving line numbers. This obviously is not useful for a production build and there's a lot of work that would need to go in to support both modes over the same code, but it's depressing no tools really work like this for local development.

You can also do JSX and skip the build step with preact + htm : https://github.com/developit/htm#example

While I was able to achieve this fairly easily, the developer experience of manually stitching strings together wasnt great. Being myself a fan of buildless libraries, such as htm and lit-html, I figured I'd try to take a stab at implementing a DSL for component-like templating in Service Workers myself, called Service Worker Templating Language (SWTL), here's what it looks like:

I would however highly recommend https://github.com/developit/htm

I thought the same thing, but apparently "HTM" is a JSX like javascript string template representation of HTML, and it can be found here: https://github.com/developit/htm

If you're going to do a no-build approach, assume modern JS (so you don't have to transpile the JS syntax). Also, you can use https://github.com/developit/htm as a nearly-identical equivalent to JSX syntax, also without transpiling.

This seems like a case of caring way too much about something that's hardly very different. JSX versus tagged template strings can be incredibly similar to one another.

The examples in this article are using vanilla template strings to author raw html, but that only misses a couple of nicities JSX has. There are tagged template string libraries like htm[1] that do include some of the few nicities JSX has, but which are actually compatible with the official language.

[1] https://github.com/developit/htm

some people cheat by using web components but with Lit Elements. https://lit.dev/

Lit[0] is the underdog winner here. Like the OP, I much prefer functional style and Lit is the only class-based thing in my repos, but it is much easier to deal with the lifecycle than React effects and hooks.

Lit is nearly bare metal HTML (and has been proposed as a permanent addition to standard HTML. It also doesn't need JSX because you just write regular HTML in tagged template literals.

Nearly all the "new, improved" reactive frameworks I see that are "better than React" are just trying to reinvent Lit.

[0] https://lit.dev

wtf are you taking about with “completely abandoned”? https://github.com/lit/lit/pulse/monthly

First I take a look at how other libraries/frameworks implement SSR and found out that they either simply don't implement DOM at all or implement the least of it (like Lit).

As HAX project lead, our platform works exclusively through the building and nesting of 1,000s of Web Components and most (~95%) use ShadowRoots via Lit / LitElement.

Lit

Lit lit.dev Fast, lightweight Web Component library.

My favourite Custom Elements Manifest generator is the one by open-wc. The setup is straightforward: you create a config file and tell it where to find your components. It even has support for Lit out of the box.

And it is built with https://lit.dev a fantastic library !

> since Material Web seemed to quickly end up in maintenance mode

This is really unfortunate to say the least - the engineering team has done a fantastic job there, but apparently no backing from Google despite the nice promise at the the launch of Material Web.

If you're looking for a library to build components and apps with that does let you use plain JavaScript - to the degree that you can write working components in your devtools console - check out Lit: https://lit.dev/

Lit's used by pretty major apps like Photoshop, Reddit, Home Assistant, and The Internet Archive.