EmberJS Confuses Me
wekeroad.com
wekeroad.com
As far as I attempted to implement it in my app (https://github.com/thomasboyt/noted-app), it seemed simple enough. Models were data; all they contained was their properties and operations that controlled their properties.
I mainly used controllers as the "state" for parts of my app. In Ember, this doesn't even need to mean it's tied to a specific model type. For example, my Dropbox integration is handled within a controller that's bound to several separate views (in this case, those views included buttons that triggered syncing and modals that displayed the progress of syncing). There's no "Dropbox model," just other models that I'm using this controller to sync. Controllers are not simply an intermediary between models and views, they are an intermediary between state and views.
> I'm trying my best to reconcile this with the notion that a controller (classically speaking) is supposed to ... well control the view. Here, it's not doing that.
I think what the author was looking for in controllers is what's actually handled by, well, views. The view handles any user interaction, and then uses the controller to change the state of various bits (whether calling methods in the controller or simply updating properties on it).
To sum up: model is data, controller is state (including instance(s) of models), and the view is user interaction. Templates can bind to properties on any of these. Routes are what hook these components together depending on the page.
>Most of your controllers will be very small. Unlike other frameworks, where the state of your application is spread amongst many controllers, in Ember.js, we encapsulate that state in the router. This allows your controllers to be lightweight and focused on one thing.
"Application state", rather than "stateful vs stateless" state. The router specifies "I'm looking at a post now" and the controller specifies "Looking at a post means loading this particular Post model as well as these comment models"
As an example you could have a web application that has multiple documents and inside each document there are panels that can be expanded and collapsed. As you switch between documents each document maintains its own version of which panels are expanded or collapsed.
In the Ember world the router would maintain which document was opened (addressable state) and the DocumentController would maintain which panels are opened (non-addressable state).
Nah, kidding. So they're totally right that there's a significant amount of state in the router, in that that's where you define which model and controller (and, depending on how fancy you get, what views and templates) to use on a given page. So those are essentially state.
The state that can make a controller fat is essentially state that's too important for a view but doesn't need to be universal to the page. For example, with my Dropbox controller, the controller has a state property that handles the various permutations of the state of syncing (i.e. it could be doing nothing, currently saving, done saving, failed saving, etc.). This state is set by the controller on the controller, and used by multiple views to determine things like which label a progress modal should have.
For example, if you had a controller representing a list, you might want to keep track of which item is selected on the controller. That way, if there are multiple views that can act on the currently selected item (for example - you might have a list item view that has a template that renders the item, and then a separate view that are buttons that trigger actions that act on the current item), they all have access to it.
Plus, I always think of state defined in a router as being limited to specific pages/routes, whereas some of my controllers are used on several different routes.
Ember is explicitly not about "desktop apps". That's actually why Ember broke off from Sproutcore. Ember is very opinionatedly focused on building web applications that are native to the web and stick to web conventions.
The best web applications still behave like the web is supposed to behave: they have shareable, bookmarkable URLs that allow the application's state to be recreated. This is a big reason Ember's router is different than the other examples you mentioned -- in Ember the router automatically handles a lot more of the state reconstruction stuff.
They say as much in their guides as well.
That's orthogonal to what I'm talking about. I agree that their use of the term "MVC" is much closer to the original meaning it had on the desktop (like in Cocoa) than the meaning in server-side frameworks like Rails.
But I'm not talking about what MVC means. I'm talking about what kind of applications Ember is intended to be used to build.
A flagship example would be Discourse, which is very deeply web-focused, and nothing like the way you would structure a desktop application.
These apps are built on the web. One look at the Discourse Ember code and I think you'll understand perfectly the confusion I'm writing about.
But I'm curious: do you use Ember or are your responses "what you think"
While we're being pedantic, it's Model 2, not MVC2: http://en.wikipedia.org/wiki/Model_2
I decided to try Emberjs - not for any other reason than trying to pick up something else and see how other JS framework approaches.
I gave full two-days worth of time into it. Initially I thought - "How different can it get?" Plus, I believe even if it's very foreign I'll just keep reading, googling, stackoverflowin', youtube-tutorialin' to get my head around.
I gave up though. Here's my hopefully constructive rant, though my views are probably not as deep as the OP's.
* Many of the posts on the net are outdated. I followed a few tutorials here and there, and then things didn't work, so I asked on Stackoverflow, then the answer I got was "Dude, your code is outdated". Sure this is probably similar thing for other frameworks - but I'm just sayin'
* Models - So there is Ember Object, which you can use as models, but you can also use Ember-data.js which is more "glorified" data. Documentation wasn't clear on the difference. Plus, Ember-data.js was quite hard to get started with. It didn't work well with other versions of Emberjs. I really had to dig in to find the right one to start off with. I ended up cloning a github repo of a tutorial that worked, because nothing else did.
* Documentation on "convention over configuration" - OK, so convention over conf. is fine. But the official documentation and many of the tutorials didn't explain what all the conventions there were. I went through a tutorial app, which only had Controller, but things just "worked", because the Emberjs builds all other things for you. Well I didn't know that! THE BEST INTRO EMBERJS VIDEO I found was this.
It finally made sense in the end for me.
* But in the end, among all other things I wanted to do, I gave up, because the frustration was mounting up. I guess I can still persist through it. But I just finished AngularJS tutorial demo and in 2 hours, it makes sense to me.
Ember Data is a completely optional component of Ember that seeks to bring ORM-like abilities to the client side. It's not as far along or as stable as core Ember. For what it's worth, you can easily just use jQuery.ajax and create Ember.Objects from the response. We probably do need better documentation in this area to make this clear. That said, it's not fair to count Ember Data as a point against Ember since no other framework has anything at all similar in scope.
Our overview documentation is lacking. This is something that we're actively working on improving. The hardest part for new developers coming to Ember is that the paradigms are very different than what they're used to. We believe that the paradigms are the correct ones, but we need to do a better job explaining them.
Yes it's optional, and yes you can use jQuery.ajax or whatever, but in reality, it's not quite that simple.
The official guides in Ember default to assuming you're using Ember-Data (though they do at least mention it explicitly). This despite Ember-Data being far from production ready (as stated on the Github page) and far too slow for dealing with large quantities of data. At the same time, the conventions that are found in Ember-Data appear to be built in to core Ember (it says as much in the guides).
As far as Ember-Data not counting against Ember - it may be larger in scope than other client side data libraries (or the M part of other MVC frameworks or whatever) but the fact is that they are most definitely comparable, as it's the way that Ember gets stuff off the server, and saves it back to the server. Without Ember-Data, Ember has no built in way of doing that, which counts against it. With Ember-Data, well, it's not really ready yet, which also counts against it.
I also highly recommend watching one of the follow talks about Ember Data: http://www.youtube.com/watch?v=_6yMxU-_ARs or http://www.youtube.com/watch?v=V8nnE948zxk. Both talks make it very clear that Ember Data is not at all comparable to what is offerred by other frameworks.
Btw, is there a diagram or something that shows how it's put together internally (I'm pretty comfortable with how to use it from an API perspective, but find myself having to dive into the source code fairly regularly)?
But, I really really think for a newbie (like me) to even find out that I can use jQuery.ajax to create Ember.Objects is confusing. The immediate questions following that would be
* How do I do that? Can I see an example? And where do I find a counter-example? * Then why Ember Object (ok fine they provide cool ORM features, but when I'm starting, I just want to understand what/where things are)
I know a lot of people are raving about Emberjs, and personally it looks good and I really want to get into it, but really really really, I found it not-newbie friendly.
Creating an object instance with AJAX is as simple as just calling `create` with the data provided in the callback. However, you may want to create the object first, then update the object's properties in the AJAX callback. This is similar to how Ember Data handles things.
Also, `Ember.Object` has nothing to do with ORM. Ember Data addresses this with `DS.Model`.
If there's a specific case you feel like we've missed in the guides, we'd love to have you file an issue about it at https://github.com/emberjs/website/issues.
I went through the same thing grandparent post did - a lot of old tutorials. I think it would be a good idea for Ember to make a complete break and to call this 1.0 release something else.
So whatever code samples are out there on blogs and SO were from the initial days of the API when it was changing a lot. I am with you and have been going through the pain of weeding out examples from the web that works with the latest version on GitHub. There were many methods that weren't even available in the current API.
Given the paradigm shifts with Router and the Controller, maybe what the Ember team needs to do now is to stop doing everything else and finish up on the documentation for their 1.0.0-rc.1 release before it is finalized to 1.0.0
It looks like instead of the controller pushing data to the view, the view asks the controller for data (which it might proxy to the model).
This makes sense with a long-running controller, right? On the web both the controller and view are ephemeral -- they last for just that one request -- but if the controller is running continuously then it needs to reflect changes in the models as they happen. The model(s) the controller references can change without the view changing its reference to the controller.
Without something like this the view would render stale data. I'm assuming this is why we have a controller.model, to add that layer of indirection.
What am I missing? How is this more complicated making the controller<->view relationship pull instead of push?
The view asks the controller for data. The controller might delegate that question to the model. The view shouldn't care whether the data was delegated or not; it should just get a response from the controller.
Seems like textbook object-oriented design. Otherwise how will the views update automatically when the models change? The views shouldn't know what models it needs. In fact, it seems they shouldn't know that models are a thing at all. It's just data from the controller.
A view calling controller.model.property is MORE tightly coupled than controller.property. The controller is tied to the view and the model as it's supposed to be. The view is not tied to the model.
No, it's not. Because a single controller over its lifetime can be bound to many different models.
The controller is glue. It brings together whichever model is appropriate at the moment with whatever view is appropriate at the moment, and makes decisions about when to change those things.
For the sanity of the view, the controller is the single point where it can get the data. It shouldn't know the nitty gritty details about where it came from, whether it's a "model," or anything else. The view is just, "Gimme the data, controller! Gimme!"
This principle is just as valid in Ember as it is in Rails. The only difference I see is that because the controller and view have to live forever, so to speak, it makes more sense for the view to pull data from the controller rather than have the controller push data to the view.
Maybe think about it this way. How is this any different than rails, really? In Rails you set goddamn instance variables in your controller actions. The view and controller are straight-up sharing state.
How is that less coupled?
This would be like the controller exposing getting and setter methods and instead of typing
<% @users.each do |user| %>
<li><%= user.name %></li>
<% end %>
<% controller.users.each do |user| %>
<li><%= user.name %></li>
<% end %>
Ember seems less coupled all around than Rails and because of its long-running nature needs the view to poll the controller.
How is the controller not the data as far as the View is concerned?
I'm a bit off-topic, but you don't need to "compromise" your HTML with AngularJS, you can place "data-" in front of your attributes and you're HTML-compliant again :).
What's wrong with that? Other than scoping problems (which Angular solves), this is far more in line with classic view-controller than anything else.
A more general argument is that any behaviour specified in markup is bad. I'd counter that by saying that it's already there in HTML. Input boxes for example have behaviour intrinsic to their being. So angular let's you create a (for example) richtext tag. You attach behaviour to that tag, say on click. In the HTML it's as clean as <richtext>. Within the directive you can make it behave as you please.
I think that people see the shortcut directives used in angular (eg Ng-click) and the purists shout "unclean"! The reality is that You can do things a slightly longer way and end up with something thy looks a lot like the observer pattern.
It took me a while as well to figure out why controllers proxied to models. However it started to make a lot of sense in when building an app, since the controllers are there to stay around, and the models are swappable.
Having the option to easily swap out a model at the controller level is worth the extra layer abstraction. That and the ability to add additional UI specific properties on the controller that don't necessarily belong in the model (since they don't need to be persisted).
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
for those that haven't read what the original model-view-controller-user idea was all about. It makes more sense from a Smalltalk/Self/Object-C/Message-passing style of object orientation ("true object orientation") than from java -- in this sense it should be a good fit for javascript as well -- but unfortunately java/c++ style object orientation (really "class-inheritance orientation") have bastardized MVC to mean something subtly different (I am not quite sure what, exactly, but I don't think I'm the only one...).
[1] "Well, I'm an old-fashioned guy. And I also happen to believe in history. The lack of interest, the disdain for history is what makes computing not-quite-a-field." -- Alan Kay http://www.drdobbs.com/architecture-and-design/interview-wit...
I tried to get to the core idea, and I think it is to separate things as much as possible, and minimize interconnections, so as to keep complexity down.
In practice it means to create components (objects) that keep their guts hidden and offer an official "API" to use them.
This might seem far from MVC, but what is the purpose of MVC if not to protect us from the exponential complexity black hole?
Just don't mix things more than you have to.
BTW, I'm much more adept of removing the controller and going to a tightly coupled stack of view-model with the use of the observer pattern where needed. Controllers remind me of that extra indirection that seems useful in design but is never really used and is thus just unnecessary complexity.
One can think of it as Eclipse with its ecosystem.
To build such a system on the Enterprise with its typical NIH (not invented here) paranoid attitude was VERY hard.
I had to reinvent a lot of wheels.
On the Web, I've used backbone for a long time now, since almost the time it was out. I saw the same problems building complex applications with it (that backbone-marionette amends to a great deal). For a larger project, I evaluated Angular. Had very strong negative feelings about it.
Then I tried Ember. It took me a long time to "get" it. The only thing that kept me motivated is knowing that Yehuda, Tom and Trek and other capable people are contributing on it. I kept fighting through the outdated tutorials, the outdated videos, and even the peepcode video was embarrassingly confusing to me at some point.
But then it hit me. Ember and its infrastructure, the way its MVC is rigged, was very similar to what I was building from scratch on the desktop many years ago. It truly IS the one framework that "gets" desktop, or client-side, applications.
The causer of my confusion was that I didn't completely let go of the "Web-think" for building application. I was stuck at either server-side MVC (MVP), or bare-bones frameworks such as Backbone.
It's been just too long out of the real complex desktop game for me, to realize what that I'm looking at is a proper MVC framework.
So for me, Ember ended up as being great - it still takes me back to the way I was building desktop applications, and I'm sure it will become even better and better. To understand it, you need to cold-boot your thoughts into that classic desktop MVC place; and if you were never in it, I think Ember is an excellent way to get into it as opposed to other frameworks.
Though, I understand the pain of coming from a server-side MVC architecture, I found it refreshing that Ember.js takes the "desktop" MVC approach. Our web apps are now living on the client, acting like desktop apps. Most people struggle with this reverse at first, but can conceptually catch on if shown the way. I think what really needs to happen is a good screencast or two walking through these concepts. I'm interested in putting something together and will when I have the time.
This means that using it with another framework often means modifying that interaction pattern to be more like how rails views ajax, complete with the root objects ({"model":{}}).
This may more accurately apply to the REST driver in ember-data, but that is quite tightly coupled with the rest of it.
As far as the root objects are concerned, I've always been a fan of that part of Rails. Not to say that it cannot be easily gotten rid of with something like this (for ActiveResource)...
ActiveResource::Base.include_root_in_json = false
Or, like in my example app, with this (for ActiveModelSerializers)...
https://github.com/rails-api/active_model_serializers#1-disa...
Angularjs was easy to pickup and I have completed what I wanted to do in about half a day, except one issue, angularjs template rendering is DOM driven. I wanted server-side templates, hence I have to boot phantomjs at server-side. I didn't quite like booting phantomjs for server-side templates.
Since Emberjs offered, handlebar based templates, I was happy that I could render my templates at server-side. So tried emberjs, it took about 3 days, to get it done. Many out dated tutorials & documents spread across internet about older versions of Emberjs. Documentation at emberjs.com is minimal and not helpful. I started looking at source code of discourse.org and try to understand how they used ember. I felt the power of emberjs when I needed complete control of context and rendering of nested templates. It was real beauty.
I switched to Angular (which I also had never used before) and got the same app up and running in a couple days with even more functionality because I was able to hash lots of the trickier "outside-the-box" functionality that I could not for the life of me get working in Ember.
That being said I really like Ember's syntax, Handlebars integration, core values (performance & stability specifically) and have the utmost respect for its creators. I'm hoping since it hit 1.0 that lots of new sample apps, blog posts and SO-type Q&A resources will start showing up and actually stay relevant for more than a month.
The idea is you can have a commentsController instance, and when you switch to a different post, the view(s) bound to it will automatically pick up the new comments array that is swapped out on behind the controller.
Routing is just rewiring the pointers on your controllers and getting the right views up on the page.
1)They say it follows MVC. Its actually MVC but MVP, if you look closely at the implementation.
2)Controller job is not precisely defined. Example: Even the data validations are done at controller level not a model level
So i switched to Backbone.js, which is very flexible library with tons of plugins that can be used when needed.
Since implementation of UI is different from requirement to another requirement. I feel EmberJS doesn't satisfy this, which leads to people using Backbone.js.
Regarding AngularJS, please use it only if you are new javascript and prefer learning Angular Javascript (which is not javascript by the way) :)
Regarding AngularJS, please use it only if you are new javascript and prefer learning Angular Javascript (which is not javascript by the way) :)
Just for clarity, I believe that when you write Angular code you are writing the purest form of javascript. Because thats what you are writing there. Just plain javascript. There is no constructs imposed by the framework at all. This is probably why most people think "Angular's javascript" is not javascript. They have been always fed layers on top of javascript because "javascript is somehow not optimal, not right" and it has to be "changed" and "corrected" . OOP is shoved down the throat. This is probably gone on to the extent that when someone actually writes in pure javascript it starts looking like a foreign language !!
Do you realise that JS is an object oriented language? Prototypes are a means for inheritance (i.e. reuse of code), just as classes are in more traditional languages - it does not mean JS is not OO.
My interpretation of the GP comment is that he means angular to JS is like jQuery to JS, it's effectively a DSL that you have to learn in itself. Someone once said "people don't write javascript anymore, they write jQuery". That's what I think he meant
If you're not convinced of the benefits of MV* frameworks on the client, please write a complex client-side app with vanilla JS and share what you learnt.
I'm being sincere there - I've tried, and I quickly started drowning in sea of boiler plate code I'd rather not have to write. Not that it's not fun to write some of that stuff, but I'd rather be delivering value. And what happens when I create a second app? Hmm seems there's lot of similar boiler plate stuff, why don't I just abstract that into a framewo.. oh wait
1) Is MVC an OOP concept ?
2) Is JS an Classical or Functional language ?
3) How does JS support Closures ?
4) What is Unobtrusive JavaScript and why its so popular ?
5) Is it necessary to add declarations in markup or templates to implement bindings in client side ?
6) Differences between Model Backed View and Markup Driven views ?
7) which should be fat in MVC model or controller ?
8) How does multiple controllers in JS MVC App are controlled?
If you answer these questions and score 80%, you will know what i am talking about.
P.S: If you want some, Come on get some :)
I'm not sure that's very fair to AngularJS. I gave up on Backbone and Ember because they had too many features, then later I was comparing JavaScript MVC patterns and stumbled across AngularJS which just made sense.
If what you mean by 'prefer learning Angular' is you have to understand $scope and $resource, $http etc, that's true of using anyone else's code, plus it's not exactly a massive library!
I'm genuinely curious why you think Angular _isn't_ Javascript?
If you feel my comment about Angular is completely Unfair, I agree with you and will delete it. But here is my argument.
Why Angular is not Javascript:
1) The code written in Angular javascript gets compiled into javascript.
2) Tough to extend Angular and implement features that are not supported by Angular. Please Try adding new features on your own, then you will feel the pain.
3) Mixing bindings between the markup and script is not a good way to add bindings. Bindings should not be mixed with Markup (Unobtrusive JavaScript).
4) I felt Google is doing the same mistake they did with "GWT". They are not thinking in terms of issues faced by other JS developers, That is why jQuery is still pretty popular (Plugin based approach)
While developing client side app, each requirement is completely different and you really don't need a framework to address all this. But you need libraries like Backbone, jQuery ...etc as per the requirement and backed by open source . This is why, i love Backbone,jQuery ..etc
I worked on 4 applications with each having its own simplicity and complexity that uses Backbone. Never faced any issues, Community is very supportive.
If you have done R&D on JS MVC and like Angular than Backbone JS (Ember JS always confuses me too), Please continue with your work. Because there is always a nicer way of doing things in Client side :).
P.S Here is one of my project in Backbone JS (https://github.com/pradeepin2/bbquiz)
Please share your toughts, Why you prefer Backbone JS over Angular JS ? It will be very helpful.
I said a little, not completely, but we're all entitled to our opinions, that's why we're here :)
> 1) The code written in Angular javascript gets compiled into javascript.
I don't fully understand this - although I have only been using Angular for a few months - are you talking about my code in my controllers, views, services etc? because it doesn't seem to compile it and I can step through in browser developer tools. Or are you talking about the directives?
> 2) Tough to extend Angular and implement features that are not supported by Angular. Please Try adding new features on your own, then you will feel the pain.
Again, perhaps it's my use case, I haven't tried to add features to AngularJS but treated it as a dumb framework, adding my own libraries to perform localstorage, offline/online sync, custom view transitions etc. What have you had difficulty implementing?
> 3) Mixing bindings between the markup and script is not a good way to add bindings. Bindings should not be mixed with Markup (Unobtrusive JavaScript).
I agree with you here, however unless you're entirely building the DOM from scratch in JavaScript, you're probably going to work with HTML/CSS templating developers. I feel Angular gets the balance right of extending the templates with directives while not making the HTML generation completely opaque.
> 4) I felt Google is doing the same mistake they did with "GWT". They are not thinking in terms of issues faced by other JS developers, That is why jQuery is still pretty popular (Plugin based approach)
Maybe they are, however jQuery solved the problem of writing one set of JavaScript code which ran on all browsers, even though they all used different syntax (remember the old XHR JS?).
I see a lot of people use jQuery in a hamfisted attempt to modify the DOM without considering Layout/Reflow cycles and then they complain that their pages are clunky and slow to use.
I have an issue with client-side template engines which use handlebars/some other syntax because it's yet another templating engine that HTML developers have to learn, rather than just ... using HTML, which is already a standard.
> I worked on 4 applications with each having its own simplicity and complexity that uses Backbone. Never faced any issues, Community is very supportive.
I think that's great! It would be a very boring world if we were all the same.
> If you have done R&D on JS MVC and like Angular than Backbone JS (Ember JS always confuses me too), Please continue with your work. Because there is always a nicer way of doing things in Client side :).
I swore off writing frameworks a long time ago! :) There are a lot of people much cleverer than I, working on them, plus I much prefer working in the UI/DB area.
> P.S Here is one of my project in Backbone JS (https://github.com/pradeepin2/bbquiz)
Looks good. I think you may have a character encoding issue on one of the questions (it was the rearrange the letters one) I was getting ? ? letters in Chrome on my Mac (UK).
> Please share your toughts, Why you prefer Backbone JS over Angular JS ? It will be very helpful.
Today, I prefer Angular to all the other frameworks, but like I said I don't _want_ a massive library, I just want the routings/DOM manipulation to be handled for me and I can do the rest!
Having said that, if a new project came in tomorrow which was a perfect fit for what Backbone or Batman does, I would go for it. The right tool for the right job!
If Angular was to become a massive framework, I would probably ditch it or just use the parts I need.
I enjoy these discussions, especially when other people know more about a different library than I.
The DOM manipulation stuff is one of the features which sold me on Angular. I love the idea that everything renders itself then responds to a single redraw event fired on the DOM so that reflow happens once rather than the hideous way many people use jQuery to do things like:
var div = $('div').appendTo('.home'); var ul = $('ul').appendTo(div); $('li').appendTo(ul);
Well done, each time you're causing layout.
I had decided to build the frontend in a js mvc framework and the candidates were backbone, emberjs (pre version), angularjs. Read about them and gave backbone a try, however from the documentation only emberjs approach felt better maybe because of a similar in-house development java framework that we work on. So i tried to give emberjs a try at the same time, due to the tight deadlines. I dropped backbone, and spent more time on emberjs because everything simply worked and fitted together nicely. All these binding mechanisms are great and actually work :) . Haven't tried angularjs.
The system now works with emberjs (pre and rc) with a nice layered architecture and separate independent business logic modules.
My advice is to read the documentation carefully and choose what fits better to your needs and coding styles.
text-only: http://webcache.googleusercontent.com/search?q=cache:http://...
Potatos, Potahtos.
To digress a little, it's not much different than the terminology confusion in Backbone, where:
- Router(s) work as front controllers,
- templates (along with the browser's DOM) as views, and
- Views as presenters (from the MVP pattern).
Models are flavored with the Active Record pattern. Presenters and views are tightly coupled.
MVC and MVP coexist because the controllers respond to navigational input (mapping to model-presenter pairs) and the presenters respond to page-specific input (mapping to model manipulations and, possibly, server calls).
That usage of Controllers is not part of the MVC pattern, I'd say. It's just a recycling of the controller instance - not forbidden, just confusing if you wonder what it has to do with MVC.
Actually it's also the RoR way to have short lived controllers (a controller is instantiated for every request), other frameworks use one static controller instance instead.
Just a little clarity in the code. Thanks for the writeup!
This may be the issue. I think most of us never really wanted to build web applications, but we were forced to do so due to browser and framework limitations.
We really just wanted to build the best damn desktop app possible that just happened to be deployed in a browser via the Web. This might explain our confusion and disappointment when client side frameworks don't deliver on that desire.
So no matter which framework we use, we should talk about real world project. Not simple usage that only exists in trying and testing.
Use the framework, you love and you will make it beautiful no matter what :D
Are you talking about HTML validation? AngularJS supports using data-ng-* which means it's valid HTML.
I always get confused by this. I don't understand how being nice factors into technical decisions?
(For the record, I also think wycats is nice, but I don't really care when I'm trying to decide whether or not what he's saying makes sense)