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.
I agree, if there is a death of React it will be killed by Next/Vercel.
I probably shouldn’t care. I’m just not looking forward to the chaos of another full “turn” in JavaScript, akin to query->backbone or backbone->react.
Maybe I shouldn’t fear it. I’ve just yet to see an idea that feels valuable enough to move an entire ecosystem. Svelte, HTMX, etc… where is the “disruptive” idea that could compel everyone to leave React?
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.
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.
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
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
1. native support for all http verbs such as put and delete in html itself without relying on JavaScript
2. sensible controls for drop down, select, multi select, date, time, datetime and so on without relying on any JavaScript
3. Submitting a form and submitting actions without reloading the whole page again without requiring any JavaScript
4. A whole lot of stuff yes without requiring any JavaScript
When I first heard the term htmx, I thought that was what htmx was but sadly it is just intercooler. What I am asking for requires broad support from browser vendors.
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)
> 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.
Oh man, I wish people would stop attributing picking SPA's to not wanting to use "lame" technology. It makes them sound myopic and naive. Really naive.
You may not have been around at the time, but I certainly was. And the idea that SPAs don't (or didn't) have their place is just plain absurd.
Like "Tell me you're a backend dev who is made they have to learn new stuff to stay current" without telling me.
In fact, I'm not even sure what your argument actually is. Is it MSP vs SPA? Is it JSP vs any of the other backend languages you can still use with React? Is it templates vs JSX? What are you actually trying to argue?
Are your rose-colored glasses ignoring what a pain a decent UX was to build in those technologies? That mobile apps pushed backends to an api-only version and SPAs took over for the frontend? Are you saying people should pick old technologies wtih old tooling just because you didn't get on board with it the first time?
It's not swinging back to JSP, it's finding a middle-ground between the 2. THAT'S what progress is.
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 dunno, to me that seems like all YAML's mistakes all over again. I quite like the conciseness, and significant whitespace seems like a good match here, but the double hyphen thing really seems odd to me. And the syntax is so hard to parse, apparently, that their own example is syntax highlighted incorrect, coloring content as if it's tags.
I was looking at Marko a few years ago because of the concise syntax. I have always thought highly of Pug and would have loved a framework that integrated that sort of elegant, minimal syntax. Unfortunately, Marko doesn’t even get the syntax highlighting right in its own docs for this style.
The example on that page with leading commas to separate tag attributes, and a number of other choices across the framework are also a turn off for me personally.
I’ve mostly been using Svelte for the past half-decade instead but still hope for something more elegant to come along.
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.
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.
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).
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.
> A lot of people are coming to eBay from a link that someone shared or from a search engine... This whole "amortized cost savings" you get from a Single-Page App (SPA) you don't necessarily get with eBay. Or people might go to eBay and open up ten [browser] tabs... If that's ten SPAs you're opening you're not really saving that much.
> At the same time in 2012 people are coming out with React, Angular... the question was "can we just use these tools?" and the answer was "kinda no"... Initially React was considered but the things we needed right out of the gate was streaming [sending as much HTML as... available without waiting for services responding with loaded data for the specific page]... With streaming you can send out stuff to the browser and have the browser [start] showing content to user without having to wait for your slowest service. At eBay there are a lot of services... Essentially if we were to adopt React or Angular the fact that there wasn't streaming would essentially mean that we're throwing away two seconds or so... which is not acceptable.
In years of using eBay, have never had an issue with it. Sad that that's a high praise these days, but it is. eBay is fast, it works damn well, and always has.
As a counter point, React's poster children, in messenger, Facebook and Instagram. Have all been plagued with UI bugs for the entire time I've used them.
Obviously those aren't wholly comparable, but I do think it's worth taking note of the actual outcomes we have when tools are used at real scale.
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.)
<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?
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.
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?
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.
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.
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.
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.
I personally do not want to write HTML and I especially do not want to encode logic into it. This wave of HTMX-likes has some interesting ideas but encoding it all into HTML just feels so wrong to me. JSX is likewise awful. We need real programming languages here.
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.
SSR isn’t a craze. Web applications have been served that way for literal decades now.
I agree, if there is a death of React it will be killed by Next/Vercel.
I probably shouldn’t care. I’m just not looking forward to the chaos of another full “turn” in JavaScript, akin to query->backbone or backbone->react.
Maybe I shouldn’t fear it. I’ve just yet to see an idea that feels valuable enough to move an entire ecosystem. Svelte, HTMX, etc… where is the “disruptive” idea that could compel everyone to leave React?
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.
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.
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.
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:
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).
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?
No Vue, is just JavaScript. React is JSX.
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...
What I'm hoping to see in the future are:
1. native support for all http verbs such as put and delete in html itself without relying on JavaScript
2. sensible controls for drop down, select, multi select, date, time, datetime and so on without relying on any JavaScript
3. Submitting a form and submitting actions without reloading the whole page again without requiring any JavaScript
4. A whole lot of stuff yes without requiring any JavaScript
When I first heard the term htmx, I thought that was what htmx was but sadly it is just intercooler. What I am asking for requires broad support from browser vendors.
We are working to integrated some of the ideas of htmx directly into the HTML specification:
https://alexanderpetros.com/triptych/
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.
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.
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)
> It was the correct paradigm all along
Debateable.
> 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.
Oh man, I wish people would stop attributing picking SPA's to not wanting to use "lame" technology. It makes them sound myopic and naive. Really naive.
You may not have been around at the time, but I certainly was. And the idea that SPAs don't (or didn't) have their place is just plain absurd.
Like "Tell me you're a backend dev who is made they have to learn new stuff to stay current" without telling me.
In fact, I'm not even sure what your argument actually is. Is it MSP vs SPA? Is it JSP vs any of the other backend languages you can still use with React? Is it templates vs JSX? What are you actually trying to argue?
Are your rose-colored glasses ignoring what a pain a decent UX was to build in those technologies? That mobile apps pushed backends to an api-only version and SPAs took over for the frontend? Are you saying people should pick old technologies wtih old tooling just because you didn't get on board with it the first time?
It's not swinging back to JSP, it's finding a middle-ground between the 2. THAT'S what progress is.
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.
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.
For those curious, the Marko team created a HN clone to showcase Marko 6
https://github.com/marko-js/example-hacker-news
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
I dunno, to me that seems like all YAML's mistakes all over again. I quite like the conciseness, and significant whitespace seems like a good match here, but the double hyphen thing really seems odd to me. And the syntax is so hard to parse, apparently, that their own example is syntax highlighted incorrect, coloring content as if it's tags.
I was looking at Marko a few years ago because of the concise syntax. I have always thought highly of Pug and would have loved a framework that integrated that sort of elegant, minimal syntax. Unfortunately, Marko doesn’t even get the syntax highlighting right in its own docs for this style.
The example on that page with leading commas to separate tag attributes, and a number of other choices across the framework are also a turn off for me personally.
I’ve mostly been using Svelte for the past half-decade instead but still hope for something more elegant to come along.
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.
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
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).
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
React has a clear separation of concern? Excuse me? I only see do-it-all pre-styled components in the real world.
Here’s an informing recent DevTools podcast episode featuring someone from the Marko team, https://www.devtools.fm/episode/
Some interesting context from the podcast:
> A lot of people are coming to eBay from a link that someone shared or from a search engine... This whole "amortized cost savings" you get from a Single-Page App (SPA) you don't necessarily get with eBay. Or people might go to eBay and open up ten [browser] tabs... If that's ten SPAs you're opening you're not really saving that much.
> At the same time in 2012 people are coming out with React, Angular... the question was "can we just use these tools?" and the answer was "kinda no"... Initially React was considered but the things we needed right out of the gate was streaming [sending as much HTML as... available without waiting for services responding with loaded data for the specific page]... With streaming you can send out stuff to the browser and have the browser [start] showing content to user without having to wait for your slowest service. At eBay there are a lot of services... Essentially if we were to adopt React or Angular the fact that there wasn't streaming would essentially mean that we're throwing away two seconds or so... which is not acceptable.
404
Looks absurd. Can't wait to try it.
I think it's worth noting Marko's proven nature.
In years of using eBay, have never had an issue with it. Sad that that's a high praise these days, but it is. eBay is fast, it works damn well, and always has.
As a counter point, React's poster children, in messenger, Facebook and Instagram. Have all been plagued with UI bugs for the entire time I've used them.
Obviously those aren't wholly comparable, but I do think it's worth taking note of the actual outcomes we have when tools are used at real scale.
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.)
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.
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
How would you prefer to write those examples?
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.
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
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?
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 reminded me of ColdFusion, which could be something better if it hadn't ended up in Adobe's hands.
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.
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.
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.
I wonder how this compares to htmx, seems similar though obviously different in terms of approach. I'm getting a little jQuery feels too.
Honestly, why not just put Scheme on the browser.
Scheme is capable to represent HTML JS and CSS all in 1 language.
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
Why are you copy pasting the same comment, under different usernames everywhere?
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.
I love the landing page for this project. It's very engaging.
It looks like they reinvented ColdFusion for modern web apps.
The new jquery? Eurk.
I thought React was the new jquery.
abomination
So .... ColdFusion?
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.
[dead]
[flagged]
hello!
[flagged]
I personally do not want to write HTML and I especially do not want to encode logic into it. This wave of HTMX-likes has some interesting ideas but encoding it all into HTML just feels so wrong to me. JSX is likewise awful. We need real programming languages here.