DEV Community

Discussion on: A First Look at MarkoJS

Collapse
starptech profile image
Dustin Deus • Edited

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.

Thread Thread
ryansolid profile image
Ryan Carniato Author

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.renderBody or not props.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.