As some of you know I joined the Marko team at eBay a year ago. And for many the immediate question was "What is Marko?" Well it's a JavaScript framework like React or Vue, built specifically to handle the high performance needs of eBay's platform.
Performance through server rendering has been critical since day one, as eBay is an eCommerce platform and lost milliseconds means lost revenue. And there are many platforms with the same requirements but eBay made a pretty bold move in the 2012 when they decided to move to full-stack JavaScript for such a platform with using Node on the backend.
The first thing they realized were the existing tools weren't going to solve the problem. So Marko was created with exactly this in mind. But that was years ago and we are seeing other frameworks like React and Astro starting to adopt some of techniques Marko uses. So what has Marko been working on?
Unique Origins
Marko was really built with only 2 main things in mind. It needed to have progressive server rendering. We need to have the page on the client as soon as possible without waiting for Async but we need to support SEO.
And we needed to ship the least possible JavaScript to the browser to support all sorts of devices around the world. The way to do that is through Partial Hydration. Or only sending the JavaScript to the browser for the small parts of the page that were actually interactive.
And Marko did both of those in 2014. The real secret of these two features is that they work together amazingly well. If you are streaming your page as it loads but that content is mostly static and can be eliminated from the client JavaScript you send to the browser, you can get fully dynamic page loads with skeleton placeholders with 0kb of JavaScript bundle sizes.
That is immediate rendering with content progressively loading in without pulling in the big framework bundles. Nothing else does that today. But a few libraries are looking at doing parts of it.
Maybe the best way to picture this for those up to date on the latest tech, is picture if you wrote an app with HTML based template language and used a compiler like Svelte to automatically generate Astro-like Islands out of only the code that needs to run in the browser, and it's all served to you using something like the upcoming React 18's Suspense for SSR.
Yep. 2014. Sure things were a bit more manual than they are today, but the core pieces were there. This is a great start to a story but then the difficulty sets in.
Growing Pains
How do you possibly achieve such futuristic development in 2014? Well you pretty much need to write your own Parser, Compiler, and Bundler. It wasn't enough to handle the templates but in order to package things differently for the server you need a bundler. So the team created Lasso. The idea with Lasso was to compile and serve templates on demand instead of upfront. This way dev server startup times could be fast and incremental rebuilds were possible.
This was important as Marko being one of the earliest library with truly isomorphic development, where the same templates worked on server and browser, needed to coordinate multiple builds on code changes. Honestly it wasn't until Snowpack 3 or Vite 2 that there was a true successor.
So supporting the growth and tooling around Marko was definitely the focus for the next couple years. Partial Hydration got smarter, and architecture was streamlined. The next groundbreaking release was Marko 4 in 2017 where Marko starting to be conscious of browser performance opted into using a Virtual DOM to handle client rendering.
However, the world had changed in those 3 years. Things like React and Webpack had sprung up, and most importantly Babel. The trend had become transpiling JavaScript to support modern features before the browsers did. Marko was maintaining its full end to end tool chain and was quickly being left in the dust.
The migration to Marko 4 was also a big effort at eBay as well. Internally Marko had its roots as early as 2012 and you can imagine even with automated migration scripts there were challenges. To put it in perspective for React devs that time span bridges the gap before React existed in Open Source, through the createClass days, to ES6 classes and almost to Hooks.
The Marko team now only 2 people, simultaneous supported migrating the eBay platform written mostly on Marko and upgrading the tooling around Marko to be more modern. This included the move to Babel, replacing Lasso with other bundlers that didn't quite fill the gap, support for Testing Library, Jest and Storybook. The majority of this work happened over 2018-2019 and would become Marko 5.
FLUURT
The project, codenamed FLUURT, was an idea that had been floating around really since the release of Marko 4 but there had been no time to pursue it. FLUURT is an acronym that Michael Rawlings had come up with that stood for Fast Lean Unified Update & Render Target.
The concept is that with sufficient knowledge from compiler analysis it would be possible to produce the optimal code for any target platform. Whether that be server, browser, mobile, or even a different JS Framework.
This is really 2-part effort. There is the method and language for analysis, and then there is the compilation and runtime to support it. Both are immensely difficult challenges.
The first carries with it all the stigma and DX concerns with understanding how languages function. I've written about it in Marko: Designing a UI Language. Some people will not be happy with it but Marko's new Tags API is like a marriage between something like React's Hooks and Svelte's $: syntax. It has all the compiled magic without losing any of the composability.
Composability is king. But so is clear analyzable syntax. Blending both is key incidentally to achieving the granularity that we want for code elimination in the browser for Partial Hydration. We really needed to go component-less not only as a technology but as a language. Luckily this aligns with Marko's earliest goal of being a superset of HTML. Writing and maintaining code should be as easy as working with HTML templates.
The second part has been quite the undertaking. Marko has already conquered Server rendering. Even though Marko might have the most efficient Partial Hydration of all JavaScript frameworks today, having worked with it at eBay scale for years, we know we can do a lot better.
Generating the suitable client side approach has been a bit of trial and error. There are many considerations and details. From the ability remove even more static code from the browser to handling of Async consistency and transitions that needed to be ironed out.
Experimentation
The team had developed out their first approach before I joined the team. It was a top down reconciler similar to a single pass VDOM, like you might find in libraries like uhtml or Lit. However, it didn't let us leverage Hydration as effectively as we would have liked. Granularity was going to be the key here especially with the goal of being able to truly only send the necessary JavaScript to the browser. Ultimately, this led to me getting recruited for the job.
The second approach was a runtime reactive approach with precompiled dependencies. This reduced the overhead of subscriptions and got performance in Inferno-like range in the browser. Static dependencies, while saving us from having to run computations to determine dependencies like other runtime reactive libraries (MobX, Vue, Solid), required the dependencies to be reactive variables themselves. This led to over-wrapping of expressions and used up more memory. It also still put considerable weight on template boundaries.
We spent most of the fall on the 2nd attempt before shifting our focus on releasing Marko 5 and related tooling like Vite and universal Hot Module Replacement. However this effort wasn't without value. We had used it to develop 2 key new features for the Marko compiler.
First, we added an analysis pass that gather's metadata about all your Marko files so that as the compiler transforms the code we can make informed decisions based on the contents of child templates that are imported. Secondly, we pulled the core parts of the bundler into Marko's compiler so that we have a generic solution to handling code elimination for automatic Partial Hydration. While this lets it be bundler agnostic, more importantly, it gives us the ability to do wider sweeping changes on the final output.
The Solution
Coming back refreshed Michael realized we could compile away the reactivity without the limitations of local compilation. We had already built the pieces we needed and the answer ironically is the simplest one we had to date.
What if the compiler could split a template into multiple exports that were tree-shakable, around the different inputs(props) they accepted. A parent could decide, based on the statefulness of its own data it was passing, which exports it needs to import. And then through the use of shared scope and inlined calls of those imported methods you could effectively compile away all reactivity but keep a granular update model.
This doesn't have the problems of the compiled reactivity as you aren't making signals or computations anymore but passing the data as is with simple dirty checks. If that sounds familiar, it should. It's basically how Svelte works on a localized scope, except Marko's version transcends files.
What's next?
Well, we still aren't done yet. We have working prototypes and preliminary benchmarks. We feel we've finally found the approach suitable for Marko. This is an incredible step forward for compiled JavaScript framework design. But there is still more work to do. So we've decided to take a different tact.
We will be releasing Marko's Tag API, in Marko 5 ahead of the release of the new compiler and runtime. We can leverage Marko's cross template analysis to give the minimum feature set so that you can get started with the new features and syntax.
Together with Marko's already powerful Partial Hydration and Streaming Server rendering we can deliver on the developer experience. This will also give a good opportunity for feedback. We've been working tirelessly long behind closed doors and we need to do better at making our efforts visible.
We now are tracking our projects more visibly on Github and intend to give more regular updates. We will follow that in the fall with the beta release of the next version of Marko. Sometimes good things take a long time. But it will be well worth the wait.
Top comments (17)
In our country (China), SSR is too slow, because HTTP requests are too slow. All large companies in our country are self-developed two thread framework, similar to React Native. They do not request network resources, but update offline packages when they enter app.
Yeah this is a very unique perspective at least compared to what is being pedalled in the west. We've been told that the way to make headway on slow networks and low powered devices is ship less JavaScript not make larger bundles that offload future interaction. These messages seem really in conflict with each other and I'd love to hear more.
Both MPA and SPA architectures can leverage Service Workers and PWA for offline and cached browsing but only MPAs have the ability to ship considerably less JavaScript since they don't need to render full pages on the client on navigation.
I would like to read post about that. Do you have any good links or maybe you want to write one?
One possible architecture is presented in
Building a multi-page PWA
Article: Beyond SPAs: alternative architectures for your PWA
SO PWA live demo
SO PWA GitHub project
The repo has been updated from using plain JavaScript Template literals to rendering with lit-html and lit-html-server.
These days I'd look at µhtml + µhtml-ssr (and perhaps JSX2TAG if jsx support is desired).
Using template based rendering seems the logical choice here as it should be easier to optimize on the server as it isn't burdened with spinning up an entire component framework just to render the HTML for a single page.
The demo has the ServiceWorker serve primarily from the Cache while updating the cache in the background. However the application could just as easily render from data stored and managed in IndexedDB (perhaps via a sqlite-worker).
That said with this architecture you'll have a substantial download hit on the first request as the entire app downloads itself after the first (server side) page has been rendered - and the application has to carefully elide parts of the pages that are preferrably absent rather than stale. But at least this setup can make use of multiple (perhaps slow) cores on the client device. Also while the ServiceWorker is a promising technology, it isn't without it's problems.
Marko fits an entirely different use case. The page(s) need to always show up-to-date information on render (stock levels, pricing, etc.) and perform well even on casual engagement (i.e. perform as much work as possible on the server while not delaying client rendering, delivering later content asynchronously or via stream without necessarily committing to building a separate HTTP-API).
In many ways as certain legacy server-side stacks look to be updated it could be more effective to adopt Marko rather than building a separate React frontend and hiding the entire server-side capability behind an HTTP-API.
I'm more interested in China view. I know what west have to say about that
The MiniApp seems to be popular in China but relies on a native host app.
Mini app components
Mini app standardization
Other mini app runtime environments
Mini app open source projects
Project structure, lifecycle, and bundling
Programming the mini app way
Applying the mini app programming principles to an example project
Concluding thoughts about mini apps from a web developer
In 2017 Ele.me (an online food delivery service platform) seems to have converted to a Vue based MPA PWA.
Yes, Miniapp is our main architecture. I am an architect. I have developed a dedicated miniapp architecture for our company(ctrip.com).
I've shared too many articles about the dual threaded framework in China. If you don't mind using the translation function, you can read this article: zhuanlan.zhihu.com/p/373958625
Our country's large companies are using similar architecture, there are many open source projects:
github.com/ctripcorp/wean
gitee.com/openharmony/ace_engine_lite
github.com/openkraken/kraken
github.com/NervJS/taro
I'm an expert in this field, but the architecture behind it is quite complicated. It's similar to React Native(or Flutter), so it's hard to explain.
Thanks. I will take a look
Thanks for sharing, that was very interesting! It's amazing such advanced things happily existed in pre-React era. While reading I had a feeling that Marko could take place of React or Svelte, but — if I understood you correctly — it didn't. What's the main reason in your opinion? Or, maybe, is it just luck or coincidence?
Rich Harris, author of Svelte asked me the same question.
I think what we have was an engineer driven project that never really got pushed. To this day where Marko gets the most respect is from other Framework authors. They understand what has been built here. It was never marketed really. And there was some bad timing.
Marko was coming with a solution that no one in 2014 was looking for and didn't realize it could capitalize on a whole market that didn't realize it was exactly what they were missing. When it came up people weren't looking for building their static sites on JavaScript, and Marko didn't fit the mold for JavaScript frameworks at the time. Anything not Single Page was seen as regressive.
I was in that boat myself. I saw Marko and was like.. is this like Jade/Pug? Why would I not use client side routing. And the truth was for me Marko wasn't the right choice. And the same was true of many making these interactive apps in JavaScript.
But then something changed. At some point we hit the inflection point. Some sort of critical mass where everyone wanted to build in these tools and were branching beyond SPAs. We started seeing server rendering and frameworks like Next and Gatsby. And they just used all the tooling that had been built for React. Rise of JAMstack and maybe that was the point where Marko should have stepped in. I mean compared to those solutions especially in those days.. It's no comparison.
But it also coincided with the exact time the original creator moved on from the project and eBay and the team went from 4 to 2. Evangelism stopped and as I highlighted in the article a lot turned inward. And the evangelism being done focused on the incredible technology which I feel is probably an audience mismatch when the people to benefit most from Marko are those just building simple sites and especially eCommerce.
Marko might be the perfect solution for that crowd. But marketing makes up such a big part. Svelte's marketing was very effective and managed to cut in to a space that looked closed off. But even it's a bit late to the table. React dictates the conversation. We are here right now because people are talking about progressive rendering again because of React 18.
This project could have easily died, and for that I am looking at the positives. Marko is still in its current state an incredible technology for building isomorphic sites and we continue to set the bar high with what is coming. So while there isn't anything to be done about the past, we are going to keep working on some amazing things.
For what it is worth I looked at Marko at the same time as I looked at React and... I did not get it. Admittedly that was maybe 7-8 years ago when Marko did not use a vDOM, and the message was oriented about speed (direct DOM updates!). That may be the only point I got then. Can't really remember much more.
I would not say that Svelte's promotion was good. I am not even sure there was something you can call the promotion of Svelte. I just got to know it because I was a big fan of Ractive and I was a big fan of Ractive because... it had a terrific website that was the nicest of all the other frameworks (documentation, concepts explanation, everything was just crystal clear for the novice that I was then). It was a blast so I picked up Svelte immediately when it went out. Same docs quality, appealing syntax choices, reactive model just clicked etc. I don't see Svelte popularity as a result of deliberate marketing but very simply as a result of good design choices. People get it because it is designed for people to get it -- fast: not much new to learn, terrific docs, feels like just javascript even when it is not... And all of that in my mind is due to Rich Harris being more than a multi-skilled programmer. I believe that programmers with two or three skills bring more to the table. In the case of Rich, I hypothesize that working in a newsroom forced him to to have empathy with non-programmers that still need to get a page up quickly. That means good communication and didactic skills, and a lot of pragmatism (Ractive had double binding at a time when most of the frameworks were going away from it). Ractive never focused on the speed of the code, but on the speed of the developer (onboarding + producing). Ractive tag is "web apps made simple". In a newsroom you don't do too much long-lived apps, you have a few days to write a story with some captivating infographics, and then you move on and hardly come back to it (the story isn't gonna change). So Ractive website had a ton of graphics, and clear story telling because that's what you need to succeed in a newsroom. Svelte only improved on that. Whatever "marketing" there is today is the unprompted effort of the folks who loved it. (Interestingly enough, and not seeking to discourage anybody but the folks who took over Ractive I think actually did away with a good part of Ractive attractiveness - at least to me... That is the difference people make).
React is a different story. There is a team of people and a ton of budget invested in supporting the external communication. They also suffered somewhat from the departure of the early folks, they had a serious problem when Facebook decided to change the licensing but they went through that. They did well in terms of community handling even with the initial communication mistakes around hooks. They are learning and improving constantly which is nice to see even if I disapprove of the recent directions they took. But ultimately they have all that because React picked up for the simplicity of vdom = f(state). Otherwise they would have been deemphasized like Flow or React Native or several other projects at Facebook. Success brings success.
Microsoft, which is a consumer software company and is about the best you can find when it comes to proper marketing and open source management. The quality of its documentation, developer support, and tooling is constant across the board. A real turnaround for the bad days of the browser wars.
All those examples are to say that unless you have a proper marketing company behind you for which open source is strategic, success needs to come from the community of believers. They need to be preached to, and there need to be a clear message, value proposition, and differentiating point. The way I understand Marko now is that it is the framework for e-commerce. Proof -> eBay use it. The rest are technical details. The bottom line is you get the money-generating speed that you need in scalable e-commerce apps (did I mention eBay?). It is Next.js for e-commerce. Next.js recently added an e-commerce product, and they can do that because Marko has not occupied that space when it has a very credible story for it. And Next is doing it because it has huge incentives to do so (VCs breathing in the neck), which Marko does not (2-3 folks doing what they want and can). In fact, if Marko was to become successful for e-commerce I wonder if eBay would let possible competitors use part of their secret sauce.
Well ok that is just some musings. Hope it is somewhat useful in your reflections. Just thought out a tagline: webapps at e-commerce speed.
Yeah Marko never knew how to present itself. Even to this date it has been strangely difficult to explain the use case from a technical stance. And I agree that has largely been due to focusing on it from a technology standpoint, something that probably didn't matter with the suitable audience. I think you are right about the argument/tagline. It also suggests that any head to head should be with things like Next, rather than focusing on core technology of say React.
I think a lot of people never really heard of Svelte until Svelte 3. I suppose if you were there from the start it might have seemed different. But around release time the message was simple: VDOM is pure overhead, Disappearing Framework, the Candyman of JavaScript framework benchmarks. Rich's amazing communication skills present in his talks and videos definitely shone through but that was the narrative. He's given some of my favorite all time talks.
And all directly from his mouth. That is why I consider it marketing because it was deliberate and successful. And all those messages have since disappeared into the ether in an official sense. Svelte has many merits as you outlined. And I agree about origins. It's really obvious Svelte was designed with small apps/demos in mind. Just it isn't hard to find people who will tell you to this day that VDOM is pure overhead, or that Svelte compiles away the framework with no runtime. But the message is much better now.
Still I spend more time correcting Svelte myths than even React. I probably should thank Rich for that too since he successfully cracked through React's myths. From what I've seen you don't get to dispute the mythos only replace it. And that is incredibly hard. It goes beyond "believers" to enter the overall consciousness. And that is where Svelte has succeeded in a way hard to believe in this relatively jaded post-javascript fatigue time.
Some things to consider:
Pure Speculation:
I suppose during 2013 and beyond there was an enormous push to implement applications in the browser (native envy) especially as the Web was still primarily consumed via desktop computers - maintaining the appeal of the completely client-side rendered SPA concept. SSR was an afterthought only addressed by Next,js in late 2016.
Marko at the time focused largely on server side rendering with streaming and asynchronous rendering support - rather than a move towards client-side SPA. So at the time it didn't satisfy the predominating "shiny object syndrome" even though it was extending the reach of the server into the client - which could be advantageous in a market where the web is more frequently consumed from low-spec client devices.
Yeah that marketing I suspect is spearheaded by Angular and potentially some classic SSR solutions like Rails which see React's new interest on the server as threatening. There are meta-frameworks that are gaining increasingly more popularity like Next.js built on React which might be lending to this as well a tiny bit. Marketing solutions to reduce complexity seems to be the latest trend here.
But yes I agree. Redux got oversold initially, beyond what its creators or maintainers ever wanted, and React's dominance is so propagated into this frontend culture it isn't even that it's popular anymore. But that people feel if they aren't working in it their career isn't growing. I've heard the term Resume Driven Development thrown around. Senior devs rarely care about these sort of things but it is a real concern for junior/intermediate level developers since it does really lend to job prospects. It matters to hiring managers since it's easier to find candidates. Really a vicious cycle.
Marko is good in areas React is not. I don't even see this as a head to head sort of thing. It only works that way if you view all web sites/apps as having the same requirements. I have a much steeper climb vs React with my other library Solid. Marko is just really good at a certain niche. That niche just happens to be most Content Sites/Blogs/eCommerce. We're fine leaving Web Apps to React for the most part.
Been hearing you talk about fluurt since last year, been wondering when we'd start seeing something on that. The wait is killing me.
I know. And hopefully this fills in some of the gaps of what has been going on. We've needed to re-examine our approach a few times now.
I think we're making the sane approach of splitting the language from the runtime. If our language truly independent of runtime, like our goal states, porting it to Marko 5's VDOM should be as doable as Marko 6(Fluurt)'s compile away reactivity.
So Marko 5's support of the language will come first which we expect to have an announcement about soon.