To me, from the getting started, it looks like yet another JavaScript framework.
Might be good, unfortunately I got framework fatigue.
My personal website has about 30 lines of javascript, no framework and no library.
Contrarian take: the whole field of front-end frameworks seems to be lacking an all around good isomorphic solution to me.
Is there anything that would out of the box: 1) do fully static server-side rendering that outputs zero JS by default, 2) still be capable of rendering client-side interactive components where appropriate (for user agents with JS), 3) have both of the above as equal first-class citizens without contrived workarounds needed to achieve either interactivity or SSR, 4) handle all required bundling/fetching at build stage and load fast at runtime, 5) be isomorphic and leverage TypeScript typings to validate the correctness of the whole thing at build time as much as possible, and ideally 6) allow easy reuse of preexisting React components?
Another comment already mentioned Svelte. Alternatively, Hotwire Turbo or htmx might be more along the lines of what you want. Choose your own server-side language. I sprinkle in fancier frameworks when individual components need it, but this is more the exception than the rule.
The biggest difference is that it uses tags/components as a means to mix markup and code. (the "old" server-side language ColdFusion does this same thing)
I still believe good old sever-side rendering + js sprinkle is still the best business value for the buck. Our industry seems to not have analysis on engineering cost compute with business value.
This is the best way to get Python devs to start using JavaScript. But if you're already writing in JavaScript (or TypeScript), why wouldn't you want to re-use the code on server and client? Next.js is basically modern day PHP - you create a file in /pages/foo/bar.ts and it renders at localhost:3001/foo/bar. It really doesn't get much easier than this, and anyone complaining about it has likely not tried it or doesn't have a green field project where they can start from scratch with TypeScript and Next.js.
Also, this trope that "JavaScript can only render websites that require JavaScript to read" is a common misconception. Next.js, for example, is perfectly capable of rendering websites that work for clients with JavaScript disabled. In fact, that was kind of the original point of SSR: to make websites that search crawlers could read by processing the HTML sent from the server. The server renders the initial page, and then the client (optionally, if following best practices) "hydrates" the DOM to render any further content that requires client-side interaction (indeed, it's bad practice to require hydration, and a mismatch between server rendered DOM and hydrated DOM will generate warnings in development).
I wouldn’t say the state of the art is particularly great, but interestingly enough server-side rendering + JS sprinkle is exactly what many modern frameworks like Marko are going back to.
They provide some opinionated/convenient ways to author code but deliver fully server-side rendered HTML. They use fancy means to detect where interactivity is needed, and only ship JavaScript to the browser for those components.
In fact, they make what you describe easier to achieve. When you do it on your own, it’s up to you to ensure one piece JavaScript doesn’t mess another piece up, it’s up to you to sync back-end with front-end—but with a good framework you get encapsulation, bundling, and typing with compile-time checks (if you removed an attribute from some object server-side but forgot to update the client side, your build will fail with a useful error message before you can deploy it).
Your specific recommendation really depends on your use-case.
But I think the general principle applies, and you can even go further: try building simpler things. This is why I use static websites + a little JS and some API calls until I absolutely need my own server/SPA/etc.
The technical lead needs to explain and link between highly interactive widget to business value. Breaking down feature/value to pieces and link each to what type of widget it needs. JS frameworks always sell like lets build the whole thing with this whole tools. It's not only not fined-grain solution, it's often mismatched.
I don't buy the isomorphic thingy that reduces cognitive load because that's not only it's not absolutely true, it could be false and brings other type of problems.
I elaborate under the other comment. Htmx is good as long as there's not a lot of business value that needs highly interactive widgets. The whole thing is highly interactive sounds like a attempt silver bullet. The isomorphic invention currently doesn't solve client-server problems at all, it only solves 'I want to use one language' problem. Data still needs to live somewhere and move to somewhere, and there's physical distance between them, so it still has problems due to that condition.
I agree, that's why I like NextJS that gives you the DX of thinking in reusable and composable components (React) and type safety (TypeScript) that then ships no JS at all to the client.
And eBay is easily the jankiest website I use on an at all frequent basis. Click about in profile/settings and you get randomly shuttled about between pages designed in (by the looks of them) 2010, 2002, 2003, and 2016...
I don’t have inside info like you might, but it seems like a mean-spirited comment considering ebay.com uses marko, as well as other sites in the ebay group.
It definitely has not gained a lot of traction outside of ebay but there is a fair amount of buzz around the marko6 release with a completely new tags-based language.
It is also one of the few frameworks that leverage html streaming in a simple way (and has for a long time) and offers islands-style partial hydration out of the box.
Looks scary. ${index} and ${color} require escaping, (user.loggedOut) requires parentheses and |color, index| requires pipes. I just don’t understand what is going on.
What I like React for is that I can use JavaScript for things that seem to belong to JavaScript, like conditionals and loops. And components just have properties that may be dynamic and conditioned, in which case they obviously require JavaScript. But here the syntax breaks that separation of concerns IMO.
Maybe it's only me because I'm not a frontend developer and obvious things are not obvious to me, but it seems that there is nothing in the docs about deploying to a server and visiting a page it with a browser.
Anyway, I traced the JavaScript code. There are files packed with Webpack. They're not minified and pretty easy to follow. I even found a comment linking to https://github.com/gorhill/uBlock/issues/205 with the note "Do not handle added node directly from within mutation observer".
There are some docs on how to deploy for different node servers (express etc) as well as an examples repo which has templates for different environments.
I run Marko on cloudflare pages for some of my clients and couldn’t be happier, it’s the perfect framework for people who like writing plain html, but still want the advantages of a UI library like react.
Per some tests as of last year[0], Marko[1] is much more performant than Svelte, which matters a lot for UX and for page rankings (especially in case of more complex sites).
I’d expect Qwik to be faster than any of the above, but it seems not quite production-ready enough.
What's interesting is Marko and Solid are opposite in some ways: the first is HTML first, with sprinkles of interactivity; and the second is JavaScript first, in that it uses JavaScript and JSX primarily. Despite these opposite approaches, they are both iterating towards having very little runtime overhead.
Readit News
Is there anything that would out of the box: 1) do fully static server-side rendering that outputs zero JS by default, 2) still be capable of rendering client-side interactive components where appropriate (for user agents with JS), 3) have both of the above as equal first-class citizens without contrived workarounds needed to achieve either interactivity or SSR, 4) handle all required bundling/fetching at build stage and load fast at runtime, 5) be isomorphic and leverage TypeScript typings to validate the correctness of the whole thing at build time as much as possible, and ideally 6) allow easy reuse of preexisting React components?
https://turbo.hotwired.dev/https://htmx.org/
https://qwik.builder.io/
Deleted Comment
"my use case doesn't need a JS framework so we don't need JS frameworks"
Also, this trope that "JavaScript can only render websites that require JavaScript to read" is a common misconception. Next.js, for example, is perfectly capable of rendering websites that work for clients with JavaScript disabled. In fact, that was kind of the original point of SSR: to make websites that search crawlers could read by processing the HTML sent from the server. The server renders the initial page, and then the client (optionally, if following best practices) "hydrates" the DOM to render any further content that requires client-side interaction (indeed, it's bad practice to require hydration, and a mismatch between server rendered DOM and hydrated DOM will generate warnings in development).
They provide some opinionated/convenient ways to author code but deliver fully server-side rendered HTML. They use fancy means to detect where interactivity is needed, and only ship JavaScript to the browser for those components.
In fact, they make what you describe easier to achieve. When you do it on your own, it’s up to you to ensure one piece JavaScript doesn’t mess another piece up, it’s up to you to sync back-end with front-end—but with a good framework you get encapsulation, bundling, and typing with compile-time checks (if you removed an attribute from some object server-side but forgot to update the client side, your build will fail with a useful error message before you can deploy it).
But I think the general principle applies, and you can even go further: try building simpler things. This is why I use static websites + a little JS and some API calls until I absolutely need my own server/SPA/etc.
I don't buy the isomorphic thingy that reduces cognitive load because that's not only it's not absolutely true, it could be false and brings other type of problems.
slim-lang + htmx or stimulusjs and a single dev can replace a team.
It definitely has not gained a lot of traction outside of ebay but there is a fair amount of buzz around the marko6 release with a completely new tags-based language.
It is also one of the few frameworks that leverage html streaming in a simple way (and has for a long time) and offers islands-style partial hydration out of the box.
What I like React for is that I can use JavaScript for things that seem to belong to JavaScript, like conditionals and loops. And components just have properties that may be dynamic and conditioned, in which case they obviously require JavaScript. But here the syntax breaks that separation of concerns IMO.
Anyway, I traced the JavaScript code. There are files packed with Webpack. They're not minified and pretty easy to follow. I even found a comment linking to https://github.com/gorhill/uBlock/issues/205 with the note "Do not handle added node directly from within mutation observer".
I run Marko on cloudflare pages for some of my clients and couldn’t be happier, it’s the perfect framework for people who like writing plain html, but still want the advantages of a UI library like react.
Not saying this is a bad thing. Svelte is universally loved.
But it does raise the obvious question of why not Svelte. (Or Solid or Astro or...)
Same with HTML streaming. Marko has had it since 2014 and IIRC SvelteKit doesn't have it yet.
I absolutely love Svelte but if you need those features then Marko would be a better choice.
I’d expect Qwik to be faster than any of the above, but it seems not quite production-ready enough.
[0] https://dev.to/this-is-learning/marko-for-sites-solid-for-ap...
[1] In the Reddit the author mentions that, despite focusing on Solid+Astro in the article, Marko is actually still more performant than those: https://www.reddit.com/r/javascript/comments/ubs6i9/marko_fo...
''' <tabcontainer> <tab> ... </tab> </tabcontainer> '''
So any markup technology these days needs that ability I think.
Then there's Content Security Policy to think of too.
Jokes aside, this does look pretty neat.
It looks like Marko v6 is going to perform incredibly fast, up there with vanilla javascript and solidjs, ahead of Vue, React, and Angular. https://dev.to/ryansolid/marko-compiling-fine-grained-reacti...
What's interesting is Marko and Solid are opposite in some ways: the first is HTML first, with sprinkles of interactivity; and the second is JavaScript first, in that it uses JavaScript and JSX primarily. Despite these opposite approaches, they are both iterating towards having very little runtime overhead.