The way to keep it that way is to never add even 1 new feature and only fix bugs. That's not a bad idea actually; if you don't, it'll end up like every other framework on earth. So it's a good niche to say 'this is it' and keep it exactly like that even though it 'lacks features'.
Sorta like Backbone... People definitely love adding plugins and definitely don't count it as a negative when comparing to other JS MVC frameworks......
But this was built to solve problems the author was having at the time he/she created it. In the future, as the web evolves, those problems will change, and you're saying the framework shouldn't adapt to solve new problems?
I'm saying that's the only way to keep it from entering the inevitable malignant growth phase frameworks enter in after a bit because the author / community wants it to do everything. And we already have a ton of those, some popular, most not.
Looks very clean. Especially having just tried a read through the angular docs. Bleurgh. Take the advice of the others in this thread and avoid bloating this and maybe it will take off!
The tests don't make sense. jQuery is not an MVC framework and should not be tested as if it were. It's worth noting that both Backbone and Angular use some version of jQuery (lite or otherwise), so comparing that to your own way of using jQuery doesn't correlate. I could use jQuery to append elements in a way that was much faster than and just as short as what you've done in your test. Also, did you know you can append image elements with events using document.appendChild? It must be a security issue! But seriously, don't even include it in the tests. It is a JavaScript library that serves a lower-level purpose than MVC frameworks.
I would say that what node.js runs is ecmascript with it's own API that differs from the DOM. It's called javascript for convenience, but then what separates javascript from ecmascript?
Nothing. It is only different in name. Oracle owns the actual copyright on JavaScript via Sun. ECMAscript was used so the ECMA would not have to worry about this.
I guess this is a point of contention. Javascript is considered by many to be an implementation of ECMAscript that also provides additional features (the additional features, according to the book I cited, being the DOM and BOM).
DOM is separate from Ecmascript, but is actually one of the 3 components of Javascript (along with Ecmascript and the BOM). This is at least according to Professional Javascript for Web Developers (you can see it on 'page 3' in the Amazon preview).
I've become a huge fan of simple things. When I was just starting out developing software, I was a big fan of huge integrated solutions. But as the years went on I loved well scoped, lean options.
This is the reason why I like Backbone.JS instead of Angular. The reason why I like Go instead of Java.
Mithril looks really promising! Don't let feature creep turn it into a behemoth! Keep it lean and mean, and excel at the one thing it was made to do!
I think this is the same taste-maturation that many woodworkers experience. At first, you salivate over these crazy, overly specific, over engineered power tools. Over time, you start to really love things that are stupidly simple instead, like a card scraper, or a hand plane.
A few, simple, fresh ingredients prepared quickly and correctly can be much more amazing than a complicated 20 ingredient recipe that takes 2 hours to prepare.
It's the power and pleasure of understanding. It makes your mental model of the project a closer approximation of omniscience.
The cycle makes sense. A new programmer finds everything overwhelming, and the simplifications offered by something like Mithril often aren't enough to mitigate that feeling in any meaningful way. It's going to feel like you're drinking from a fire hydrant no matter what.
But as you get a much firmer grasp on the fundamentals, you also gain a much finer perception of bloat and cruft and what's necessary and what's not. So you feel a push to eliminate large all-encompassing libraries, because for the first time you realize that some sort of omniscience is within reach.
And how much net current/future amortized cost (time + maintenance + pain) / benefit there is between DIY & using "off-the-shelf" + learning/configuring/donkey-punching
Go vs Java? Choose the right tool depending on your experience with either and the goal of your project. They're really different beasts. Go (2007) focuses on concurrency, is relatively young, and is compiled to machine code for native speed. Java (1995) is object-oriented, has thousands of libraries, and runs on JVM. For the same project you probably won't consider both of them at the same time.
Backbone vs Angular? Backbone (without 10 other plugins) is just a small handful of prototypes so you will need to write huge parts of the actual application framework yourself (NIH syndrome). Not really comparable to a fullblown framework like Angular or Ember where you learn their workflow to take advantage of all the features and to save 'technical' time to write more 'business' logic. So again apples and oranges in this case until you mention Thorax and that kind.
Off-topic: how do you apply animation to your logo on activation of the browser tab? I loaded your page in a new tab, but the logo animation didn't fire until I viewed that specific tab.
The three rings are in a span. So it's content 'o' in span, the 'o' in :before and 'o' in :after.
Then he uses a -webkit-animation to translate the positions of each ring.
@keyframes logo {
from {opacity:0;transform:scale(2) rotate(359deg);}
to {opacity:1;transform:scale(1) rotate(0deg);}
}
@-webkit-keyframes logo {
from {opacity:0;-webkit-transform:scale(2) rotate(359deg);}
to {opacity:1;-webkit-transform:scale(1) rotate(0deg);}
}
I was actually wondering why this wouldn't just use React for the view. Then it could leverage all of the work going on with React (server-side rendering, possibly rendering from within a Web Worker, etc.)
Given the philosophy leo outlines, I'd guess he's going for something slimmer. This is 3k vs react's 29k. I am curious to know how it's achieving the same thing in so much less code, or rather, what react can do that mithril can't.
I don't see this as solving the same problems as React.
React is not "a templating language" that "uses a Virtual DOM", React is an implementation of _autonomous nestable components_, and that requires rerendering of HTML. Virtual DOM is just a way to achieve that rerendering better.
I don't mean this in a bad way, but do we really need another Javascript framework? Wouldn't author's energy be more useful when contributing to one of the existing ones?
Normally I'd agree, but I think this has compelling enough reason to be on it's own. The lightweight nature means it's only real competition is Backbone, which is more of a library for making a framework than a framework itself. But Mithril seems to do more while still managing to have a much lighter footprint and feel more like "just JavaScript".
That really depends on the author's motives. A lot can be learned by creating "yet another X". Not everyone thinks the same way and creating a framework from scratch gives the author an opportunity to get a deeper understanding for similar concepts and possibly a chance to invent a whole new approach. So many great things would not exist if everyone just settled to use or contribute to existing projects with similar goals to their own.
You're getting downvoted because this guy thought it was an interesting problem to think about, sat down and put some effort in, came up with something he liked (and which appears to be very good) and wanted other people to see it, and your input was, "isn't this a waste of time? People have done this before!"
The fact that frameworks are appearing at a ridiculous rate is also the reason people still feel compelled to make their own: the existing ones sometimes feel thrown together and flawed in obvious ways, so people automatically think about ways they could be better and try those things out. The result is progress (edit: sometimes the result is a bag of crap, but that's beside the point).
No, we don't need more frameworks. And yet that still isn't a good reason to stop building them, if for no other reason than to explore for yourself what goes into building one (if that's your interest).
Framework fatigue is understandable. Need? No. Want? Yes and maybe. Fortunately, no one's forced to use any one thing. That's because of the answer to your question: yes, no, and maybe. Do we really need another app? Another book? New languages? More music? Yet another program? People choosing their time and pursuits is what leads to countless dead-ends and countless progress. One might want to fear a day when the generality of a no displaces the spirit of a yes, about whether an activity is justified inherently.
That's the reason why I just shake my head every time I hear "HTML5 will overtake native for mobile apps anyday now".
They still fight over what is the best MVC framework and have no idea what native offers. When did you last saw Android or iOS dev worried which MVC framework should they use, or maybe write their own?
Well that's just silly. The native platforms already have the frameworks in place, and have done since the beginning. If you were writing a game in a native system you'd have to choose from different frameworks - or write your own.
With JS the restrictions and limitations of the system are different. People are coming up with creative and innovative ways to work with them. There's no problem with that, it a process that's ongoing in all software, and forever will be.
Also, "You" should really avoid using "They", especially when it applies to a broad group of people that you're making assumptions and judgements about. Maybe "You" have no idea what HTML5 apps offer (like portability)? I happen to think that html5 is going to be a major player in apps development, which puts me in your "They" camp, then again, I know what native offers - so I'm one of the many contradictions to your statement.
It's perfectly possible to not have FOUC with traditional template languages like mustache, and I don't think having "turing completeness" in your templates is a good thing. Frameworks like Ember.js have also shown that you don't need to manually write bindings to handle when your models change.
That being said, I do see the advantage gained with the virtual DOM you generate from the templates. I'd be interested to see if it was possible to integrate other templating languages in via plugin.
Entirely agreed, this is what I was about to say as well. Being able to use html templates for me makes apps much less confusing and much more organized. Moving your html into your javascript just doesn't seem right. If there was a way that it would accept a mustache/underscore/other precompiled template I'd be all about it. But constructing html out of javascript functions and objects just doesn't sit right with me.
I actually had the same thought, but I also get that some people don't like HTML-based templates for various reasons. My next thought was whether or not you could just augment this framework by providing a utility that converts an HTML-based template into the view that mithril expects and make both camps happy. As an optional contrib module, of course -- I'm not suggesting he start heaping on additional framework features already. :)
edit: I just wanted to add that I read through the guide expecting to find yet another half-baked framework but the whole thing seems well thought out and I like the philosophy alluded to in the guide. I'm definitely going to try this for my next mini-project.
Definitely, and there are other benefits in parallelizing the work stream if you have people that do layout and styling, but aren't necessarily up to constructing a page in a javascript framework.
But while me and my coworker have been trying it out there seem to be quite a few bugs with it, and I'd much rather have it done at runtime (precompiled for production build) then have to translate it from my HTML-based template every time I make a change.
Can you file an issue on Github? I still need to make an automated version of this tool (and eventually be able to import from something like Mustache), and I want to make sure it's rock solid.
Nice and simple like everyone said keep it lean. I really like the concise documentation and examples. I finally almost finished reading the code and get js mvc and thinking 'thats js mvc'. Good api.
The templating language reminds me a little of what spacebars (htmljs) probably looks like if a nice mustache facade wasn't put in front of it. (which goes back to Gee's comment about react... but I guess anything these days that promotes a 'virtual dom' will probably be tarnished with that brush from first glance)
I love the simplicity and independent direction this micro-framework provides. It's very 'non-magical' which I think makes it far more appealing.
If you end up solving the HATEOAS/ember-data sideloading/'embedded foreign key data loading' problem I think this will be my goto library (though this probably falls out of the microframework requirements also ;)
This actually fills a good niche, if i'm looking for a monolithic framework that trys to do a bunch of things, angular fits the bill. I like that this does one thing, and seems to do it exceedingly well (fast). I'm not in the market for a new framework right now, but the next time I am... i'd consider it, if it stays small and compact like it is today.
Hi lhorie, I like this. I want to use this. How long will this supported is my concern. Or is this a fun side hobby you worked on and plan on moving on to the next with no future updates?
Correct me if I'm wrong, but what this does is: 1) allows the code to be run in an environment where 'window' is not the global object (perhaps for testing), and 2) in a browser, gives the caller the option to isolate the module code so it's not allowed to touch 'window'.
Here are my thoughts, but you won't like them. Stop with the frameworks. Learn Javascript. Learn CSS. Learn HTML. You'll find pretty quickly that what you need are libraries, not frameworks. Things like jQuery, underscore, etc...
That's similar to my viewpoint. Stop with all the frameworks - what new, powerful functionality will it provide your users that existing things can't do (ie JQuery, raw JS)?
Faster development, potentially less bugs, conventions, etc. All of that is highly dependent on what your projects needs but I can't imagine writing some of the Ember apps I've worked on in just plain jQuery while maintaining a clean and readable code base.
You eventually end up writing your own framework of sorts anyway when you take minimal path.
the point of a framework is speedy development. less lines of code for results. the tradeoff is often bloat, which one should (ideally) refactor out later. Angular can get overwhelmingly slow if you're not careful with your code, but gosh dang, you sure can whip an app up pretty fast
For most apps, I've found that slowness is not a problem with Angular. You can do some nasty things though if you're not careful though, definitely agree with that. If you have flaws elsewhere in your codebase, including the backend, it may be possible that in practice, the effects may trickle down to your frontend code with Angular - it has happened in an app I've worked on with a couple of other developers, in which flaws with the api performance caused us to implement some subpar workarounds that triggered many $digests & forced us to spend a day or two on just optimization.
Angular can be quite fast compared to jQuery in an app of substance. It is not constantly reading/writing to the DOM in most cases, which saves a lot on the performance front. It is also a smaller library than jQuery, and you're not naively applying global or complicated selectors. Plugins rewritten to be pure javascript + Angular also can have a much smaller footprint & be more powerful to boot, such as the Angular UI Bootstrap project (5 KB minified & gzipped as opposed to 15-35 KB? I forget Bootstrap's js size) & contains all of the power of Angular to modify your functionality with them & more.
I don't like rewriting boilerplate code for every new project-- as I see it, Angular is to jQuery what jQuery is to raw JS, just in terms of reimplementing basic functions for the nth time.
Of course, if a framework automates a ton of functionality, it'll naturally be inappropriate for certain projects. I wouldn't try to use Angular for an HTML 5 game, for example, though there's a good chance I wouldn't use jQuery either.
> I wouldn't try to use Angular for an HTML 5 game, for example, though there's a good chance I wouldn't use jQuery either.
I actually did use Angular for an HTML5 game last week as part of a demo for a conference. Admittedly it was a really simple game (tic tac toe), and it did use Polymer as well as angular, as sort of an experiment. But it worked pretty well, and only took about a day and a half to hack together, with realtime multiplayer and chat using socket.io.
Obviously you're going to run into things that Angular is not really ideal for, but we are trying to make it do what it does very, very well, so in the future it should be suitable for pretty much any mobile or desktop app.
---
This sounds like evangelism, which is not my intent, you're absolutely right about what you're saying, but it's true, sometimes a framework works (and saves a ton of time) that you'd otherwise spend hacking together something awful. Hopefully this mithril thing also saves people a ton of time without them having to worry about numerous other issues.
That's sort of like the tone Microsoft took after releasing ie6. Landscapes change. Every single js framework in existence today will be unfit for purpose in 10 years. So we enhance the frameworks we have and try out new ones so in 10 years time we don't find ourselves stuck with tools that don't work anymore.
The problem is the shear volume of new frameworks. Writing your own framework has almost become a rite of passage for software developers. And I'm not knocking that. I did it myself. I learned a lot, the most important of which was that my framework was crap and that I didn't really need it at all.
>Stop with the frameworks. Learn Javascript. Learn CSS. Learn HTML.
That's good advice to someone that might be asking about using a framework. But to someone that has written a framework they probably have a pretty good understanding of Javascript already, and if they didn't it will have improved greatly by the time they are done.
The Stop with the frameworks idea still applies doesn't it?
I don't code in JS. Maybe a few lines once in a while when it pops up. It just seems like an MVC framework is the javascript equivalent of writing your first recursive factorial function.
A developer I worked with several companies ago told me the same type of thing about learning OO "Its not necessary just learn to code better".
The fact of the matter is large code bases need to be supported over time by diverse groups of people and frameworks help enforce standards that get people up to speed quickly.
That developer I knew, he has been chronically unemployed for the last 5 years because he lacks the skills to work as part of a team. Great coder though!
I second that. I have met a number of devs who are not idiots, have good analytical thinking, but refuse using frameworks, libraries, etc. The result is unmaintainable code base, which no one wants to maintain, and re-writing is too expensive so the business owner is, well, fucked.
The majority of the Web apps is CRUD + a bit of logic. It makes much more sense to use a framework because 1) most of the things are already there 2) easier to maintain for someone from outside 3) and, most importantly, very few developers have skills to create a nice, maintainable design, accompanied with a useful documentation.
Yes, in ideal world, maybe you should be able to stay framework-less (just made that word up) but the world isn't ideal. We have to sacrifice philosophical ideals for the business because that's what pays the living.
In rare cases, when the app is much more than a simple CRUD, it might make sense to ditch frameworks... But it's very, very rare.
Sorry, he's not a great coder. I think there is a big difference between saying "just learn to code better" and "use the right tool for the job" (which was the intent of my post).
I'll add an addendum to my post that frameworks can be the right tool for the job. But 99% of the time they're used the wrong way and for the wrong purpose.
Ehh I know Javascript, and know it well, along with HTML+CSS. My experience is that a very light framework can not only help structure things in a more sane way, but can provide a set of tools that make a mindset easier.
After building/using Composer.js (http://lyonbros.github.io/composer.js/) extensively I inevitably end up reimplementing parts of it on projects that don't use it because it makes some things so easy.
That said, if you're learning javascript, stay away from frameworks at all costs.
Ehh. As a developer, I find the best way to understand a concept is to sometimes implement it from scratch. Sometimes your implementation may just be for your own edification on how the patten (doesn't) works, other times it can be useful for others.
Sounds great until you have a team of 5 developers maintaining at least a semi-huge code base over the course of some years. Some people leave, new join the team.
Then you really start appreciating frameworks if only for their conventions to structure the code. Top coders can write web apps with jQuery and underscore alone, but everyone else is better off following some conventions.
HTML, css, JS (jquery) have stable APIs, when new developers come they don't have to learn something new.
If your code degrade over time, sorry to tell you, a framework won't solve the problem.
If you have coders that don't care about maintainability of code correction, code organization in whatever technology, they won't care about what you wish.
As usual, they won't take the time to learn the frameworks, will diverge, and you are back to square one with no code that can be salvaged or reused. (at least with vanilla techs you may salvage stuffs)
I think you use frameworks to solve the wrong problems here: you are probably the problem by trying to ditch the lack of real engineering skills in IT (not the letter of engineering. The spirit: making things that are correctly built and are reliable over time... like a plane).
Well I think we'll just have to disagree here. I think you are patently wrong if you really believe you can keep up maintainability of a largish codebase by appealing to craftmanship in a real-world company.
This is all nice and well in academics and start-ups but some years down the road, your code is going to be a mess. Frameworks, especially opinionated frameworks are a tremendous help. Coding in jQuery or native JS without some prodding is at best an accident waiting to happen.
In my experience, the only reason the code is going to be a mess is because the company hired a bunch of junior developers and gave them "Architect" titles. I can show time and time again that with a team of seasoned engineers the code not only isn't a mess but in fact there is less code that does more, and does it more efficiently.
Actually, this is kind of the spirit of Mithril. It's really a tiny collection of standalone useful functions that also happen to work well together. Ironically, your examples of "libraries" are both quite big in the context of the "lean learner" mentality, and in comparison to Mithril.
I am really interested in this, and am going to give it a go on my next project. Its areas of responsibility are contained and well-defined, the syntax is nicely concise, and it really feels like plain old javascript, which gives me the comfort I can get under the hood if I need to, without massive conceptual/abstraction overload.
If I am iffy on anything, it would be the templating language, but I suppose a React-type HTML syntax could be optionally layered over top without interfering with anything else. And there is something secure about javascript-rendered HTML in that you are much less likely to have unclosed tag issues, etc.
But for me, having experimented with some of the slower performers like angular, performance is a huge draw, and I am willing to write my templates in js if that's what it takes to get it.
The approach we've taken in our anti-framework is that the model is your data (and the code you use to manipulate the data), the view is your HTML/CSS (not a special templating language -- actual HTML), and the controller is automatic for simple stuff and custom for complex stuff.
So the big example at the end of Mithril would, for us, be something like (we implement binding as a jQuery extension)
$('.display').bind(data);
Where .display selects the root node of the bound UI, and data is our object.
Which is simpler and less code, I think. (Oh and our binding library has jQuery as a dependency, but is sub 3kB minified and gzipped.)
That said, we haven't put our libraries on github yet :-(
Ours is a fair bit more elegant and works both ways. It's also being used for multiple pretty complex projects so it's reasonably "battle-tested" (although nothing is in production yet, so not as battle-tested as it needs to be).
We also do not bind by class because that's a really bad idea. (Actually the way we bind is a lot like Angular, but without being a templating language.)
A key design requirement is that the model does not get polluted with special methods and properties to support the binding -- so (for example) if you have nice RESTful services, you can GET, bind, edit, POST/PUT and everything just works. For moderately complex cases we support "decorators" that live "off to the side" (i.e. do not pollute the model). Again, you can stick getters and setters in your model if you want to, you just don't need to.
Am I using code to do binding? Yes. Do we bind to HTML or something that -- after being parsed -- turns into HTML? HTML.
The advantages are significant. First -- you have to know HTML. Second -- all the code that works on HTML works on HTML.
We use data attributes to make the binding work. The data attributes are a "template language" if you will, but it's not breaking HTML (and if you read our attributes they make sense without much documentation).
No, if you're compiling at some point into HTML, then by definition, you're not writing HTML. HTML doesn't have functions in its spec (function m()) That's breaking HTML right there.
your "getting started" page is like a crash course in building websites with javascript - just forwarded it to a bunch of friends
it felt like you were giving a smart person a crash course in javascript
wish more apps sturctured their tutorials like this
great job!
One thing: it feels like it's aimed at people who are already competent at javascript
but your tutorial isn't too many steps away from a being solid "javascript for absolute beginners" guide
So would be cool if you made it slightly more beginner friendly, like I'm sure you're losing a lot of engagment and users because they read the first line of your guide and immediately think it's too complicated
"Mithril is a client-side Javascript MVC framework, i.e. it's a tool to make application code divided into a data layer (called "Model"), a UI layer (called View), and a glue layer (called Controller)"
Like I'd suggest adding a VERY simple sentence about why you'd want to use javascript AT ALL
both on the guide and the start page
like if someone landed on your page and they were good at HTML and css but never really programmed, they could probably use your framework to build their first programming project if you made it a little more beginner-friendly
166 comments
[ 3.3 ms ] story [ 219 ms ] threadLooks like Javascript IS the Assembly of the Web.
Javascript is a way to manipulate the DOM, no matter whan those nutters who run it on servers say.
This is the reason why I like Backbone.JS instead of Angular. The reason why I like Go instead of Java.
Mithril looks really promising! Don't let feature creep turn it into a behemoth! Keep it lean and mean, and excel at the one thing it was made to do!
A few, simple, fresh ingredients prepared quickly and correctly can be much more amazing than a complicated 20 ingredient recipe that takes 2 hours to prepare.
The cycle makes sense. A new programmer finds everything overwhelming, and the simplifications offered by something like Mithril often aren't enough to mitigate that feeling in any meaningful way. It's going to feel like you're drinking from a fire hydrant no matter what.
But as you get a much firmer grasp on the fundamentals, you also gain a much finer perception of bloat and cruft and what's necessary and what's not. So you feel a push to eliminate large all-encompassing libraries, because for the first time you realize that some sort of omniscience is within reach.
Backbone vs Angular? Backbone (without 10 other plugins) is just a small handful of prototypes so you will need to write huge parts of the actual application framework yourself (NIH syndrome). Not really comparable to a fullblown framework like Angular or Ember where you learn their workflow to take advantage of all the features and to save 'technical' time to write more 'business' logic. So again apples and oranges in this case until you mention Thorax and that kind.
Then he uses a -webkit-animation to translate the positions of each ring.
React is not "a templating language" that "uses a Virtual DOM", React is an implementation of _autonomous nestable components_, and that requires rerendering of HTML. Virtual DOM is just a way to achieve that rerendering better.
Obviously the author thinks so.
The fact that frameworks are appearing at a ridiculous rate is also the reason people still feel compelled to make their own: the existing ones sometimes feel thrown together and flawed in obvious ways, so people automatically think about ways they could be better and try those things out. The result is progress (edit: sometimes the result is a bag of crap, but that's beside the point).
No, we don't need more frameworks. And yet that still isn't a good reason to stop building them, if for no other reason than to explore for yourself what goes into building one (if that's your interest).
http://lhorie.github.io/mithril/comparison.html
With JS the restrictions and limitations of the system are different. People are coming up with creative and innovative ways to work with them. There's no problem with that, it a process that's ongoing in all software, and forever will be.
Also, "You" should really avoid using "They", especially when it applies to a broad group of people that you're making assumptions and judgements about. Maybe "You" have no idea what HTML5 apps offer (like portability)? I happen to think that html5 is going to be a major player in apps development, which puts me in your "They" camp, then again, I know what native offers - so I'm one of the many contradictions to your statement.
It's perfectly possible to not have FOUC with traditional template languages like mustache, and I don't think having "turing completeness" in your templates is a good thing. Frameworks like Ember.js have also shown that you don't need to manually write bindings to handle when your models change.
That being said, I do see the advantage gained with the virtual DOM you generate from the templates. I'd be interested to see if it was possible to integrate other templating languages in via plugin.
edit: I just wanted to add that I read through the guide expecting to find yet another half-baked framework but the whole thing seems well thought out and I like the philosophy alluded to in the guide. I'm definitely going to try this for my next mini-project.
So basically XAML?
But while me and my coworker have been trying it out there seem to be quite a few bugs with it, and I'd much rather have it done at runtime (precompiled for production build) then have to translate it from my HTML-based template every time I make a change.
I love the simplicity and independent direction this micro-framework provides. It's very 'non-magical' which I think makes it far more appealing.
If you end up solving the HATEOAS/ember-data sideloading/'embedded foreign key data loading' problem I think this will be my goto library (though this probably falls out of the microframework requirements also ;)
Cheers.
You eventually end up writing your own framework of sorts anyway when you take minimal path.
Angular can be quite fast compared to jQuery in an app of substance. It is not constantly reading/writing to the DOM in most cases, which saves a lot on the performance front. It is also a smaller library than jQuery, and you're not naively applying global or complicated selectors. Plugins rewritten to be pure javascript + Angular also can have a much smaller footprint & be more powerful to boot, such as the Angular UI Bootstrap project (5 KB minified & gzipped as opposed to 15-35 KB? I forget Bootstrap's js size) & contains all of the power of Angular to modify your functionality with them & more.
How do you refactor out bloat from a framework without throwing away the framework?
This is my whole point about not using frameworks. They're a siren that WILL eat you in the end.
Of course, if a framework automates a ton of functionality, it'll naturally be inappropriate for certain projects. I wouldn't try to use Angular for an HTML 5 game, for example, though there's a good chance I wouldn't use jQuery either.
I actually did use Angular for an HTML5 game last week as part of a demo for a conference. Admittedly it was a really simple game (tic tac toe), and it did use Polymer as well as angular, as sort of an experiment. But it worked pretty well, and only took about a day and a half to hack together, with realtime multiplayer and chat using socket.io.
Obviously you're going to run into things that Angular is not really ideal for, but we are trying to make it do what it does very, very well, so in the future it should be suitable for pretty much any mobile or desktop app.
---
This sounds like evangelism, which is not my intent, you're absolutely right about what you're saying, but it's true, sometimes a framework works (and saves a ton of time) that you'd otherwise spend hacking together something awful. Hopefully this mithril thing also saves people a ton of time without them having to worry about numerous other issues.
I don't code in JS. Maybe a few lines once in a while when it pops up. It just seems like an MVC framework is the javascript equivalent of writing your first recursive factorial function.
The fact of the matter is large code bases need to be supported over time by diverse groups of people and frameworks help enforce standards that get people up to speed quickly.
That developer I knew, he has been chronically unemployed for the last 5 years because he lacks the skills to work as part of a team. Great coder though!
The majority of the Web apps is CRUD + a bit of logic. It makes much more sense to use a framework because 1) most of the things are already there 2) easier to maintain for someone from outside 3) and, most importantly, very few developers have skills to create a nice, maintainable design, accompanied with a useful documentation.
Yes, in ideal world, maybe you should be able to stay framework-less (just made that word up) but the world isn't ideal. We have to sacrifice philosophical ideals for the business because that's what pays the living.
In rare cases, when the app is much more than a simple CRUD, it might make sense to ditch frameworks... But it's very, very rare.
I'll add an addendum to my post that frameworks can be the right tool for the job. But 99% of the time they're used the wrong way and for the wrong purpose.
After building/using Composer.js (http://lyonbros.github.io/composer.js/) extensively I inevitably end up reimplementing parts of it on projects that don't use it because it makes some things so easy.
That said, if you're learning javascript, stay away from frameworks at all costs.
Your view is limiting
>Things like jQuery, underscore, etc...
Sounds great until you have a team of 5 developers maintaining at least a semi-huge code base over the course of some years. Some people leave, new join the team.
Then you really start appreciating frameworks if only for their conventions to structure the code. Top coders can write web apps with jQuery and underscore alone, but everyone else is better off following some conventions.
If your code degrade over time, sorry to tell you, a framework won't solve the problem.
If you have coders that don't care about maintainability of code correction, code organization in whatever technology, they won't care about what you wish.
As usual, they won't take the time to learn the frameworks, will diverge, and you are back to square one with no code that can be salvaged or reused. (at least with vanilla techs you may salvage stuffs)
I think you use frameworks to solve the wrong problems here: you are probably the problem by trying to ditch the lack of real engineering skills in IT (not the letter of engineering. The spirit: making things that are correctly built and are reliable over time... like a plane).
This is all nice and well in academics and start-ups but some years down the road, your code is going to be a mess. Frameworks, especially opinionated frameworks are a tremendous help. Coding in jQuery or native JS without some prodding is at best an accident waiting to happen.
If I am iffy on anything, it would be the templating language, but I suppose a React-type HTML syntax could be optionally layered over top without interfering with anything else. And there is something secure about javascript-rendered HTML in that you are much less likely to have unclosed tag issues, etc.
But for me, having experimented with some of the slower performers like angular, performance is a huge draw, and I am willing to write my templates in js if that's what it takes to get it.
So the big example at the end of Mithril would, for us, be something like (we implement binding as a jQuery extension)
$('.display').bind(data);
Where .display selects the root node of the bound UI, and data is our object.
Which is simpler and less code, I think. (Oh and our binding library has jQuery as a dependency, but is sub 3kB minified and gzipped.)
That said, we haven't put our libraries on github yet :-(
http://beebole.com/pure/
We also do not bind by class because that's a really bad idea. (Actually the way we bind is a lot like Angular, but without being a templating language.)
A key design requirement is that the model does not get polluted with special methods and properties to support the binding -- so (for example) if you have nice RESTful services, you can GET, bind, edit, POST/PUT and everything just works. For moderately complex cases we support "decorators" that live "off to the side" (i.e. do not pollute the model). Again, you can stick getters and setters in your model if you want to, you just don't need to.
The advantages are significant. First -- you have to know HTML. Second -- all the code that works on HTML works on HTML.
We use data attributes to make the binding work. The data attributes are a "template language" if you will, but it's not breaking HTML (and if you read our attributes they make sense without much documentation).
it felt like you were giving a smart person a crash course in javascript
wish more apps sturctured their tutorials like this
great job!
One thing: it feels like it's aimed at people who are already competent at javascript
but your tutorial isn't too many steps away from a being solid "javascript for absolute beginners" guide
So would be cool if you made it slightly more beginner friendly, like I'm sure you're losing a lot of engagment and users because they read the first line of your guide and immediately think it's too complicated
"Mithril is a client-side Javascript MVC framework, i.e. it's a tool to make application code divided into a data layer (called "Model"), a UI layer (called View), and a glue layer (called Controller)"
Like I'd suggest adding a VERY simple sentence about why you'd want to use javascript AT ALL
both on the guide and the start page
like if someone landed on your page and they were good at HTML and css but never really programmed, they could probably use your framework to build their first programming project if you made it a little more beginner-friendly
great work! :)
use some punctuation and
not separate your thoughts out on different lines?
Not trying to be mean, this is just hard(er) to read!
astroturfing
AT ALL