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.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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.