6 ms·

It looks interesting and in a past life I probably would have tried it out but do you know why I like React? Because it's just JavaScript. This `<let/variable=

• afavour 11mo ago
  I mostly agree with you but React isn’t just JavaScript. JSX is not JavaScript. It’s just that we’re so used to it we don’t consider it notable any more. Worth keeping in mind when you’re looking at a brand new framework.
  • tills13 11mo ago
    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 }))
    • c-hendricks 11mo ago
      There are of course libraries that use JSX and have '<For>' components
    • phatskat 11mo ago
      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.
  • tshaddox 11mo ago
    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.
  • erikpukinskis 11mo ago
    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.
    • MrJohz 11mo ago
      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.
  • zero_shift 11mo ago
    It almost was JavaScript! ES4 was going to have something very similar to JSX tags. Well, an extension to ES4 called E4X
  • paulddraper 11mo ago
    It is thin syntax sugar. <MyComponent prop={value}></MyComponent> is just jsx(MyComponent, { prop: value }) Libraries and apps can use JSX or JS syntax.
  • fouc 11mo ago
    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) ]) } }
    • Rohansi 11mo ago
      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.
    • tills13 11mo ago
      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`
    • dualogy 11mo ago
      > 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())
      • insin 11mo ago
        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).
  • Latty 11mo ago
    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.
  • ethanpil 11mo ago
    Another interesting approach IMHO is https://github.com/gnat/surreal https://github.com/gnat/surreal
• someguyiguess 11mo ago
  React has not been just JavaScript for a long time. The react DSL just keeps getting more and more bloated as they add more hooks for more and more edge cases (useFormStatus, useActionState, etc…). It’s becoming just another bloated mess now. And I used to love react! This looks promising though. The syntax looks very straightforward. Even though it’s not “just JavaScript” it is very easily understood by most programmers. I’ve glanced at it for all of 2 minutes and it all makes perfect sense. Functions look like functions. Variables look like variables. I think it looks cool!
• moritzwarhier 11mo ago
  Really, this point can't be stated often enough. It was my reason for switching to React when I learned TypeScript after getting more into JS frameworks via Vue.JS. My starting point was Vue 2.7, and I started out using string templates haha :) Even wrote some reactive custom code (without Vue, just regular DOM code) in a customer widget that utilized Object.defineProperty et al, inspired by Vue. And today, while I'm using React at $job, I also think Vue 3 is probably a solid framework as well. Last time I checked, they improved on DX of their component and templating system. But I'm not even sure whether they still recommend the v-if etc helper tags. For what it's worth, even Vue 2 always also supported JSX and later TSX
  • deleted 11mo ago
    [deleted]
• etothet 11mo ago
  To each their own. This syntax actially resonates with some people, which is why template-based frameworks like Vue and Svelte are also popular. In fact, at first glance this reminds me a lot Vue in some of its approach and syntax. BTW - with Vue you can use entirely JSX of you dislike HTML component syntax (I don’t know enough about Svelte to know if it allows the same).
  • prokopton 11mo ago
    Svelte does not allow that.
• zero_shift 11mo ago
  In a past life we did try it... Marko has been around for years. It started as a project at eBay and then got spun out to an open project around 2015
• iammrpayments 11mo ago
  Do you really believe React is just javascript?
  • pwdisswordfishy 11mo ago
    React is "just JavaScript" that you have to write in a very particular way, which the language in no way helps you enforce, for otherwise your "web app" will misbehave is bizarre and confusing ways.
    • brazukadev 11mo ago
      There are no particular ways to code react where JSX is just JavaScript, it is not.
      • Etheryte 11mo ago
        React is not the same thing as JSX. You can use React without using JSX and you can also use JSX without using React. This argument makes no sense from the get go.
        • brazukadev 11mo ago
          It does not change the fact that JSX is not valid JavaScript and so 99.9% of React code is not valid JS.
• DonnyV 11mo ago
  No Vue, is just JavaScript. React is JSX.
• notpushkin 11mo ago
  Agreed on the syntax part. We’ve had good syntax for templates before: <ul> {% for user in users %} <li>{{ user.firstName }}</li> {% endfor %} </ul> And we have good syntax for templates now: <ul> {#each users as user} <li>{user.firstName}</li> {/each} </ul> Why do we have to squish everything into HTML-like-but-not-quite blocks? But no, JSX isn’t that great either: <ul> {users.map(user => ( <li>{user.firstName}</li> ))} </ul>
  • cubefox 11mo ago
    Why not use html/XML style syntax rather than mixing two syntax styles? For example, "{/each}" already looks like "</each>".
    • benrutter 11mo ago
      I guess the argument against would be that <element> designates an HTML "thing", i.e. some content for rendering. </each> is about control flow, so it's a conceptually different thing. I can't tell how convincing that argument is to be honest, and how much I'm just rationalising familiarity.
      • cubefox 11mo ago
        I think there isn't too large a gap between "wrap this stuff in a box and add a line break afterwards" and "repeat this stuff for each item".
        • naasking 11mo ago
          Generally for templating, you want a visual distinction between the control language and the target/rendered language, because they are two different things. Where they aren't two different things, you have some kind of component configuration language, like WPF on .NET. There is no control language, the instantiated components have behaviours and are responsible for any control logic, like rendering a list of items. This isn't a template language though. HTML now has web components and so you can think of it in the latter way. I'm not sure if anyone has take this approach though.