Marko is faster and lighter. Also the syntax of single file components is more minimalistic than Vue, which is a good thing.
I'd say there is no interest because the single file components are quite new, and before that the project was focused on being a really fast templating engine.
We run marko in production. My favorite part about Marko is the automatic dependency management. If you already defined a `Modal` component, you can just use it in other components / pages by writing `<Modal />`. The JS files AND the CSS files will all get auto-bundled into your page.
Marko is also the only framework that supports server-side rendering streaming. This means that your user will start to see HTML even before the page has finished rendering. Afterwards, the page is bootstrapped and components run on the client side. It's very fast.
I've been using marko for ~1yr now and don't work for eBay.
1) It's a templating language, not JS, not ternary operators, etc. Where this really makes sense is the following (probably valid marko). I _dare_ you to rewrite this simple search-results component in your FE framework or programming language of choice. Note how "state" is transferred in to a component
.../components/my-component/index.marko
```
<await( results from component.resultsPromise(state.search) )>
<ul if( state.search && results.length > 0 )>
<li for( r in results )>
<!-- the "a href" will be prevented in a single-page context -->
<a
href="${component.getLink(r)}"
on-click('emitEvent_ResultClicked', r )
>${ r }</a>
</li>
</ul>
<ul else>
<li><i>no results</i></li>
</ul>
<await-placeholder>Loading...</await-placeholder>
<await-timeout>Timed Out!</await-timeout>
<await-error>Errored Out!</await-error>
</await>
```
2) It's like PHP (mostly the good parts) ... there's only one negative I currently have with marko and that's the deprecation of "<var />" or "<scope />", as with "really large templates" (already an anti-pattern), the lack of scope can cause variable shadowing.
3) you can break out into "just javascript" at any point ... `$ var xyz = 1 + 2 * component.functionAbc( 123 )` and then use ${ xyz } right after. I personally prefer having `scope...` in my arsenal so I don't accidentally re-use `var xyz` but it's really rare if you make small components and keep an eye on your refactoring.
4) It is _designed_ for both "virtual dom" + "HTML streaming" ... virtual dom is what helps diff trees efficiently (client side), but HTML streaming is the real genius. Given a relatively declarative template (which is what marko deals with), marko will actually take your "foo.marko" and literally compiles it into: "make_a_tree(...)" or "make_a_string(...)" which runs on client or server respectively.
Seriously.
```
$ mkdir foo && cd foo
$ marko create xyz
$ cd xyz
$ npm start
$ open http://127.0.0.1:8080/
```
Follow along with the docs / tutorial and then humor me and run the following:
I've used angular 1.x, ember 1.x, a touch of react, and I'm most hopeful for marko, as I really see a way for an SPA to start up using the smallest-possible-html-bootstrap, marko to download after first paint, attach handlers, etc. and be "as active" but "as quickly as possible" ... harkening back to the "good old days" of PHP and JSP where the content rendered quickly ... mixed in with the "good days of today" where subsequent page renders don't just blank out the browser, but instead, efficiently load up only the changed portions (ie: the SPA / single page app / progressive experience).
It's easy to do a "progressive" experience requires a 1MB download of JS before first paint. It's actually really cool to be able to render a 100kb page in only 100kb of network traffic, but also to have all your handlers / regular JS working from the remaining 900kb ready to work automatically _enhancing_ your page, but not to have to make any tradeoffs or think about it in order to do it.
And why are there no interest? Because it is from Ebay? I mean look at the reply and no one even want to touch on it.