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.
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).
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.
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`
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.
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.
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.
> 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:
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)
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.
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.
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).
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!
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
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.
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.
I remain convinced that RSC and the SSR craze was a result of someone (or multiple) people needing a raise and their friends wanting to start a company selling abstract compute. Statically hydrated, minimal React was pretty great when served over good CDN infrastructure. Then I watched the bundle sizes and lock-in balloon. That second article is a dragon slayer. It really lays out the problem with React. In marrying itself to Next.js and embracing the server, it's betrayed the platform. Meanwhile, the platform itself has matured. React practically built my career, and I just don't have a reason to choose it anymore.
That’s interesting. I’ve always held SvelteKit in high regard for greenfield projects because it balances capability, developer experience, and performance, but I’ll have to give Marko a look. I’d love to see a similar deep dive into Electron style desktop frameworks since that space still feels underexplored compared to mobile. I honestly wouldn’t know where to start for a video game interface, and that bothers me.
This is actually quite cool - JS inside HTML, rather than the more React-y HTML inside JS.
As I understand it, Ryan Carniato was a major part of this project, and later went on to lead SolidJS, which goes back to the React style HTML in JS. Has he spoken at all about why he went back to that templating style?
Ryan was working on Solid before he joined eBay/Marko. Both projects have benefited from the shared knowledge and approaching a similar solution space from different angles.
He eventually got the opportunity to work on Solid in a more full-time capacity and decided to take it, but still talks with the Marko team from time to time
After two decades of this churn we are back to the equivalent of JSP. It was the correct paradigm all along but millennials wouldn't be caught dead working with such a "lame" technology so they bestowed SPA on us and now they are slowly walking it back.
We also had JSF, which was even cooler - being able to reconstruct the state server-side. It was ridiculously fast to write complex form-driver websites with that! No DTOs/schemas in different languages, no worry about how the client calls the server, what happens if it fails, etc.
The only problem is that it won't necessarily scale to some insane numbers without some care.
(Not sure why the past tense, it does work and developed still)
I’m not completely sure of that. The simplicity of a backbone app, plain javascript with no build, less/sass, early days node.js or old RoR apps is becoming increasingly elusive. Not a lot of modern apps you couldn’t build with those stacks, and most of the underlying technology is the same (http/html/css/js/sql/libuv/etc).
Saying this feels like advocating for a return to horse carriages though, when the right analogy would be the brief electric car era of the early 1900s, and React as the Model T.
I’d venture to say that the idea of a “correct paradigm” is based on a false premise. Why would there be one paradigm to rule them all? Maybe there is more nuance. Maybe certain paradigms are better for certain applications.
I don't normally comment on formatting, but for a language I assume they're dog-fooding for the demo it's amusing that none of the gradient-backgrounded text renders visibly ("HTML-based", "building web apps", etc).
The problem when taking several languages and mixing them together this way is that the result is supposed to have brevity, but it’s actually unreadable. You need slash to mean something grammatical, colon has to say something, you can speak “open brace” in a way that anticipates; @ means “at”. This code looks more like a compression scheme.
The challenge was to make it seamless enough that so it doesn't look like that we tried to mash languages up, but to make them form a different language that is consistent and simple at the same time.
Your Mint language looks awesome! You’ve done a great job making it very seamless between the 3 languages. I had a couple thoughts regarding your css/styling though:
1. The one feature I prefer in Marko when compared to Mint is Marko’s nice ID and class syntax, rather than your custom selectors, so you can just use regular CSS (which seems to be advancing faster than the JS & HTML specs combined). You could get the scoping using shadow roots for your components (I’m sure this has flow on consequences, but given you own the language it’s probably better case than many others.)
2. Interpolating values directly in CSS blocks is something that a lot of HTML templating systems sort of give up on (see Astro going out of it’s way to make interpolating variables super verbose [0]), so I’m glad to see you do it. Does the value interpolation compile to CSS variables that are set on the component root (or somewhere else I suppose) as in Astro [0], or is it just simple interpolation? Additionally, I can’t help but notice your hash symbol would conflict with ID selectors, so is CSS nesting available?
Please don’t take this as criticism! I really like what you’ve done here and am very curious.
1. Inside style blocks it's pretty much regular CSS except for interpolation and if/case expressions, so you can create a style for the root element and then use ids and classes if you desire, but it won't be optimized.
2. CSS definitions without interpolation compile down to static CSS while the ones with interpolation compile down to CSS variables which are set on the element where the style is assigned. This also allows for passig arguments to styles [0].
CSS nesting is supported and the interpolation doesn't conflict with the id selectors because interpolation is not supported in selectors.
It's there a way to define routes in a nested, hierarchial fashion, preferably across multiple modules?
For example, with react-router, my root route object array I define by spreading out other route object arrays that I've imported from other modules in my project. And each of those do the same thing, recurring as necessary until I get to the full depth of my route tree.
Isn't syntax pretty much just compression? We could write down the AST itself in some generic notation but that would be orders of magnitudes larger, so invent clever tricks to compress it, which we call syntax.
Maybe just me but I actually think building web apps is already fun. I’ve got a hot reloading instant dev environment, I can publish to users in an instant… it’s great!
Looking at the Marko examples I feel the same way I do whenever similar stuff gets showcased: it’s trying to focus too hard on brevity and/or cutesiness and doesn’t seem like it would scale well to a full, complex web app. But maybe it’s not supposed to and maybe that’s fine.
React and Svelte and the rest can read clunkily at times but they have a clear separation of concerns and I’m glad for that.
Pretty much every JS framework has SSR, the question is really how quickly does it hydrate. React typically rates poorly there but Svelte does great, at least partially because it has a compiler to optimize (like Marko does, it appears).
Marko’s compiler is designed for partial hydration (by default, without any special developer effort), which performs quite well. IIRC they were also looking at implementing “resumability” (term coined by Qwik, for an approach that sidesteps hydration as a concept entirely). I’m not sure where they’re at on that now, but I think it’s generally safe to say that Marko prioritizes load time performance more than nearly all other frameworks.
I didn't look deep into Marko yet, but in my opinion JSX is by far the best HTML template language there is. And it's not restricted to React.
Most other template languages hits serious limitations really fast. I tried and hated (for non trivial things): Angular, Handlebars, Razor (dotnet) and Vue (which does support JSX optionally).
I've been liking the model of the Python library Dominate [1]. You write your HTML as regular Python code, and you render() once at the end, having full control over the formatting. Well, at least in theory; in practice the formatting is brittle and the library otherwise makes some choices I don't like.
I wrote a Rust library with a more restricted/verbose API, and I've been enjoying using that. Unfortunately, I find it really hard to make it as fast as I want. It's really the perfect use case for arena allocation, but doing that and keeping the API as function calls mirroring HTML is not trivial, and probably requires macros to rewrite the tree as a series of stack pushes.
I written lots of Vue/angular/react (like more than 3 major projects with each) and I'm a firm believer that:
1. Jsx is nicer to write but that's a non issue
2. vue's and angular's directives and bindings lend themselves to much saner and lighter rendering (performance does matter)
3. Vue is much easier to tame, it's reactivity model does not require a PhD in hooks or a deep understanding of React's internals. It just works out of the box as it should and is much easier to control the rendering lifecycle.
At the end of the day, after many years, my preference goes with Vue and Nuxt especially which is tremendously better than the monsters of Next or RR. That's what pays the bill the easiest and is eventually easier to maintain and optimize.
It's misleading to call this "A declarative, HTML‑based language" when it in fact relies heavily on writing explicit JavaScript (which is very different from HTML and not declarative at all).
Something like htmx does come a lot closer to being a HTML‑based language in my opinion. So much so that you could add it to the actual HTML spec.
(That's not to say that Marko is bad, just that it's more a way to mix HTML and JavaScript in a more intuitive way rather than a declarative, HTML‑based language.)
Someone posted here, thanks for that!! It immediately reminded me of HAML: https://harcstack.org/
I like HAML a lot, it was the most pleasant to develop with. And it shares a lot in common with Stylus. They both shared things in common.
NO NEED FOR: Curly braces, parentheses and semicolons. The cool thing, it was all optional and I wasn't forced to make use of all shortcuts!
I developed my own CSS Framework in 2003, shared with some UX guy at Yahoo, who incorporated it into YUI mostly as is, after I waived all rights. Most of that became internet standard. Later I had my own PHP based CSS scaffolding framework in 2005 that could also generate grids (before flex-box). SCASS/LESS was really similar to my framework, when it came out.
But I disliked it, it just looked like PHP mixed with CSS. I thought why accept the ugly syntax, despite a compiler being available?
File-based routing is fundamentally flawed and it cannot be fixed. A number of libraries opt for it since it's easier for newcomers to pick up, but eventually you run into all of the cases where you do need something else. This in turn leads you to a hybrid system of multiple things where there's no single source of truth and everything is spaghetti.
Role based access control is one of the simplest examples, your routes need to be conditional and all come with related metadata for permissions and such. With file-based routing you'll then end up with your routes defined in one place and the configuration for them either in a separate different place or split up across the codebase. Whenever you need to change something you need to remember to do it everywhere else. If your routing is in code, you can define everything in one place with strict type checks, tests, and so on.
Let’s not pretend that useState() is plain TypeScript either. It’s a DSL in disguise.
JSX is amazing for stateless rendering of templates. Not so much for state management. That should really have been given a dedicated DSL. Here I think Marko did the right thing, why they then made even for-loops a dsl is more questionable.
<p>Today is ${new Date().toDateString()}</p>
<p>Random number: ${Math.floor(Math.random() * 100)}</p>
Sorry, I don't like it. I already disliked that immensely in PHP. Not going back to that spaghetti mesh-up.
The intro is also incorrect in my opinion. It writes a "HTML-based language", but this is more a hybrid of HTML and JavaScript. Why is JavaScript not mentioned in the intro?
Personally, I'd either just put the content in an ID-ed span and have a script to replace the content. Another, perhaps better, way is to use Alpine.JS which excels at this kind of stuff.
> I'd either just put the content in an ID-ed span and have a script to replace the content
And so your script is broken when someone else in your team (or maybe even yourself) renames or removes the ID and forgets to search in the whole project if some piece of code depends on this ID. JSX fixed all that mess 10+ years ago.
But that separation is sometimes the point. A designer tweaking the looks has no chance to break the computation logic, and an engineer tweaking the computation part won't disrupt the design by mistake.
Terseness is good for code golf [1]. I disliked CoffeeScript after writing it for some time: nearly any typo can result in another syntactically correct program which, of course, does not what you wanted the original program to do, or fails the compilation in an unrelated place. A practical language has safety margins, aka some redundancy.
I'll concede that Alpine.js is harder to understand and more verbose than Marko's syntax, but in order to use Marko you have to commit to the Marko framework. If you're willing to choose a framework solely for its JS-in-HTML capabilities, there are much better choices (like SvelteKit that handles JS-in-HTML wonderfully).
Don't blame Marko for this type of abomination. This is basically fancy react JSX.
ITS just bizzare people want to parse JavaScript at the same instance they're parsing html.
Also, LLMs are going to destroy any new framework. Someone's gonna need to figure out how to integrate these things into new tools. LLMs suck but it'll be much worse if they freeze innovations cause they're too expensive to chase the new hotness.
Honestly I don't know... I'm somewhat skeptical about these "next big thing that will fix all your pains in web development". There is so much fragmentation in JS libraries / frameworks. Angular, React, Vue, Svelte, Asto, SolidJS, NextJS, Nuxt, Qwik... The list is so overwhelming. Almost each one claims that it fixes a problem in other framework, and a year later the other framework fixes that issue... I think it's better to stick to a big old player, such as Angular.
Marko has been around for over a decade at this point and powers most of eBay. It's not the oldest or the largest, but it's got a pretty solid track record
Honestly I don't know... I'm somewhat skeptical about these "next big thing that will fix all your pains in web development". There is so much fragmentation in JS libraries / frameworks. Angular, React, Vue, Angular, Asto, SolidJS, NextJS, Nuxt, Qwik... The list is so overwhelming. Almost each one claims that it fixes a problem in other framework, a year later the other framework fixes an issue... I think it's better to stick to a big old player, such as Svelte.
One of its core dependencies is morphdom, which has been used successfully by a slew of frontend view libraries like Marko, including Phoenix LiveView.
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=...>` and `<for ...>` syntax is awful.
Agreed on the syntax part. We’ve had good syntax for templates before:
And we have good syntax for templates now: Why do we have to squish everything into HTML-like-but-not-quite blocks?But no, JSX isn’t that great either:
Why not use html/XML style syntax rather than mixing two syntax styles? For example, "{/each}" already looks like "</each>".
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.
Speaking of writing javascript instead of JSX, I'm a big fan of the hyperscript approach:
> 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:
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).
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.
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.
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
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,
is literally identical to: 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.
I don't think the syntactic sugar works how you describe. JSX components actually desugar to something like:
(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.
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.
> 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:
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)
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.
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.
It is thin syntax sugar.
is just Libraries and apps can use JSX or JS syntax.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
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
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).
Svelte does not allow that.
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!
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
Do you really believe React is just javascript?
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.
There are no particular ways to code react where JSX is just JavaScript, it is not.
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.
No Vue, is just JavaScript. React is JSX.
As someone who has actually worked on JavaScript frameworks, I think Marko is criminally underrated. The compile-time optimizations are extremely impressive: https://markojs.com/docs/explanation/fine-grained-bundling
I was not surprised for example that Marko came out very well in this performance comparison: https://www.lorenstew.art/blog/10-kanban-boards
I remain convinced that RSC and the SSR craze was a result of someone (or multiple) people needing a raise and their friends wanting to start a company selling abstract compute. Statically hydrated, minimal React was pretty great when served over good CDN infrastructure. Then I watched the bundle sizes and lock-in balloon. That second article is a dragon slayer. It really lays out the problem with React. In marrying itself to Next.js and embracing the server, it's betrayed the platform. Meanwhile, the platform itself has matured. React practically built my career, and I just don't have a reason to choose it anymore.
That’s interesting. I’ve always held SvelteKit in high regard for greenfield projects because it balances capability, developer experience, and performance, but I’ll have to give Marko a look. I’d love to see a similar deep dive into Electron style desktop frameworks since that space still feels underexplored compared to mobile. I honestly wouldn’t know where to start for a video game interface, and that bothers me.
This is actually quite cool - JS inside HTML, rather than the more React-y HTML inside JS.
As I understand it, Ryan Carniato was a major part of this project, and later went on to lead SolidJS, which goes back to the React style HTML in JS. Has he spoken at all about why he went back to that templating style?
Ryan was working on Solid before he joined eBay/Marko. Both projects have benefited from the shared knowledge and approaching a similar solution space from different angles.
He eventually got the opportunity to work on Solid in a more full-time capacity and decided to take it, but still talks with the Marko team from time to time
Yes. Mostly because:
• JSX is well understood by a lot of developers • support is already built in to text editors • it is understood by typescript
JS inside HTML! Groundbreaking! It's nothing like Netscape ever conceived in 1995...
After two decades of this churn we are back to the equivalent of JSP. It was the correct paradigm all along but millennials wouldn't be caught dead working with such a "lame" technology so they bestowed SPA on us and now they are slowly walking it back.
We also had JSF, which was even cooler - being able to reconstruct the state server-side. It was ridiculously fast to write complex form-driver websites with that! No DTOs/schemas in different languages, no worry about how the client calls the server, what happens if it fails, etc.
The only problem is that it won't necessarily scale to some insane numbers without some care.
(Not sure why the past tense, it does work and developed still)
Yes, we go in circles, but there are subtle (and sometimes not so subtle) improvements every iteration. Of course sometimes there are also dead ends.
It is exciting to see what the ingenuity of the next group brings, even though some existing things are lost, but hopefully not forgotten.
This.
Also it cannot be understated: apis, language and tooling are miles ahead better they were a decade ago or more.
I’m not completely sure of that. The simplicity of a backbone app, plain javascript with no build, less/sass, early days node.js or old RoR apps is becoming increasingly elusive. Not a lot of modern apps you couldn’t build with those stacks, and most of the underlying technology is the same (http/html/css/js/sql/libuv/etc).
Saying this feels like advocating for a return to horse carriages though, when the right analogy would be the brief electric car era of the early 1900s, and React as the Model T.
I’d venture to say that the idea of a “correct paradigm” is based on a false premise. Why would there be one paradigm to rule them all? Maybe there is more nuance. Maybe certain paradigms are better for certain applications.
I'd go a bit further and say certain paradigms may be better for certain people.
> It was the correct paradigm all along
Debateable.
previously:
January 2023, 125 comments - https://news.ycombinator.com/item?id=34591625
August 2017, 150 comments - https://news.ycombinator.com/item?id=15057371
February 2015, 10 comments - https://news.ycombinator.com/item?id=9065447
Oh wow! So I guess Marko has been around for while. Despite that, this is my first time hearing about it.
The main author also wrote morphdom circa 2015, which is/was used in htmx and sprung up a bunch of other frameworks.
I don't normally comment on formatting, but for a language I assume they're dog-fooding for the demo it's amusing that none of the gradient-backgrounded text renders visibly ("HTML-based", "building web apps", etc).
This looks interesting and seems like a vast improvement over jsx.
I especially love the pug style concise syntax which for some reason they have buried deep into the docs rather than showcasing front and center.
https://markojs.com/docs/reference/concise-syntax
For those curious, the Marko team created a HN clone to showcase Marko 6
https://github.com/marko-js/example-hacker-news
The problem when taking several languages and mixing them together this way is that the result is supposed to have brevity, but it’s actually unreadable. You need slash to mean something grammatical, colon has to say something, you can speak “open brace” in a way that anticipates; @ means “at”. This code looks more like a compression scheme.
I think I managed to combine three languages in one with Mint (https://mint-lang.com/):
1. There is HTML (tags) with, but without interpolation {...} you can put string literals, variables and everything that type checks as HTML children.
2. There is CSS but only in style blocks where you can interpolate any expression you need and put in if and case expressions too.
3. There is the normal Mint code you write the logic in (this would be the JavaScript in other languages).
Here is an example which have all three: https://mint-lang.com/examples/7guis/flight-booker
The challenge was to make it seamless enough that so it doesn't look like that we tried to mash languages up, but to make them form a different language that is consistent and simple at the same time.
Your Mint language looks awesome! You’ve done a great job making it very seamless between the 3 languages. I had a couple thoughts regarding your css/styling though:
1. The one feature I prefer in Marko when compared to Mint is Marko’s nice ID and class syntax, rather than your custom selectors, so you can just use regular CSS (which seems to be advancing faster than the JS & HTML specs combined). You could get the scoping using shadow roots for your components (I’m sure this has flow on consequences, but given you own the language it’s probably better case than many others.)
2. Interpolating values directly in CSS blocks is something that a lot of HTML templating systems sort of give up on (see Astro going out of it’s way to make interpolating variables super verbose [0]), so I’m glad to see you do it. Does the value interpolation compile to CSS variables that are set on the component root (or somewhere else I suppose) as in Astro [0], or is it just simple interpolation? Additionally, I can’t help but notice your hash symbol would conflict with ID selectors, so is CSS nesting available?
Please don’t take this as criticism! I really like what you’ve done here and am very curious.
[0]: https://docs.astro.build/en/guides/styling/#css-variables
1. Inside style blocks it's pretty much regular CSS except for interpolation and if/case expressions, so you can create a style for the root element and then use ids and classes if you desire, but it won't be optimized.
2. CSS definitions without interpolation compile down to static CSS while the ones with interpolation compile down to CSS variables which are set on the element where the style is assigned. This also allows for passig arguments to styles [0].
CSS nesting is supported and the interpolation doesn't conflict with the id selectors because interpolation is not supported in selectors.
[0]: https://mint-lang.com/reference/styling/arguments
It's there a way to define routes in a nested, hierarchial fashion, preferably across multiple modules?
For example, with react-router, my root route object array I define by spreading out other route object arrays that I've imported from other modules in my project. And each of those do the same thing, recurring as necessary until I get to the full depth of my route tree.
No it's nor supported currently.
Isn't syntax pretty much just compression? We could write down the AST itself in some generic notation but that would be orders of magnitudes larger, so invent clever tricks to compress it, which we call syntax.
Edit: typo
almost all code looks like nonsense when you're unfamiliar with it
The new jquery? Eurk.
I thought React was the new jquery.
Maybe just me but I actually think building web apps is already fun. I’ve got a hot reloading instant dev environment, I can publish to users in an instant… it’s great!
Looking at the Marko examples I feel the same way I do whenever similar stuff gets showcased: it’s trying to focus too hard on brevity and/or cutesiness and doesn’t seem like it would scale well to a full, complex web app. But maybe it’s not supposed to and maybe that’s fine.
React and Svelte and the rest can read clunkily at times but they have a clear separation of concerns and I’m glad for that.
FWIW, marko comes from Ebay. So, it scales - and being primarily SSR, its a better UX than your preferred frameworks
HTML rendering is, to be fair, not usually where you find the scaling issues.
Pretty much every JS framework has SSR, the question is really how quickly does it hydrate. React typically rates poorly there but Svelte does great, at least partially because it has a compiler to optimize (like Marko does, it appears).
Marko’s compiler is designed for partial hydration (by default, without any special developer effort), which performs quite well. IIRC they were also looking at implementing “resumability” (term coined by Qwik, for an approach that sidesteps hydration as a concept entirely). I’m not sure where they’re at on that now, but I think it’s generally safe to say that Marko prioritizes load time performance more than nearly all other frameworks.
Marko did ssr by default, a decade before the other frameworks decided to bolt-on ssr...
React has a clear separation of concern? Excuse me? I only see do-it-all pre-styled components in the real world.
Looks absurd. Can't wait to try it.
I love the landing page for this project. It's very engaging.
I didn't look deep into Marko yet, but in my opinion JSX is by far the best HTML template language there is. And it's not restricted to React.
Most other template languages hits serious limitations really fast. I tried and hated (for non trivial things): Angular, Handlebars, Razor (dotnet) and Vue (which does support JSX optionally).
I've been liking the model of the Python library Dominate [1]. You write your HTML as regular Python code, and you render() once at the end, having full control over the formatting. Well, at least in theory; in practice the formatting is brittle and the library otherwise makes some choices I don't like.
I wrote a Rust library with a more restricted/verbose API, and I've been enjoying using that. Unfortunately, I find it really hard to make it as fast as I want. It's really the perfect use case for arena allocation, but doing that and keeping the API as function calls mirroring HTML is not trivial, and probably requires macros to rewrite the tree as a series of stack pushes.
1. https://pypi.org/project/dominate/
Could you please try to be a bit more substantive with your comments?
E.g., Why do you think JSX is the best? What limitations did you hit with those other template languages?
Most template languages can't do something like that:
Marko can! It's "define" tag lets you create reusable templates in your reusable templates.
https://markojs.com/docs/reference/core-tag#define
RippleJS is doing the same sort of thing, but better IMO
I written lots of Vue/angular/react (like more than 3 major projects with each) and I'm a firm believer that:
1. Jsx is nicer to write but that's a non issue
2. vue's and angular's directives and bindings lend themselves to much saner and lighter rendering (performance does matter)
3. Vue is much easier to tame, it's reactivity model does not require a PhD in hooks or a deep understanding of React's internals. It just works out of the box as it should and is much easier to control the rendering lifecycle.
At the end of the day, after many years, my preference goes with Vue and Nuxt especially which is tremendously better than the monsters of Next or RR. That's what pays the bill the easiest and is eventually easier to maintain and optimize.
Have you ever given lit html a whirl?
It's misleading to call this "A declarative, HTML‑based language" when it in fact relies heavily on writing explicit JavaScript (which is very different from HTML and not declarative at all).
Something like htmx does come a lot closer to being a HTML‑based language in my opinion. So much so that you could add it to the actual HTML spec.
(That's not to say that Marko is bad, just that it's more a way to mix HTML and JavaScript in a more intuitive way rather than a declarative, HTML‑based language.)
Maybe off topic, but I’d kill for a HAML for TSX or Svelte!
Working with HAML really did make building web app fun IMO. I can’t be the only one!
Someone posted here, thanks for that!! It immediately reminded me of HAML: https://harcstack.org/
I like HAML a lot, it was the most pleasant to develop with. And it shares a lot in common with Stylus. They both shared things in common.
NO NEED FOR: Curly braces, parentheses and semicolons. The cool thing, it was all optional and I wasn't forced to make use of all shortcuts!
I developed my own CSS Framework in 2003, shared with some UX guy at Yahoo, who incorporated it into YUI mostly as is, after I waived all rights. Most of that became internet standard. Later I had my own PHP based CSS scaffolding framework in 2005 that could also generate grids (before flex-box). SCASS/LESS was really similar to my framework, when it came out.
But I disliked it, it just looked like PHP mixed with CSS. I thought why accept the ugly syntax, despite a compiler being available?
The best ever existed is: HAML + Stylus + (HARC?)
See the beauty of it: https://stylus-lang.com/docs/selectors.html
Now compare with HAML https://haml.info/
I think https://harcstack.org/ makes a good successor.
Svelte already has a Pug preprocessor :)
I used to use it years ago. So much nicer than HTML.
vue allows other languages in .vue files for both css & html similar to js
Here’s an informing recent DevTools podcast episode featuring someone from the Marko team, https://www.devtools.fm/episode/
404
Oops!
https://www.devtools.fm/episode/146
This sort of stuff is just a big nope:
Why make a special language? Just use HTML and TypeScript that will be compatible with editors, tooling, etc. This is the same mistake Imba made.It's a shame because the core of Marko looks phenomenal: streaming, fine-grained bundling, rendering performance, etc.
Also not sure about the file-based routing of Marko Run. That was a big reason why I abandoned SvelteKit.
File-based routing is fundamentally flawed and it cannot be fixed. A number of libraries opt for it since it's easier for newcomers to pick up, but eventually you run into all of the cases where you do need something else. This in turn leads you to a hybrid system of multiple things where there's no single source of truth and everything is spaghetti.
Care to make quite a simple example where file based routing would struggle?
Role based access control is one of the simplest examples, your routes need to be conditional and all come with related metadata for permissions and such. With file-based routing you'll then end up with your routes defined in one place and the configuration for them either in a separate different place or split up across the codebase. Whenever you need to change something you need to remember to do it everywhere else. If your routing is in code, you can define everything in one place with strict type checks, tests, and so on.
Let’s not pretend that useState() is plain TypeScript either. It’s a DSL in disguise.
JSX is amazing for stateless rendering of templates. Not so much for state management. That should really have been given a dedicated DSL. Here I think Marko did the right thing, why they then made even for-loops a dsl is more questionable.
I wonder how this compares to htmx, seems similar though obviously different in terms of approach. I'm getting a little jQuery feels too.
The intro is also incorrect in my opinion. It writes a "HTML-based language", but this is more a hybrid of HTML and JavaScript. Why is JavaScript not mentioned in the intro?
> I already disliked that immensely in PHP. Not going back to that spaghetti mesh-up.
That looks like a pretty normal template to me and nothing like plain PHP templates? What do you mean by "spaghetti mesh-up"?
Is there any significant difference between that and
(ideally .setHTML() when it's available)At that point I think I'd have a skeleton html file that fetches a JS that does it all. I'd take JS with embedded HTML over HTML with embedded JS.
Isn't it wonderful that we live in a world where both ways can exist together, along with a myriad of other ideas for how to do the exact same thing?
The point is that both ways contain the same "spaghetti" that the OP is complaining about and that it's unclear what alternative they actually prefer.
No.
But you can write dreadful code in any language
this comment really proves that people do not consider the information presented to them
marko is not comparable to php
it is much closer to svelte
i used to sympathize with people complaining about js-fatigue, but at some point its a skill issue
Marko is server side. How is that closer to svelte?
Svelte can also be used for SSR
How would you prefer to write those examples?
Separate templating from computing I'd assume.
Personally, I'd either just put the content in an ID-ed span and have a script to replace the content. Another, perhaps better, way is to use Alpine.JS which excels at this kind of stuff.
You should give this a read, it explains why they chose to put everything within the markup
https://markojs.com/docs/explanation/separation-of-concerns
> I'd either just put the content in an ID-ed span and have a script to replace the content
And so your script is broken when someone else in your team (or maybe even yourself) renames or removes the ID and forgets to search in the whole project if some piece of code depends on this ID. JSX fixed all that mess 10+ years ago.
Yet you still need IDs for ARIA attributes, so now the JSX also needs a pile of shared variables
Either solution sounds more verbose than the example and require writing code in at least one other source file
But that separation is sometimes the point. A designer tweaking the looks has no chance to break the computation logic, and an engineer tweaking the computation part won't disrupt the design by mistake.
Terseness is good for code golf [1]. I disliked CoffeeScript after writing it for some time: nearly any typo can result in another syntactically correct program which, of course, does not what you wanted the original program to do, or fails the compilation in an unrelated place. A practical language has safety margins, aka some redundancy.
[1]: https://en.wikipedia.org/wiki/Code_golf#Dedicated_golfing_la...
Unless the designer removes the id, or the engineer introduces new output that is not styled.
But they're both framework-agnostic.
This snippet works with any framework and any build step.
I'll concede that Alpine.js is harder to understand and more verbose than Marko's syntax, but in order to use Marko you have to commit to the Marko framework. If you're willing to choose a framework solely for its JS-in-HTML capabilities, there are much better choices (like SvelteKit that handles JS-in-HTML wonderfully).Fwiw, Marko predates svelte quiet significantly.
It was originally created by eBay iirc, back in 2014 or so.
It's syntax was even stranger back then, like writing "h1.myClass my header" to create a <h1 classes=myClass>my header</h1> and similar
Don't blame Marko for this type of abomination. This is basically fancy react JSX.
ITS just bizzare people want to parse JavaScript at the same instance they're parsing html.
Also, LLMs are going to destroy any new framework. Someone's gonna need to figure out how to integrate these things into new tools. LLMs suck but it'll be much worse if they freeze innovations cause they're too expensive to chase the new hotness.
LLMs can make use of documentation and example code.
But because of LLMs there will be less example code
Yes. I understand second order context pollution.
You two are complaining about different things. Note how the parent mentioned PHP as the reference.
I think the grand takeaway is that people like to complain
There’s some joke here about how that’s in contrast to Marketo…
There’s a Marko Pollo joke, too, but I’m too chicken to say it.
It reminded me of ColdFusion, which could be something better if it hadn't ended up in Adobe's hands.
Honestly, why not just put Scheme on the browser.
Scheme is capable to represent HTML JS and CSS all in 1 language.
So .... ColdFusion?
It looks like they reinvented ColdFusion for modern web apps.
Honestly I don't know... I'm somewhat skeptical about these "next big thing that will fix all your pains in web development". There is so much fragmentation in JS libraries / frameworks. Angular, React, Vue, Svelte, Asto, SolidJS, NextJS, Nuxt, Qwik... The list is so overwhelming. Almost each one claims that it fixes a problem in other framework, and a year later the other framework fixes that issue... I think it's better to stick to a big old player, such as Angular.
Marko has been around for over a decade at this point and powers most of eBay. It's not the oldest or the largest, but it's got a pretty solid track record
Honestly I don't know... I'm somewhat skeptical about these "next big thing that will fix all your pains in web development". There is so much fragmentation in JS libraries / frameworks. Angular, React, Vue, Angular, Asto, SolidJS, NextJS, Nuxt, Qwik... The list is so overwhelming. Almost each one claims that it fixes a problem in other framework, a year later the other framework fixes an issue... I think it's better to stick to a big old player, such as Svelte.
No, just kidding. I believe in progressive enhancement, and none of these does this very well.
abomination
Hi!
hello!
Dear front end devs
Please chill w making new languages and frameworks that re-solve solved problems. The internet is working fine as it is.
Warmest regards, Matt
Matt,
Marko was created over a decade ago at Ebay.
One of its core dependencies is morphdom, which has been used successfully by a slew of frontend view libraries like Marko, including Phoenix LiveView.
Please chill. In general.
Use cases are not all equivalent.
Ignorance is boring.