In search of the perfect JavaScript framework

https://dev.opera.com/articles/perfect-javascript-framework/

by jsargiox • 11 years ago

195 79 11 years ago

dev.opera.com

carsongross4• 11 years ago

My theory is that, for much of the web, the perfect javascript framework is no javascript framework.

Get rid of all the abstraction, local state, dependency injection, symbol management and so on. Take HTML/HTTP seriously and think about REST in terms of HTML rather than JSON.

That's intercooler.js:

http://intercoolerjs.org

Here's an image I tweeted trying to explain how to get there mentally:

https://pbs.twimg.com/media/B9QNU-ZCQAECP-K.png:large

Yes, it's a simple model. And no, it doesn't work for every app. But many apps would be infinitely simpler and more usable in a browser by using this approach, and almost all apps have some part of them that would be simpler to implement using it.

talwai• 11 years ago

This, I like. I'm interested in seeing a progression towards client-side code assembled around libraries like intercooler.js rather than frameworks. I'd like to be able to pick and choose libraries to handle DI, routing, templating, HTTP et cetera in a manner that allows me to tweak/override as needed. I'm fine with foregoing the prescriptive structure that a framework like AngularJS lends to an app - structure is something you will spend time thinking about framework or not, and enough tools exist to let you write modular client-side code without being prescriptive

ahoge3• 11 years ago

"No framework"... so here is a framework. Uh hu.

Anyhow, move that "use strict;" line into the IIFE. If it's global, you can't merge that file with other files. Some of the code out there breaks in strict mode. That's why it isn't enabled by default.

carsongross4• 11 years ago

Well, it's a library, not a framework: you can use it for as much or as little of your app as you like with as little as a single attribute declaration doing something useful for you.

On "use strict", my understanding was that it applies per script:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Strict mode applies to entire scripts or to individual functions.

Am I misunderstanding?

failed_ideas• 11 years ago

I'll be honest, I'd be much more receptive to you doing a show hn over pimping the framework in the comments of every js post.

carsongross4• 11 years ago

Fair enough.

untog• 11 years ago

Get rid of all the abstraction, local state, dependency injection, symbol management and so on. Take HTML/HTTP seriously

You can't just say "remove local state and use HTTP instead" - people didn't invent local state from nowhere, it has a lot of advantages to relying on an HTTP call for everything you do. Particularly when you're scaling out widely or when you're dealing with mobile devices.

_asummers• 11 years ago

Or when dealing with some of the offline features of HTML5. Those are literally impossible to do without some local state.

weego• 11 years ago

The irony of suggesting a framework that abuses html attributes in templates to wire up massively abstracted behaviour as a response to someone tearing into the obsession of JavaScript devs with over-abstraction.

You do appear to be overly keen on pimping it, but it looks kinda unnecessary.

juliangregorian4• 11 years ago

It's not really abuse in an HTML5 paradigm, attributes are meant to be extensible and semantic.

logn• 11 years ago

You lost me at "That's intercooler.js"

nawitus• 11 years ago

How about using Web Components? They seem to solve most of the problems that JavaScript frameworks try to solve.

thirdsun• 11 years ago

As a developer that recently made the transition from FileMaker, which is very user-friendly but limiting, to Rails, I love the new possibilities and the fact that Rails provides nearly everything I need and comes with established best practices, but I'm always a little helpless when interactivity (without reloading the page) is required. The apps I'm working on (internal, business apps) mostly work perfectly fine with a document-based approach and most features can be integrated as simple CRUD actions, but from time to time I need just a little interactivity - like in a classic scenario of an order with several line items that needs to calculate and display totals in a form as soon as the input changes. It's that simple, no need for a framework, even most libraries feel overblown for that use case.

I looked at various data-binding javascript libraries, but they all seem like targeting much bigger problems than mine. So I resort to classic jquery, data attributes and ajax calls, but it feels very messy, like a hack not intended to work that way. It may be the fact that I'm new to this but it feels as if I'm missing something very obvious whenever I have to deal with that kind of very basic interactivity and dynamic. It's a simple form that temporarily needs to calculate and process inputs until the user saves the record and solving this seems way too complicated and messy. Are there any options for those simple cases and apps that otherwise would do just fine with a document-based architecture?

fastball• 11 years ago

I found that my experience with Dart seems to meet those criteria nicely.

https://www.dartlang.org/

rapind• 11 years ago

You might want to play with React and it's ilk. It's basically a framework for only the view, and it's pretty easy to reason about once you wrap your head around it. You're just asking for calculated fields on change events right?

jQuery is fine for this too, but can become painful to use and organize once you have a lot of DOM manipulations.

React only starts to get complicated once you dive into the Routing + Data Fetching + Flux stuff IMO. React on it's own if you don't need any of that is pretty simple.

lastofus• 11 years ago

I found Knockout to be a great middle ground for when "I can do this in jQuery, but it's gona be messy" and "I'm building a SPA".

It hits the sweet spot between easy learning curve, abstraction, and interacting with the DOM nicely.

Sadly, it's not as hip as React/Angular/Ember these days.

zak_mc_kracken• 11 years ago

Get rid of all the abstraction, local state, dependency injection, symbol management and so on. Take HTML/HTTP seriously and think about REST in terms of HTML rather than JSON.

So basically go back to writing Javascript like we were doing ten years ago?

No thanks.

I was there, it was hell, I hated every second of it.

The Javascript framework scene is very chaotic today but it's exciting, a lot of new concepts and approaches are being discovered on a weekly basis. A lot of them won't pan out but some will, and they will make writing Javascript even more fun than it is today.

And one thing I know for sure: it's hell of a lot more fun to write Javascript today than it was ten years ago.

padolsey• 11 years ago

I get your point but, for me, it was more fun back then. There was more to hack on; heck, you could craft your own selector engine and people would use it. Awesome. Now, seemingly, all there is to do is build yet another CRUD application with whatever framework is hottest.

beat• 11 years ago

It's a thought-provoking article, but I would also like to see something about React in it. It seems to me that React is a very pragmatic way to get around the global complexity-driven performance issues with DOM manipulation.

When we're coding, we're optimizing for a couple of different things, really. First is real-world performance (represented by slowpoke DOM manipulation). Second is programmer performance (represented by inappropriate abstractions). A lot of things we can do in Javascript to make programming less difficult and complex result in poor real-world performance, and vice versa.

But what do I know? I'm not by any stretch of the imagination a Javascript expert.

wwweston2• 11 years ago

Abstraction is dangerous

True statement. Of course, it's more or less true, depending on how much the abstraction you're using leaks. Few (if any) abstractions completely encapsulate complexity, almost all will leak. But there's a range. Some abstractions elegantly cover a modular portion of your problem space and do it so well you only rarely have to think about what's going on under the hood (and will even produce effective clues as to what's going wrong when something does go wrong). Some abstractions awkwardly cover only part of a modular portion of your problem space, require a high intellectual down payment to even start to use, have gotcha cases that chew up performance or even break things, and require continual attention to what's going on just to keep development going.

Most are probably in between.

I think this is what JWZ is talking about in his famous "now you have two problems" assessment of regular expressions. I don't read him as saying "regular expressions suck," I read him as saying anything but tools from the high end of the abstraction quality spectrum means now you have two problems: (1) the problem you started with (2) the problem of keeping the model/details of how the tool works in your head. Regular expressions are arguably in the (maybe high) middle of the spectrum -- they may not cover your case well (ahem, markup) and they can send your program's performance to hell or even halt it if you don't know what you're doing.

Now, they're also broadly useful enough in all kinds of development that the benefits go up with the costs and so they're probably worth investing in anyway, as part of a suite of other parsing tools/techniques. So I'm not bringing the topic up to bash them.

But to take us back to the topic, I might be bringing it up to question the ROI of popular JS frameworks, which, as far as I can tell, are generally not at the the high end of the abstraction quality spectrum, don't have the broad usefulness of regular expressions to recommend them, and may not even survive longer than a handful of years.

ef43• 11 years ago

No, it's not a true statement. It's fundamentally wrong. Because if abstraction is dangerous, we should all be laying out transistors by hand instead of writing code.

People get so comfortable with their familiar abstractions that they forget they're still abstractions.

Taking the article as an example, even his "less abstracted" examples are absurdly abstract, and I doubt anybody here can really say for sure how they work completely, underneath all the abstractions. That's a good thing, because it lets us get things done and express ideas in hardware-independent ways.

Bahamut• 11 years ago

Abstractions are dangerous - if you abstract wrong, your code is potentially worse than the unabstracted version since it is easy to impose an abstraction where there is none, but a poorly abstracted component is harder to correct.

drawkbox• 11 years ago

As long as your javascript framework is a micro framework and not a monolithic one, the abstraction does not make the project foggy.

Building the core and then using micro frameworks or components like react, jquery, etc leads to less walls as swapping is easier as time progresses.

You don't want to be caught high and dry stuck in years of monolithic to cleanup when the fad dies and at that point having abstracted away everything you need to know.

Outside of javascript, .NET WebForms and Drupal are classic examples of too much abstraction in monolithic fashion (those poor bastards stuck there - dead man walking), Angular might be another. The whole time you spent building addendums and machinations to a framework, not building the core of what needs to be known.

If the framework changes everything you do and abstracts core logic or the systems you are building doing things without you being aware, it might be easy to start 90% but there are gonna be problems and eventually walls and walls against you.

The only thing that should be monolithic and the base is programming languages and platforms. Everything else should be micro components or messaging.

danabramov4• 11 years ago

We want to apply values to variables and get the DOM updated. The popular two-way data binding should not be a feature, but a must-have core functionality.

Strongly disagree. I find one-way bindings and one-way data flow much easier to reason about. A little less boilerplate code is not worth mental overhead, cascading updates and hunting down the source of wrong data in my experience.

What is important is not updating the DOM from the code and instead describing it with a pure function. React, Cycle, Mithril, Mercury do it, and it's time we get used to this. This is the real timesaver, not two-way bindings.

`Object.observe` is the wrong way to approach this problem. If you own the data, why invent a complex approach to watch it, if you could update it in a centralized fashion in the first place? Here is a great presentation on that topic: http://markdalgleish.github.io/presentation-a-state-of-chang.... I strongly suggest you read it ("Space" to switch slides) if these ideas are still alien to you.

Even Angular is abandoning two-way bindings. http://victorsavkin.com/post/110170125256/change-detection-i...

I, for one, welcome our new immutable overlords.

joshontheweb• 11 years ago

Also, data bindings assume you are working with a DOM which isn't always the case. If you make a video game using canvas built-in data bindings just get in the way.

sombremesa• 11 years ago

Even when you are working with DOM, if you are on a device with limited capabilities (e.g. mobile devices), depending on the number of elements on the screen the bindings can cause the DOM to take a long time to render.

Normally not a huge issue, but it helps put AngularJS + Phonegap in an even worse position than before against native apps.

nilliams• 11 years ago

Yep the Ember team also seem to have come to the same conclusion on 2-way bindings.

My dumb takeaway is something like '2-way bindings demo well but are rarely what you actually want in real apps'.

I think (not 100% sure) Tom & Yehuda (of Ember) talk about how they became disenfranchised with 2-way bindings in their recent Changelog podcast episode on Ember 2 [1].

[1] http://thechangelog.com/131/

danabramov4• 11 years ago

I think marketing is also a problem here. Even frameworks that realize shortcomings of two-way bindings feel compelled to support them because it's hard to educate newcomers to abandon their old ways.

“Two” looks better than “one” on a feature checklist.

Quoting Sebastian Markbåge from React, “Angular is intuitively better to most engineers based on previous experience and ideals. React is better in practice. This is a biased opinion, but based one large org's experience of trying both models extensively.”

blktiger• 11 years ago

If I remember correctly, the Ember team isn't planning on abandoning two-way bindings. They simply want to give the developer control on when to use two-way bindings and they are going to make one-way bindings the default. That way you can decide if you need live updates or if data-flow control is better.

dustingetz• 11 years ago

While I have been using React since it launched in May 2013 and I agree with a lot of what you said, using words like "right" and "wrong" doesn't help. React is a great way to write applications but it isn't the most mature library ever, and the junior developers I worked with had quite a bit of trouble working with it for a while because functional programming is so different. The ecosystem is filling in, things are great, but "you are wrong and I am right" harms as much as it helps.

danabramov4• 11 years ago

Of course there isn't a “right” or “wrong” way. I'm sorry I didn't write it more clearly.

Approaches like jQuery soup or making SQL queries from PHP templates aren't “wrong” either. They are friendlier to beginner, too.

When I wrote “wrong” I meant “in my experience, inferior for building applications with complex stateful user interfaces and later maintaining them for a period more than several months in the face of changing requirements”.

Also, I'm not talking specifically about React. Of course it has its own shortcomings. All I'm saying is that relying on `Object.observe` and giving out global state to all components to mutate is the same as using global variables throughout the program. I don't know whether it is helpful to call global variables “right” or ”wrong” but I'd certainly stay away from them when there are ways to achieve the same without future maintenance nightmare.

wereHamster• 11 years ago

You don't need to understand functional programing to use React.

AdamCraven2• 11 years ago

It is a shame to conclude two way data-binding should be a casualty in the maturation of frameworks. Like one way data-binding, it can be misused.

Two-way data binding to properties is generally not good. It increases likelihood of problems as updates to one value have to be observed to adjust other values. It is easy for bugs to slip in and hard to reason about the code.

Two-way data binding to methods is better. Methods that aren't focused on setting one value. In effect not direct data binding. It creates easy to reason about explicit code paths for changing of values. Observation of the change of properties is no longer required.

It is a useful tool and should continue to be seen as such.

estava• 11 years ago

When I was creating a UI library, I tried to pick up on the trend of data-binding, but I found it difficult to use. Now these discussions remind me of it.

I don't even know how the second option is better to be honest. I may research it further.

:-)

danabramov4• 11 years ago

What is two-way binding to a method? Can you give me an example? I can only think of this[1] but despite being similar to two-way binding, this is one-way and explicit.

[1] http://facebook.github.io/react/docs/two-way-binding-helpers...

EGreg2• 11 years ago

What's with the immutability stuff?

Shouldn't updates just be event driven?

Is it really so hard for developers of parent components to subscribe to events of child components?

acjohnson55• 11 years ago

I would argue that a parent component listening to events on its child is an unnecessary level of indirection. The parent creates the child (or at least it should, in my opinion). The parent should just give the child the callbacks it wants directly.

I've become more or less convinced that over-reliance on events is a big anti-pattern. Combined with mutable state, you get a lot of difficult to track changes in state. Some describe it as COMEFROM-based programming, the dual of the much-maligned GOTO paradigm. The COMEFROMs are your listeners and event triggers are labels they reference. The downfalls of each are pretty much the same: code that becomes increasingly difficult to reason about as it scales, because you have arbitrary global movement in control flow. COMEFROM is even worse because it introduces concurrency. Concurrency + shared mutable state is a recipe for subtle bugs.

So much of the time in a web app, an event only really has one listener. In these cases, a simple callback passed to the child component suffices. But even when you might need to have more than one component react to an event in a child component, I would argue that whatever is responsible for creating the child should still pass a single callback, which might simply be an entry point to dispatch logic on a controller whose only job is to mediate that behavior. Said controller might use or something else as its mechanism.

acdlite• 11 years ago

Bad abstractions are dangerous. Good abstractions are empowering.

cough React Native cough

rhapsodyv• 11 years ago

I LOVE ExtJS!

djabatt• 11 years ago

Where does react.js fall in this discussion? Or does it? Just reading a lot about react.js this week.

mark_l_watson• 11 years ago

A difficult article to write - I would not have tried. There are so many good alternatives and choice depends on the application and available skill sets.

I spent time today working in Clojurescript which wraps the Closure library. In the last month I have used Ember.js, Clojure with hiccup, and meteor.js. I really like all of these tools and frameworks. I used to use GWT a lot, and almost committed to Dart. So many good choices.

akrymski• 11 years ago

One super simple framework is https://github.com/techlayer/espresso.js/

It's a bastard child of React and Backbone.

thekingshorses• 11 years ago

I like the direction author is going. I have used similar methodology designing my applications (for mobile), simple, micro libraries, one way data binding.

http://hn.premii.com/

http://reddit.premii.com/

* I have bunch of helper functions (UI and non-UI). Each function define in its own file and independent (easy to unit test). Personal library like jQuery but not a jQuery replacement.

* App is route based. One route to many controllers. Each controller is a page/screen on mobile.

* There is only one model (API) that interface with 3rd party library. API layer talks to 3rd party library to get data or gets data from server directly, caches data, etc. Provides sync (Cached data) and async (Cached data or fresh from server) interface to controllers.

* There is a app class or I call it a page manager. Responsible for managing pages like ordering, loading, unloading etc (Kind of big and complex 200+ lines of logic).

- Decides which page to animate in which direction on mobile (Loading new page or going back).

- Order of pages (Back button)

- Passes events to its controllers

- Decides which pages to keep in DOM, and which to remove.

--- If you go from homepage to comments to profile page, all pages are in DOM.

--- When you go back to comments page from profile page, profile page will be destroyed and controller will be notified. Same happens when you go from comments to home page.

--- If you go to same comments page again, it will be loaded as a new page.

* Controller:

- Each controller may have multiple CSS and templates

- Controller uses its template to render

- Using sync API to get data to renders page.

- If sync API returns no data, renders empty page with loading, and makes async API call.

- Controller are idle when transitioning (animating) from one page to another on mobile. (Very important for smooth animation)

- Simple but fat controllers

- Controller handles events, UI logic

- Self cleaning so that browser can collect garbage when necessary

I package app using node/gulp. Anything that is not specific to page/app related, it becomes part of a helper library. Each app has its own model (Data layer), and controllers. I use micro templates, precompile using node for faster performance.

rorykoehein• 11 years ago

I use hn.premii.com all the time. One of the best mobile web apps I have used. Any chance of open sourcing it? Would love to see how you solved some of these problems in detail.

mercer2• 11 years ago

Thanks for creating hn.premii.com! About half my use of Hacker News is through your web app. I even wrote a little bookmarklet that turns all links on hn.algolia.com and hckrnews.com into links to your app when I happen to be browsing on mobile! And I'm always happy to find out you introduced a new feature (which I would like to see more regularly, not that I'm complaining!).

Alongside Alien Blue, your app is my most used app on my phone. Your work is very appreciated!

closetnerd• 11 years ago

This article reminds me quite a bit about Vuejs. Its got an interface similar to Backbone but with the addition of two way data binding while also allowing you to define web components style tags, attributes.

hippich• 11 years ago

I yet to find "perfect" JS framework. I bet, it will never happen.

Nevertheless, I have a favor to ask any framework developer out there - please, make it disassemblable and usable piece by piece outside of framework.

OP was right - sometimes i find some aspect of framework nice, but more often than not it is monolith part of the whole framework, which as a whole I dislike.

ps: current combination it seems to fit my mind workflow is Backbone (models + collections) + Ractive.js (Views) + Machina.js (for routing and defining "controllers"/states.) Although I am looking to use something else besides Machina.js in next project, as I want to have hierarchy now. And since it is all loosely coupled, I can replace parts.

jbeja• 11 years ago

The perfect JS framework won't exist until 2079.

ef43• 11 years ago

"Abstraction is dangerous"

The fact that Javascript people keep saying this with a straight face is getting really absurd.

You do realize Javascript is also just an abstraction, right? And that the browsers that run it also abstractions, and the operating systems, and the kernels, and even the hardware itself has multiple layers of abstraction?

"Abstraction is dangerous" is just fundamentally wrong. Abstraction is the only way we get anything done.

What you really mean to say is that bad abstractions are bad. But stated so clearly, it becomes obvious that it's a tautology. Well-designed abstractions that leak as little as possible are essential to everything we do.

This stuff matters, because instead of having stupid arguments over "how much" abstraction we want (which really boils down to 99 layers vs 100 layers) we should be debating exactly what abstractions we want.

juliangregorian4• 11 years ago

"Black boxes are dangerous" is maybe a more precise way of expressing the concept. I don't think the author literally believes you must be writing machine code.

ef43• 11 years ago

If black boxes are dangerous then you really should be writing machine code. Which is absurd of course, and demonstrates that black boxes are a very good thing.

Javascript itself is a black box. It would totally suck if you had to know how it's implemented inside to use it.

s_kilk• 11 years ago

Black boxes {are|should be} a good thing.

"Leaky Black Boxes" however (like angular), are awful.

I quite like having a black box with two sockets on it, that I can plug cables into and have it just do whatever it's supposed to.

However, if the sockets are a weird shape, or there 39 of them, or they leak a strange green ooze, then I get upset.

clay_to_n• 11 years ago

I only read the beginning few sections of the article, but it seems like it IS about "what abstractions are good", as opposed to "abstraction is bad". He's recommending abstractions that let you understand what's REALLY happening, so that you can reason about performance better.

_pmf_• 11 years ago

> "Abstraction is dangerous" The fact that Javascript people keep saying this with a straight face is getting really absurd.

I stopped expecting anything of value in the article after reading this in the introduction, too.

wwweston2• 11 years ago

Looks like someone things "dangerous" and "useful" are mutually exclusive. See also electricity, automobiles, consuming food, etc. No one is saying "don't use abstraction ever."

Maybe this metaphor will help:

"Using other people’s code is like surfing. You control and surrender. You’ve got to trust the wave to carry you, but stop paying attention, and the first abstraction leak will throw you under the water."

https://medium.com/@dan_abramov/youre-missing-the-point-of-r...

Sure, you could say "bad abstractions are bad." And it's true there's a spectrum. Some are much less leaky than others, of course, some have the boundaries of what they do and their interface outside more elegantly shaped than others. But saying "well, we just don't want bad abstractions" doesn't capture well the fact that all abstractions either leak to some degree or are awkward coverings for some problem domains.

Nor does it really get us where we want to go in terms of "exactly what abstractions we want." We want useful ones. We want minimally dangerous ones. And the way you get the latter is to understand how abstractions are dangerous.

itsbits• 11 years ago

I don't agree with DOM event handling: setting events at every node comes with a cost. And I think you forgot to mention the performance issues with that approach and so now a days almost all frameworks prefer to event delegation.

I think author except in 1,2 points didn't bother to take side with performance aspects.

mperret• 11 years ago

I like the structure of google closure, thoughts?

jcoffland• 11 years ago

Vue.js meets most if not all the criteria outlined in this article. I've been have great luck with vue.js after a nightmare of fighting with writing a big SPA in Angular.

iEchoic• 11 years ago

The Knockout example in this article is a bit strange - Knockout is not a framework (it is explicit about this) - but besides that, Knockout components actually do allow the "framework" to decide when things are instantiated.

RehnoLindeque• 11 years ago

We all like simple tools. Complexity kills. It makes our work difficult and gives us much steeper learning curve. Programmers need to know how things work. Otherwise, they feel insecure. If we work with a complex system, then we have a big gap between “I am using it” and “I know how it works”.

One answer to this problem of opaqueness in abstractions is having a well defined denotational semantics. This makes it clear that something can work in one way & only one way (without the need to dive into library internals). I feel that Elm is doing a pretty good job of tackling this for GUIs and signals.

mathgeek• 11 years ago

I was slightly disappointed that this didn't point to a 404.

tel• 11 years ago

The whole "abstraction is dangerous" spiel is so wrong (imo) that I don't even know how to respond to anything that follows.

The primary complaint appears to be that abstraction eliminates your ability to operationally trace the meaning of a program. This is true, but sacrificing operational denotations only hurts if you replace it with nothing else—and abstractions of general purpose languages are almost always more interpretable than the operational denotation of the base language itself!

Of course, there are always places for poor abstractions. I am not talking about these. Abstractions which are intentionally opaque, have confusing action-at-a-distance, etc---you're bringing down the name of abstraction in general. "Leaky" is insufficiently demeaning.

A good abstraction will have its own semantics. These can be equational, denotational, operational, what-have-you but, essentially, these semantics must be easier/simpler/more relevant than the semantics of the base language they're embedded in. Otherwise why abstract?

So what does React give you? It gives you, more or less, a value-based compositional semantics. Components have some "living" nature (an operational semantics w.r.t. to state) but they're mostly defined by their static nature. Because you can build whole applications thinking only about the static, compositional nature of components you can take massive advantage of this abstraction.

Ultimately, you do not want operational semantics for React. This is what gives us React Native, background rendering, and probably what will lead to sensible animations (in time). To define operational semantics, especially ones which have to look like or (worse) be identical to those of Javascript, would destroy almost all possibility of extension. At the cost of making things more complex and harder to reason about.

All so that you can just stick to "obvious" Javascript base operations.

fiatjaf• 11 years ago

I don't think people use frameworks and abstractions because they have a smoothier learning curve, or because they are simpler, but because of DRY. After repeating the same pattern twice, the programmer turns it into a module and abstracts it. After having a lot of modules, the programmer packages them all in a framework. This is good for the author of those modules and the framework, because he understand them, but not always for the outsider who just looks at the complete framework and don't know what's inside.

In search of the perfect JavaScript framework

Related Stories