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
```
0 )>
${ r }
no results
Loading...
Timed Out!
Errored Out!
```
.../component/other-component/index.marko
```
```
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 "" or "", 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:
```
$ npm start
$ curl -s http://127.0.0.1:8080 | wc -c
5388
$ NODE_ENV=production npm start
$ curl -s http://127.0.0.1:8080 | wc -c
1678
```
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.