psteeleidem

In another comment I mention that the biggest conceptual improvement that Marko offers is async and streaming rendering. Async changes how you think about passing data to your view (you start rendering immediately and you can retrieve backend data asynchronously to start rendering parts of the page asynchronously). Also, Marko is not tightly coupled to a VDOM (while React is) and because Marko is not tightly coupled to VDOM rendering we can achieve significantly better performance (sometimes over an oder magnitude faster than React on the server) and this absolutely can make a difference. The slowness of React (and the sync rendering) were huge blockers from the very beginning when we considered using React at eBay. --Marko author

Web components do not have a great story about passing complex data. If you want to pass typed data (not just strings) then declarative HTML suffers since HTML parses all attribute values as strings. You can use JavaScript properties to provide typed data to Web component custom elements, but properties cannot be provided declaratively in HTML and now you have two ways of providing data. With that said, I think there is value in building UI components in Marko and offering web component custom elements as one option for embedding your Marko-based UI component into a page (using a small UI bridge layer... something that we plan on open sourcing). --Marko author

Async and streaming rendering is probably the biggest conceptual difference since it changes how you think about providing data to your view (in a good way). The paradigms of how you build UI components is very similar across all of the major UI libraries, but Marko aims to reduce boilerplate and offers what I think to be a superior syntax. --Marko author

Building web apps is definitely hard work, but it can be fun if you are instantly rewarded with working components/pages that didn't require a ton of code :)

There's really no magic with implicit imports. The imports are resolved at compile-time and fully resolved imports are used in the compiled code. I see developers making mistakes with explicit imports all the time (using the wrong path or forgetting to change the variable name or moving a component to a new directory and forgetting to update all relative paths).

Webpack aliases are a Webpack-only feature that I would consider a bad practice since it relies on globally configured aliases. Implicit imports in Marko are resolved relative to the template file (not global). Marko can be used server-side under Node.js with no need for a JavaScript bundler.

> I like Vue's idea of separation computed/methods/data blocks more than mixing all together. It for example helps the green devs to better understand the framework's lifecycle/internals and separation of concern ideas.

I see separation of computed/methods/data as unnecessary boilerplate. Methods are just functions on the component definition. On a related note, In Marko there's no need for "computed" properties and there is no need for a "data" block.

You don't need a virtual DOM or real DOM on the server to render HTML. The fastest way to render pages on the server is to compile templates into JavaScript programs that produce an HTML string (not virutal DOM nodes and definitely not real DOM nodes) and you can use almost any HTML templating engine to do client+server side rendering. morphdom is only meant for use in the browser when you need to update the DOM based on new HTML/DOM nodes.

Here's the notable differences based on my understanding after looking over the docs and the source code:

- morphdom does diffing between two real DOM trees while incremental-dom does diffing between virtual DOM nodes and real DOM nodes - incremental-dom is only meant to be used with templates that compile to use incremental-dom (won't work with templates that render to HTML strings) - morphdom can be used with any templating engine that produces an HTML string (or real DOM nodes) - With additional improvements, morphdom could be used to do diffing between a real DOM tree and a virtual DOM tree as long as the virtual DOM nodes are upgraded to real DOM nodes if they need to be added to the final real DOM. In addition, the virtual DOM nodes would need to have an API that overlaps with the API of real DOM nodes.

Also, it appears that incremental-dom doesn't reuse DOM nodes that move to a new parent, but I could be mistaken. Hopefully someone more familiar with incremental-dom will chime in.

On the following note:

> it should become faster whenever browser DOMs become faster

The killer feature of React is that it made it possible to efficiently rerender the entire UI and for developers to not have to write code to manually manipulate the DOM. I hope browser vendors take note of this and do more to support this use case. Ideally, morphdom should not even exist and we could instead have the browser natively do the job of diffing/patching the DOM. Admittedly, there would have to be a lot of details to work out, but React, virtual-dom and morphdom are working in the right direction. Behind the scenes, the implementation might change and any good UI framework should make this a non-breaking change.

For the record, I got an email from Hacker News asking me to repost it since they thought it was a good story and it did not get many views. It's not wise to post something to Hacker News late on a Friday :)