When comparing Mithril vs Polymer, the Slant community recommends Mithril for most people. In the question“What are the best client-side JavaScript MV* frameworks?”Mithril is ranked 7th while Polymer is ranked 12th. The most important reason people chose Mithril is:

Most other frameworks either offer a huge API to deal with model and view synchronization, or defer to other libraries & plugins to cater for relatively simple use cases. Mithril's API is tiny but complete. The natural reaction is to assume something is missing, but as you build you realise you incredibly fast, powerful and rich applications can be built using nothing but Mithril.

Pros

Pro

Small, easy to learn API

Most other frameworks either offer a huge API to deal with model and view synchronization, or defer to other libraries & plugins to cater for relatively simple use cases. Mithril's API is tiny but complete. The natural reaction is to assume something is missing, but as you build you realise you incredibly fast, powerful and rich applications can be built using nothing but Mithril.

Pro

Fast rendering

Mithril's loading times are very fast. This is because it's templates are compiled first and then served to the browser and because it uses a virtual DOM. The virtual DOM is a virtual tree containing all the nodes of the real DOM, every time anything changes in the virtual DOM, Mithril does not re-render the entire (real) DOM, instead it just searches and applies the differences.

Pro

No need to learn another syntax to write views

Most MVC frameworks use HTML templates to render their views. They are good and useful because they are easy to read and understand. But they add more complication to an app because it's practically a new language and syntax that needs to be learned.

Mithril argues that separating markup from logic is just a separation of technologies and not concerns, so you can write Mithril views in JavaScript. Writing them in JavaScript also makes it easier to debug them (HTML templates can't be debugged).

Pro

Familiar to people used to MVC

Doesn't lock you into any complicated conventions or structures, only one function is required to create either a Controller or a View. You're free to implement your architecture exactly as you want, so you can focus on the purpose of MVC, making connections between computer data and stuff in the end user's head.

Pro

Small size

Weights just 8Kb gzipped and has no dependencies. A reactive stream module can be added for one extra Kb.

Pro

Great documentation

Mithril has a large and expansive documentation despite it's relatively small API. Mithril's GitHub repo has more documentation than actual source code. None of that documentation is auto-generated

Pro

Does not force you into a predefined structure

Mithril's API is pretty small compared to other frameworks. It forces developers to solve problems in JavaScript rather than in Mithril. Other frameworks with massive APIs force you to think in a way that suits the framework. Mithril doesn't do that.

Pro

Allows you to choose which JavaScript libraries to integrate in your project

Mithril gives to the developer the flexibility to chose the best JavaScript library to use for a specific task.A huge framework like Angular instead forces you to use their API, which does not necessarily evolve as fast as the JavaScript ecosystem. Therefore you may end up in case when you are stuck using an API which is just not the best in terms of performance

Pro

Allows a smooth transition from other UI frameworks

One thing you need to start using Mithril is just a DOM node. With Mithril a developer is able to introduce the library step by step.

Pro

Can be used without build systems

It's plain old JavaScript, can be used without webpack, gulp or grunt, just include it into your HTML and start writing your app.

Pro

Based on web components

Web Components are a collection of specifications released by W3C as a way to reduce the complexity of web apps by creating reusable components. Browser support is currently poor for web components, however Polymer is developed to make web components compatible with modern browsers.

Pro

Various basic components

It provides a base component.

Pro

HTML markup is not string

HTML markup as it can be a non-string.

Pro

CSS is easy to apply

CSS can be applied far more comfortably than React.

Pro

Flex layout components

It provides Flex layout components.

Pro

Excellent documentation

Polymer guides you as with tools (cli, build environment, app templates,..) as with complimentary documentation on all phases of app development from creation of app as progresive web app to production deployment instructions.

As Polymer is standards based, the whole community around those standards also helping in documentation and support.

Pro

Complete web app stack support

In addition to waste set of mature web components in Polymer Elements along with Vaadin Elements there are thousands of web components in the wild comparable to jQuery plugins set.

Pro

API is easy to understand, based on standard

The Polymer APIs are split on application layers and follow standards on all possible ways: Web Components, CSS variables, async API via Promises and so on.

Pro

Excellent routing

The router is embedded into CLI for project creation and covers as web as Progressive web app, also fused with Polymer layouts out of the box. The shop template for CLI has a complete solution including the routing.

Pro

No need for special debugging tools

The presence od specialized debugging tools are advertised by competitors. The all features of web components are natively supported by browser embedded development tools.

Cons

Con

Small API can make it unsuitable for larger more complex projects

Mithril's small API and small number of functions while helpful for small projects and applications where speed is needed, can add another layer of complexity in larger more complex applications where a more extensive API is needed out of the box.

Con

No server-side rendering

Polymer does not support server-side rendering. This results in higher loading times, more HTTP requests and it's not very SEO friendly, since search engines have no way of indexing a page if it's not rendered in the server.