As some of you may know I recently joined the Marko team, but I've been working on a future version and haven't actually got to dig into the curre...
For further actions, you may consider blocking this person and/or reporting abuse
Wonderful post Ryan! Personally, I'm not a fan of tag templates and how a for/of loop is actually a component. Never liked that stuff in React either, I'd just write Javascript in parenthesis. I think if the syntax had to be like how it is, then something that looks like the v-for binding in Vue might be a bit more intuitive. Maybe I feel like that because I'm used to doing something different from how Marko does it.
Maybe you could throw the code in a gist next time, it'll be easier for readers to mess around with the code that way. Streaming while you're rendering sounds exciting, maybe you could touch on that next?
Yeah that's a good suggestion. Or put up the repo just didn't seem like enough code. Unfortunately being server first it is a bit clunkier in things like CodeSandbox. This is a bit new for me since I'm primarily used to looking at client setups.
Yeah the streaming solution is really cool. And it is the default rendering in the cli. So technically it is at work there, but need to add some async data loading to leverage. I will see if I can come up with a good example to leverage it.
React doesn't have loop components. Or really any bundled components. Or template really
I think he means he doesn't like using HTML tag looking stuff at all. Like Components syntax period and probably prefers something like HyperScript Helpers syntax. github.com/ohanhi/hyperscript-helpers
I tried Marko.js years ago. I developed several apps and contributed to MarkoJS. Due to the lack of adaption in the community, I switched to Next.js. MarkoJS is primarily driven by eBay. I can't recommend it anymore. This has several reasons:
I think these are pretty fair criticisms. I think the discrepancy between client and server isn't particularly obvious (like dealing with async) and as a server first library in a sea of client side first libraries what it doesn't have on the client is much more obvious. As you said eBay didn't have the use case so it wasn't prioritized.
At the same time Webpack was being developed they were building their own bundler aimed at doing realtime on the fly compilation, again to suit their purposes. It took years to bring everything over to the common tooling especially since that tooling early on did not cover eBays cases.
I think TypeScript is going to take a bit more time. When you consider how long it has taken Vue and Svelte with the communities behind them. It is on the list, but as you can imagine its a pretty long list.
I think the rest of concerns are fairly typical and we're always looking at improving on that. I definitely can see how the lack of community and support would have left you on a sour note and having only joined the project I don't have the long history here. But for me coming across this is like a treasure trove. The technology and approaches developed here standout on their own still years later, so I'm looking at how we can change the narrative.
I think I wasn't clear enough. The API of MarkoJS is very hard to grasp. A lot of heuristics happens under the hood instead of defining a clear API (github.com/marko-js/marko/issues/1285, github.com/marko-js/marko/issues/1291, github.com/marko-js/marko/issues/1276, github.com/marko-js/marko/issues/1290). The productivity boost between Marko.JS and Next.js is tremendous. Next.js rely on React.js and open opportunities you can't archive with Marko.JS. You have to set your clock to zero. Try to find docs about component testing. You will end up researching GitHub. You don't find anything from others except eBay. It's a big deal for eBay but doesn't use it for your own business, just have fun with it in your free time. I did the mistake.
Except HTML-Streaming MarkoJS isn't special compared to other CSR/SSR frameworks like Next.js. It's quite the opposite. In Next.js you can use different rendering techniques and rely on a huge and healthy ecosystem.
It looks like you hit some annoying issues. There are some parts of Marko's legacy that are a bit awkward. I'd love to do some cutting but it's difficult to change things on active users.
The APIs are starkly different. I think that was a bit of culture shock to me too, when I was trying to find my bearings. Like why name this differently .. why is it
input.renderBodyor notprops.children, and then I realize Marko was developing this stuff back before things had consolidated. It's more than set the clock to 0. It's almost like Sliders, where you have moved to a parallel universe where everything did not go to using SPAs.I've been thinking a lot about how we can streamline this API experience but it's tricky when there isn't prior art. I see you had some difficulties with some of the "magic" heuristics on how Marko automatically determines partial hydration. Those are areas that definitely need some de-mystification and we are actively working on improving. Again this is a bit of an exploratory process as to my knowledge no other framework has these features. This partial hydration has been a hot topic for a while but very little progress has been made comparatively. It's tricky to do without it being some manual thing. I'd love to see Marko's solution be less brittle and we are working on that. But as you've suggested it has been working for eBay who rely on page load performance more than most.
I think on one hand you see eBay and think maybe React or Angular type scenario. But Marko is part of the Open JS Foundation and isn't owned by eBay. It has been primarily the work of 2 maintainers for the past 3 years for better or for worse. So put that in perspective when you are looking at this library. It isn't perfect, and the ecosystem is definitely underdeveloped.
So I'm not suggesting you drop your production Next.js projects for it. Just that I think it's worth checking out as it does offer some unique features that haven't been replicated and that seem to be a hotter topic these days. When combined with the fact the Marko team already working on next-gen solutions in these areas you have something interesting.
That is what interested me. I'm an early adopter and I look for technology that is ahead of the curve and with Marko and isomorphic rendering it's not much competition. I'm not measuring this in terms of practical things like ecosystem and popularity. I'm looking at the raw technology, and the model. I think there is a potential to harness incredible power on the server here the same way I've shown client-side performance with SolidJS. The kind of things that takes years to replicate.
I think I became aware of MarkoJS in early 2018 - but it seems to have been pretty quiet since then - hype wise at least.
Would it be an accurate guess that MarkoJS uses distinct but integrated rendering approaches on the server and client side?
The mainstream JS frameworks tend to have SSR "bolted on" after the fact by running a surrogate client environment on the server but it sounds like MarkoJS has a more phased approach:
Something to do with this, from Maybe you don’t need that SPA?
Yes, Marko's hybridness is part of its DNA. Marko started its life more like Jade/Pug with a light hydration layer. Marko 4 in 2017 brought the VDOM which was pretty late to the party, but it is largely since client rendering wasn't its focus.
The unique feature being a combination of separating out JS component code that doesn't need to be shipped to the client, and out of order streaming async content. This means it doesn't wait to render the static parts of the page rendering placeholders and then inserts the async rendered sections in the same stream via script tag insertion as it finishes. Both of these are hype new experimental features in popular frontend libraries and are getting names like Island's Architecture or Suspense, but Marko has been using these in production for years.
But addressing the elephant in the room. You are right there has been a dip in momentum. Patrick the creator of Marko moved on in late 2017 and that definitely affected its presence in the community. The team continued the effort of supporting eBay and has been working to modernize tooling but we definitely need to improve public transparency.
As for what I've been doing on the team, definitely. It's been a lot of designing, but we've been working on a new client runtime. As one would expect with reactivity and client profiling being my strong points. I'm comfortable saying the runtime will be significantly smaller, and client performance in a tier very few UI libraries have seen. This though only serves as a foundation for being able to achieve the type of partial hydration in the article. Still a lot more to be done, but it's definitely really interesting work given how ahead of the curve Marko is in certain areas, and where it is classically weak are my specialties.
Have you tried the "concise syntax" at all?
It is kinda like Pug(Jade).
Torn on this one. I used to love using Jade and CoffeeScript and Stylus, but white space matters less of my preference now. As a library writer the fact that we support this is really quite annoying. Marko actually allows concise and not concise mode in the same file. It limits syntax parsing potential which makes it harder for people no using concise mode. Maybe we will make this stricter in the future, but never want to hurt backwards compatibility. As the new guy though this is one of those things where I wasn't there and am just... Why?....
I totally missed the part that you work on Marko now.
Does this mean Solid is kill?
Not at all. These have opposite design philosophies and in many ways opposite strengths. I get the opportunity to explore both. I'm learning a ton and I find the situation very symbiotic.
Both deserve to exist the same way say React and Svelte do. This beneficial for both libraries as it gives insight that these approaches usually don't have from the other side.
Never heard of Marko.js! Will give it a try! Thanks for the introduction!
So there are must be so many javascript libraries for the 5th contender, but so far only Angular, React, Vue and Svelte who stands out.
It's not a popularity contest. One has to assume that MarkoJS exists because it's the best fit for eBay's particular use case - and because it's open sourced others can use it. Sometime before 2017 they moved from a more traditional Java-based web stack to MarkoJS to accelerate their iteration cycles.
What sets MarkoJS apart from current mainstream JS frameworks is that it evolves and extends the traditional server-rendering model rather than starting out with a client-side rendering approach.
For client-side rendering frameworks SSR is typically added after the fact (React -> Next.js, Vue.js -> Nuxt.js, Svelte -> Svelte Kit).
And unlike more recent server-side entries like Nest.js MarkoJS's rendering capabilties encompass both the server and client-side - with emphasis on server-side performance.
Current efforts seem to be geared towards reducing the client-side JS payload size and computational requirements - so that the resulting UX will still be acceptable even on (less than) modest client device hardware.
So MarkoJS isn't about "emulating native apps" but building commercial web applications that a company like eBay can benefit from. And there are likely lots of other use cases that could benefit from that as well.
A clean start for the web
The truth is that there is a full spectrum from the document to application web and I think that MarkoJS aims for the "highly interactive document" to "application with static parts" slice.
Given the possible range of use cases "one-framework" is just as unrealistic as one-language. Currently the industry's obsession with native-envy and "web application" glamour (vs. just a web site) seems to make React/Next.js the de facto standard regardless of the potential trade-offs (in TCO and UX).
And if it was a popularity contest ... then there is the vocal faction of developers who won't even look at MarkoJS because "it doesn't support TypeScript out of the box". Svelte had to deal with it - adding support this year. Only time will tell if that vocal faction is sufficiently large to make a noticable difference in adoption going forward.
"Marko extends the HTML language" while Svelte is "using a superset of HTML" and both seem to have a philosophy of investing in design time solutions to reduce runtime requirements (e.g. by using compilers). This trend seems a more natural direction for web technology to evolve along compared to anything else that has appeared since AngularJS in 2010.
Yeah so many. To be fair Svelte is still relatively new in the 4th spot. There was a time where Ember was established enough to even be uncontested 3rd spot. What I like about the popular libraries is that Angular, React, Svelte all have a clear identity so it is easy for people to choose between them. There has been clear narrative on the client side of things.
That being said what makes Marko particular interesting is it does things that none of those libraries do. There is some work in 3rd party space for sure, but Marko is built on it to the point it is optimized at the core level. I'm not going to say those features are necesary to make good sites and apps. But given the interest around things like Next, Gatsby, Nuxt, Nest, Sapper, etc.. its interesting when there is a mature library built on these constructs and not where they are patched on as an afterthought.
I'm considering marko for my hobby project. Do you know if there is vite or snowpack plugin for marko out there?
Not as of yet. Marko is heavily server-side and those projects have only added SSR support in the last few weeks. Before that Marko wouldn't really be leveraging the benefits. We (or someone interested) is going to have to spend some time there as Marko has decent amount of consideration around server solution since our automatic partial hydration needs to leverage the bundler to ensure we don't send unnecessary code to the browser.
SSR support in Vite and Snowpack is still in its early stages. They've been made with less sophisticated SSR solutions in mind. I've already made one PR against Snowpack but there is more work to be done. Honestly, I'd suggest starting to try Marko with the CLI for now.