From f8b6dfa1b00ff5f049b323b31e48f62096f263ce Mon Sep 17 00:00:00 2001 From: Leo Horie Date: Thu, 20 Mar 2014 12:54:06 -0400 Subject: [PATCH] fix typos in docs --- archive/v0.1/comparison.html | 6 +++--- archive/v0.1/mithril.min.zip | Bin 19855 -> 19855 bytes 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/archive/v0.1/comparison.html b/archive/v0.1/comparison.html index 44ad8f78..e9ec66b8 100644 --- a/archive/v0.1/comparison.html +++ b/archive/v0.1/comparison.html @@ -62,10 +62,10 @@

In terms of architecture, one of Mithril's main differences is that it does not provide base classes to extend from.

It's often said that frameworks, in contrast to libraries, dictate how code should be written. In this sense, one could argue that Mithril isn't really a framework.

Instead of locking developers down to very specific implementations of design patterns, Mithril's approach is to provide an idiomatic pattern to follow, and tools to aid the developer when required. This approach means that developers can get discoverable codebases without necessarily getting locked into the framework.

-

One related difference is that other frameworks often hard-coded base classes where every conceivable convenience method are inherited by the developer's classes (remember, in Javascript, this can mean copying all of the utility methods over to the child class, regardless of whether they're going to be used or now).

+

One related difference is that other frameworks often have hard-coded base classes where every conceivable convenience method gets inherited by the developer's classes (remember, in Javascript, this can mean copying all of the utility methods over to the child class, regardless of whether they're going to be used or not).

Mithril's on-demand tooling approach means there are no hidden performance costs when implementing core MVC patterns, and there's also no extra learning curve for framework-specific syntax for those patterns.

View Layer Paradigm

-

Some of the older frameworks among the popular ones (out-of-the-box jQuery and Backbone, specifically) take a more procedural paradigm when it comes to the view layer: this means every action requires the developer to write custom view-level code to handle it.

+

Some of the older frameworks among the popular ones (out-of-the-box jQuery and Backbone, specifically) take a more procedural paradigm when it comes to the view layer; this means every action requires the developer to write custom view-level code to handle it.

This can get noticeably bulky when you look at thing like collections: you often need to implement insertion code and deletion code, in addition to a "draw everything" routine for performance. And this is for every list that needs to be displayed in some way.

Mithril's view layer paradigm is designed be declarative, much like HTML, such that the same code implicitly does everything it needs to. As it turns out, this design decision is actually a compromise: it offers the benefit of decreased application code complexity at the cost of some performance loss. However, as the performance tests in the homepage show, this does not necessarily hurt Mithril in a meaningful way.

@@ -82,7 +82,7 @@

Another marking difference is that Backbone is workflow agnostic, that is, there's no one idiomatic way to organize applications. This is good for framework adoption, but not necessarily ideal for team scalability and codebase discoverability.

In contrast, Mithril encourages that applications be developed using the patterns found throughout this guide. This discourages "bastardized" MVC pattern variations and architecturing style fragmentation.

One technical aspect that is also different is that Backbone is heavily event-oriented. Mithril, on the other hand, purposely avoids the observer pattern in an attempt to abolish "come-from hell", i.e. a class of debugging problems where you don't know what triggers some code because of a long chain of events triggering other events.

-

A particularly nasty instance of this problem that sometimes occurs in "real-time" applications is when event triggering chains become circular due to a conditional statement bug, casuing infinite loops and browser crashes.

+

A particularly nasty instance of this problem that sometimes occurs in "real-time" applications is when event triggering chains become circular due to a conditional statement bug, causing infinite loops and browser crashes.

Another significant difference between Backbone and Mithril is in their approach to familiarity: Backbone appeals to people familiar w/ jQuery; Mithril is designed to be familiar to people with server-side MVC framework experience.

Angular

Angular is an MVC framework maintained by Google, and it provides a declarative view layer and an emphasis on testability. It leverages developer experience with server-side MVC frameworks, and in many ways, is very similar in scope to Mithril.

diff --git a/archive/v0.1/mithril.min.zip b/archive/v0.1/mithril.min.zip index 5b915f8b0bf09dec1f623167e6737e1025ee2dc6..76218c580c9c5ec72ab5c4af39cb4f0c6f01b6f4 100644 GIT binary patch delta 41 tcmeC5&DcMikvqVfnT3l11a@xZ){$l0x!FSYiaz7c$-KVSK+@CK4FKUF3!DG| delta 41 tcmeC5&DcMikvqVfnT3l11Y$OF>&P<3Y_^cSqR$vJnb+4ENP7CZ0RYSn3Mc>o