There are a lot of things people might mean by claiming that something "is just JavaScript," but one possible meaning is that the source code you write can run in the browser without any build whatsoever. For React, that's true with the exception of JSX, which is a very simple and optional syntax transform. (Of course in practice you'll probably want to do module bundling too, but browsers could technically load your ES modules directly from static file storage.

For Marko, that doesn't seem to be the case, but it also doesn't really make sense given the problems that Marko is trying to solve.

Another thing people might mean by "it's just JavaScript" is a much more subjective notion about how similar the overal syntax, control flow, etc. feels to whatever previous JavaScript experience the person has. This meaning is a lot harder to pin down, and in most cases reasonable people could disagree on what is and isn't "just JavaScript" according to this meaning. That said, I would tend to agree that React's templating uses normal JavaScript control flow and composition primitives more so than Marko.

Speaking of writing javascript instead of JSX, I'm a big fan of the hyperscript approach:

      var ListComponent = () => {
        let count = 0, selected = null
        return {
          view: ({attrs: {items}}) =>
            m("div", [
              m("p", "Clicked: " + count + " times"),
              m("ul", items.map(item =>
                m("li", {
                  onclick: () => { count++; selected = item },
                  style: {cursor: "pointer", color: item === selected ? "blue" : "black"}
                }, item)
              )),
              selected && m("p", "Selected: " + selected)
            ])
        }
      }

> Speaking of writing javascript instead of JSX, I'm a big fan of the hyperscript approach

Speaking of writing JS instead of JSX or your example, I like the vanjs.org approach:

    const Hello = () => div(
      p("Hello"),
      ul(
        li("World"),
        li(a({href: "https://vanjs.org/"}, "VanJS")),
      ),
    )
    van.add(document.body, Hello())

JSX was such a breath of fresh air after having written and maintained apps which used both of these formats for years (and also having written a library which supported both of them for reusing the same templates on the server and in the browser) - it's the commas! I'm glad it's everywhere now.

But that was also back in the days when trailing commas at the end could break things, JavaScript editor support was relatively poor, and tooling wasn't where it is now (knowing your code is once again valid because the autoformatter just kicked in).

Since we're sharing HTML in JS syntaxes. Don't forget JS tagged template literals like https://jsr.io/@mastrojs/mastro/doc/~/html

Mastro looks like what I do for my offline-first, rendered from Service Workers. I just compose html template string literals and stream them back to the front end. The lib I use for HTML is a bit more powerful though. It is a very elegant way to program.

https://github.com/jon49/Soccer

Thanks, this one? https://github.com/jon49/html-template-tag-async Looks very similar indeed! What makes it "more powerful" than Mastro's html template?

This looks like what JSX compiles into. You can do the same (or similar) with React by using `React.createElement` instead of `m` (or just alias it) so you don't need JSX.

Your example template and the others here are almost jsx after it's compiled (handwritten below). This jsx discussion seems more about removing the compile step, which you can do with https://github.com/developit/htm

    import { createElement as m } from "your-jsx-compatible-library";
    
    var ListComponent = () => {
      let count = 0, selected = null;
      return {
        view: ({ attrs: { items }}) =>
          m("div", null,
            m("p", null, "Clicked: " + count + " times"),
            m("ul", null, items.map((item) =>
              m("li", {
                onclick: () => { count++; selected = item; },
                style: { cursor: "pointer", color: item === selected ? "blue" : "black" },
              }, item)
            )),
            selected && m("p", null, "Selected: " + selected)
          )
      };
    };

Yes, I also like relying on just functions.

I have found aberdeenjs a better dx than hyperscript.

https://aberdeenjs.org/

oh didn't know that one. Been building something that shares the same goals although I can see it is different in many ways. Interesting.

fwiw I think this is worse than Marko in terms of syntax and certainly in terms of readability. For all its flaws, HTML / XML / like syntax is such a good declarative way of writing UI imo. React would not be as popular as it is today were it not for JSX. Like the other reply to your comment said: this is effectively identical to what JSX compiles to assuming your jsxPragma is `m`

It almost was JavaScript! ES4 was going to have something very similar to JSX tags. Well, an extension to ES4 called E4X

It is thin syntax sugar.

  <MyComponent prop={value}></MyComponent>

is just

  jsx(MyComponent, { prop: value })

Libraries and apps can use JSX or JS syntax.

I mean, you’re technically correct. But you’re also not understanding the point.

What people mean when they say “React is just JavaScript” is…

1) JSX, more than any other templating system, is just HTML interleaved with JavaScript. It’s HTML, and anything between { and } is evaluated as JavaScript.

2) Inserting a React component’s “HTML tag” in your JSX is _actually_ the same as calling the JavaScript function. The HTML attributes are the function arguments. Yes, inside your function there can be state, and there can be contexts, and there are refs. But you get at all of those things by calling JavaScript functions.

Like,

      <b><MyComponent attr=“yes” /></b>

is literally identical to:

      <b>{MyComponent({ attr: “yes” })}</b>

It’s the tiniest bit of syntactic sugar.

I feel like too many people think “React is Just JavaScript” is some kind of lie people tell to make React sound cool.

It’s not a lie. There’s a _small_ amount of hand waving around the word “just” but the point is, it’s WAY smaller than what you need to explain the ways Svelte or Vue or Angular diverge from plain JavaScript.

It's further than that even. JSX has the semantics of (modulo a couple of optimisations there and there) a bunch of nested function calls returning normal JavaScript objects. That means you can, in your head, very easily convert between the JSX representation of an expression and the equivalent transpiled JavaScript code.

This is unlike a lot of other templating languages where, even if the expression part of the language is pure JavaScript (or PHP or Python or whatever), it's still interleaved with arbitrary text which will get printed out according to its own rules. This makes the whole thing much harder to reason about (leading to the philosophy that you should put as little logic as possible in your templates because it makes them harder to understand, _even when that logic is directly related to the templating process_.

A good example is for-loops. In a lot of templating languages, you start in text-land, then you enter expression-land to write the opening {% for (const X of ...) %} line, then you're back in text-land again. You sprinkle in a couple of expressions, and then at the end you go back to expression-land to close the loop. You're jumping backwards and forwards between the two worlds, but there's no real syntactical or structural support for mixing them.

Meanwhile, in JSX, you start in text-land, then you open up an expression between two curly braces, and in that expression you write the entirety of your loop. If you need to go back to text-land within that loop, you can create a _new_ set of text nodes, but you're not interleaving expressions and text in the same way.

The result of this is that, once you understand how your JSX will get compiled, it's very easy to read it as if it were the JavaScript that it will get compiled to, rather than as a separate templating language. Which in turn makes it very easy to think of it as "just JavaScript", even if it's technically a syntax extension.

I don't think the syntactic sugar works how you describe. JSX components actually desugar to something like:

   <b>{jsx(MyComponent, { attr: "yes" })</b>

(Previously this function was called "React.createElement", but these days they have special functions that only the JSX compiler is allowed to use.) The extra layer of indirection is needed to do things like support hooks being called inside of MyComponent's function body, keep track of `key` props, and so on.

I don't think that's true, you can write uncompiled createElement calls and everything still works fine.

createElement still exists, but the JSX compiler doesn't use it anymore; see https://legacy.reactjs.org/blog/2020/09/22/introducing-the-n...

Regardless of whether you use JSX or createElement, you can't just call MyComponent({ attr: “yes” }) directly, is the main point.

Yeah I don't think you ever could just call MyComponent(props) directly if the component used hooks. If it was hookless (what a concept...) it wouldn't matter.

You certainly can in Preact.

> JSX, more than any other templating system, is just HTML interleaved with JavaScript. It’s HTML, and anything between { and } is evaluated as JavaScript.

That’s not true though and IMO is one of the weaknesses of JSX: it looks like something it is not. Having to use className instead of class is one of the most obvious tells. But in theory if it was just HTML with {}s I should be able to do:

    <{tagName} />

    <span {someStringWithAttributes} />

    <div>{stringContainingHTML}</div>

and many other things you’re actually not able to do. Not to mention that things like onClick aren’t actually HTML attributes and are instead event listeners, etc etc.

Once you grasp that what you’re actually doing is a function call with an object of arguments it makes sense. But it isn’t HTML. It’s a chain of function calls.

We’re all really used to it so we don’t think about it a lot. But I always try to remind myself of that when I look at a new unfamiliar syntax.

(not to mention, your example isn’t correct! <Component/> don’t map to Component(), it maps to previouslyUnknownFunction(Component()), which is another confusing factor)

You can just use “class”, fyi, at least in Preact, and iirc, it works in React, but isn’t officially supported there.

And this is one of the disadvantages of JSX. The snippets you posted are NOT identical.

JSX (react flavor) is lazy. <My component> is not rendered/evaluated until it's needed.

You can't just call a react component. It's not a regular function call.

It’s not JavaScript if you can’t make an html page locally and open it in your browser without things like an http server or need to transpile.

You can use React with just JS, JSX isn't core to React. htm is a library that uses string templates and is just Javascript but works like JSX and can (but doesn't need to be) compiled down like it, and you can use with with React or other tooling.

That's true, sure. My response to that is in React you have JavaScript & JSX and there are clear boundaries. It's not mixed. I don't write

<for ...>

In JSX I write JavaScript that returns JSX:

{data.map(node => <Element {...node} />)}

^ ----- JS ----^ ^ ------ JSX -------^

or

const elements = data.map(node => <Element {...node} />) ... <div>{elements}</div>

Really the most obscure syntax there is the splatting but it makes sense to you when you realize that JSX is just syntactic sugar for JS:

data.map(node => React.createElement(Element, { ...node }))

I’ve never been a fan of JSX. I tried years ago and wasn’t super into it, and then Vue after that and found the syntax a lot easier on the mental model.

There are of course libraries that use JSX and have '<For>' components

Another interesting approach IMHO is https://github.com/gnat/surreal