htm VS jsx

Compare htm vs jsx and see what are their differences.


Hyperscript Tagged Markup: JSX alternative using standard tagged templates, with compiler support. (by developit)


The JSX specification is a XML-like syntax extension to ECMAScript. (by facebook)
InfluxDB - Power Real-Time Data Analytics at Scale
Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
htm jsx
44 16
8,623 1,952
- 0.3%
0.0 0.0
6 months ago 8 months ago
JavaScript HTML
Apache License 2.0 -
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of htm. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-06-05.
  • I've been writing web backends and frontends since the 90s. Finally: declarative, dynamic markup done right
    2 projects | | 5 Jun 2024
    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.
  • Ask HN: How do you use React as a library in 2024?
    1 project | | 10 May 2024
    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=""></a> to at least give you JSX-like syntax for writing your components.

  • VanJS: A 0.9KB JavaScript UI framework
    15 projects | | 20 Dec 2023
    The preact team also dislikes transpiling jsx so they've developed an alternative using tagged template literals:
  • React SSR web-server from scratch
    2 projects | | 21 Nov 2023
    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.
  • HTML Web Components
    14 projects | | 13 Nov 2023
    You can also do JSX and skip the build step with preact + htm :
  • Service Worker Templating Language (SWTL)
    4 projects | | 19 Aug 2023
    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:
  • Gaseous - Yet Another Games Manager
    3 projects | /r/selfhosted | 10 Jul 2023
    I would however highly recommend
  • Create and Hydrate HTML with HTM
    2 projects | | 25 Jun 2023
    I thought the same thing, but apparently "HTM" is a JSX like javascript string template representation of HTML, and it can be found here:
  • Anyone using React from just a CDN, barbarian style?
    1 project | /r/reactjs | 28 Feb 2023
    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 as a nearly-identical equivalent to JSX syntax, also without transpiling.
  • Simple Modern JavaScript Using JavaScript Modules and Import Maps
    9 projects | | 16 Feb 2023
    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.



Posts with mentions or reviews of jsx. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-06-28.
  • Understanding React Compiler
    11 projects | | 28 Jun 2024
    > Where is jsx defined, as a language? is the primary home.

    > are there multiple transpiler implementations?

    Yes. Off the top of my head:




    > is it standardized at all?

    In terms of well documented, yes. In terms of a TC-39 standard accepted as a part of JS and intended for browsers to consume? No. Unless you count how much it borrows from E4X [0] which was an optional part of the "lost version" of JS that was EcmaScript 4, then "sort of".


  • I am having to pass down 8+ props even for simple components. What are some common ways to mitigate this? (Typescript)
    2 projects | /r/reactjs | 12 May 2023
    Svelte syntax? Yes, there is upcoming initiative JSX 2.0 which includes shorthands like that. However, have no idea whether it will be released any time soon. So let's say "this is part of React/JSX 1.0" (shrugging)
  • Why TypeScript is the better JavaScript
    2 projects | | 7 May 2023
    Inherent support for JSX in the language itself
  • Node.js やReact、ESM、Viteの説明
    7 projects | | 21 Jan 2023
    JavaScript + HTML(DOM)= JSX
  • Alpine.js
    17 projects | | 13 Jan 2023
    FWIW, the className prop is a React thing not a JSX thing. Other libraries which use JSX will happily accept a plain class prop. The React limitation is abstraction leakage: props are not attributes, they map to DOM properties.

    But to the point that JSX is a DSL, that limitation is specifically because React itself is very tightly coupled to DOM semantics… but JSX explicitly has no built in semantics[1].

    1: First sentence of - “JSX is an XML-like syntax extension to ECMAScript without any defined semantics.”

  • React - Introducing JSX
    2 projects | | 6 Sep 2022
    JSX stands for 'JavaScript XML' and is a syntax extension for JavaScript. It is used to create DOM elements that are then rendered in the React DOM. Although it looks like HTML, it is actually an XML-like syntax specifically written for use in React. Interestingly, JSX is not valid JavaScript either. JSX needs to be compiled by a tool like Babel to be translated into regular JavaScript that a browser can understand. Put simply, JSX describes what the UI should look like, and React takes care of properly rendering it.
  • Web lagnunages to learn
    3 projects | /r/learnprogramming | 29 Jul 2022
  • My thoughts on Mithril.js
    7 projects | | 3 May 2022
    Alternatively, you can use JSX syntax (like with React), but then you need build-tools.
  • Incrementally adopting TypeScript in a create-react-app project
    6 projects | | 11 Jan 2022
    Note: For React component files (JSX) we'll use .tsx to maintain JSX support and for non React files we'll use the .ts file extension. However, if you want you could still use .ts file extension for React components without any problem.
  • Sciter, the 5 MB Electron alternative, has switched to JavaScript
    16 projects | | 30 Dec 2021
    I’m concerned that you’re falling into the same trap here with integrating your own variant of JSX, and mulling over adding more things like hyphens in unquoted object literal keys.

    JSX is popular enough that it’s safe, ECMAScript isn’t going to break it, but your alterations to JSX are already significantly incompatible: you have being equivalent to JSX("input", {"class": "search"}, null), but the JSX everyone else is using has that equivalent to JSX(, {}, null). I’m not certain if your JSX syntax is supposed to be able to be used with React code or anything else that uses JSX syntax, but if yes then it’ll be broken in a significant number of cases so that it’s worse than useless, and if no, well, it’s going to be misleading, and what if JSX did get merged into ECMAScript in some form? Then you’d be incompatible with ECMAScript again.

    Same deal with hyphens in unquoted object literal keys: it’s not part of ECMAScript now, but just because it’d be a syntax error now doesn’t mean it always will be. Decorators in TypeScript are a good example of things going badly wrong even when an extremely popular project is involved.

    I say: if you want to go JavaScript, go JavaScript, maaaaaybe plus standard JSX conforming with <>, and no further. Even if what you do is obviously superior, &c. &c. I’d apply the same reasoning on your fork of CSS: you introduced it for a good reason back then, but now it’s just friction, even if it’s a little better in a vacuum (and maybe it is in parts, maybe it isn’t in other parts).

What are some alternatives?

When comparing htm and jsx you can also consider the following projects:

Preact - ⚛️ Fast 3kB React alternative with the same modern API. Components & Virtual DOM.

joystick - A full-stack JavaScript framework for building stable, easy-to-maintain apps and websites.

esbuild-plugin-alias - esbuild plugin for path aliases

denoflare - Develop, test, and deploy Cloudflare Workers with Deno.

babel-plugin-react-html-attrs - Babel plugin which transforms HTML and SVG attributes on JSX host elements into React-compatible attributes

React - The library for web and native user interfaces.

vim-jsx-pretty - :flashlight: [Vim script] JSX and TSX syntax pretty highlighting for vim.

prepack - A JavaScript bundle optimizer.

lit - Lit is a simple library for building fast, lightweight web components.

vite - Next generation frontend tooling. It's fast!

babel-plugin-proposal-pattern-matching - the minimal grammar, high performance JavaScript pattern matching implementation

ember-render-modifiers - Implements did-insert / did-update / will-destroy modifiers for emberjs/rfcs#415

InfluxDB - Power Real-Time Data Analytics at Scale
Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives