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 fra...
For further actions, you may consider blocking this person and/or reporting abuse
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.