Poll: Which JavaScript framework do you use (and why)?
41 comments
I'm going all in on Angular, even building a big open source project around it (http://ionicframework.com/). What really drew me in was hearing from developers that were using it at big, slow companies for entire teams building production apps.
Officially adopting a technology like that is pretty rare, and I guessed Angular had started to achieve a level of adoption that would make it the most worthwhile to invest in.
I also wrote more about how I think it's going to be huge, which I admit sounds best if you already love angular :) http://ionicframework.com/blog/angularjs-will-be-huge/
Officially adopting a technology like that is pretty rare, and I guessed Angular had started to achieve a level of adoption that would make it the most worthwhile to invest in.
I also wrote more about how I think it's going to be huge, which I admit sounds best if you already love angular :) http://ionicframework.com/blog/angularjs-will-be-huge/
I think it may also be useful to pass this post around too, for people who are browsing this thread. Took me some clicking around to find the right level of explanation (for me) of what ionic does.
http://ionicframework.com/blog/where-does-the-ionic-framewor...
http://ionicframework.com/blog/where-does-the-ionic-framewor...
Ionic is pretty darn cool! We are building our customer facing app around it and it has made developing apps for smartphones a breeze. The funny thing is, we use the MEAN stack for the server side component so essentially, our entire dev stack is HTML5, CSS and Javascript :D
Great to hear, let me know if you ever have any questions :)
Also, for anybody who is a fan of Durandal... looks like it'll be combining with Angular:
http://eisenbergeffect.bluespire.com/angular-and-durandal-co...
http://eisenbergeffect.bluespire.com/angular-and-durandal-co...
At my place of work (large, slow) Ember is starting to get widely used. "Google uses/supports it" is instant justification for using it to any layer of management, and I think that's the source of its success. (At least where I'm working people are afraid of using Ember because it's harder to explain/justify to the suits.)
Likewise, I expect at some point we'll be using node.js (probably over Rails/Django) because it's a lot more obvious to 'management' that it's used by large organizations.
Likewise, I expect at some point we'll be using node.js (probably over Rails/Django) because it's a lot more obvious to 'management' that it's used by large organizations.
I meant to say Angular is starting to get widely used. Typing snafu. (Post makes no sense otherwise.)
We're an Angular shop and just started using Ionic for our mobile app. Loving it so far! Thanks!
I was surprised to see you're based in Madison! Dangerously close to Muramoto.
For what it's worth, I've worked on large teams building production Angular, Backbone and Knockout applications. By far my preferred framework is Backbone.
Angular is great at first. You can get the first 80% of your application done in no time. The rough edges are intense though, and if you find yourself using the $compile and $parse services you're definitely writing code someone else is going to curse you for down the road.
Also, I do not understand why so many people think Angular is "testable." The end to end testing is weird and would be better accomplished with Selenium.
The unit testing story is even worse. inject() and module() helper functions are a necessity, and that fact alone should cause everyone pause. How come the basic injector is so difficult to load things into? Creating controllers in unit tests is awkward. Dealing with scope.$apply and promises is also painful.
Large code bases get painful quickly. There's (at least last time I looked) no dynamic script loading solution. You can use require, but coupling that with the dependency injector gets awkward. Further, directives sound great at first, but once big teams start pumping out directives, it gets difficult to reason about your html and figure out what's going on.
Form validation is really strange and the business requirements on every project I've worked have never been met by it.
Also, Angular seems to suffer more from client side rendering jitter than many of the SPA frameworks I've seen. Backbone does too, for sure, but it's easier to hook up something like FastDOM to Backbone.
Which leads me to Backbone - it's more of a library than a framework. It provides nice code structure and organization and otherwise stays out of your way. For small apps that may not be desirable, but for large apps it can absolutely be a blessing. Sure, you have to do more, it may even take more discipline, and it might even be more lines of code, but for big teams it really does seem like a better fit.
Finally, my contention is that VERY FEW APPLICATIONS SHOULD BE WRITTEN AS "SINGLE PAGE APPLICATIONS". Using something like Pjax + Backbone/React for light interactivity seems to be a sweet spot for many of the applications I've worked on. So many screens are read only, and performance will be markedly better rendering server side and injecting HTML directly in to the DOM.
Angular is great at first. You can get the first 80% of your application done in no time. The rough edges are intense though, and if you find yourself using the $compile and $parse services you're definitely writing code someone else is going to curse you for down the road.
Also, I do not understand why so many people think Angular is "testable." The end to end testing is weird and would be better accomplished with Selenium.
The unit testing story is even worse. inject() and module() helper functions are a necessity, and that fact alone should cause everyone pause. How come the basic injector is so difficult to load things into? Creating controllers in unit tests is awkward. Dealing with scope.$apply and promises is also painful.
Large code bases get painful quickly. There's (at least last time I looked) no dynamic script loading solution. You can use require, but coupling that with the dependency injector gets awkward. Further, directives sound great at first, but once big teams start pumping out directives, it gets difficult to reason about your html and figure out what's going on.
Form validation is really strange and the business requirements on every project I've worked have never been met by it.
Also, Angular seems to suffer more from client side rendering jitter than many of the SPA frameworks I've seen. Backbone does too, for sure, but it's easier to hook up something like FastDOM to Backbone.
Which leads me to Backbone - it's more of a library than a framework. It provides nice code structure and organization and otherwise stays out of your way. For small apps that may not be desirable, but for large apps it can absolutely be a blessing. Sure, you have to do more, it may even take more discipline, and it might even be more lines of code, but for big teams it really does seem like a better fit.
Finally, my contention is that VERY FEW APPLICATIONS SHOULD BE WRITTEN AS "SINGLE PAGE APPLICATIONS". Using something like Pjax + Backbone/React for light interactivity seems to be a sweet spot for many of the applications I've worked on. So many screens are read only, and performance will be markedly better rendering server side and injecting HTML directly in to the DOM.
As it happens, most of these projects are JavaScript libraries leaving only Ember, Spine, and Batman labeled as bonifide "frameworks" by their respective maintainers.
If your intention is to build JavaScript applications and the different philosophies of these projects isn't obvious to you, then I think it's worth hearing Yehuda Katz and Tom Dale make the case for frameworks (specifically Ember) in their keynote presentation at Fluent 2014: http://youtu.be/jScLjUlLTLI
If your intention is to build JavaScript applications and the different philosophies of these projects isn't obvious to you, then I think it's worth hearing Yehuda Katz and Tom Dale make the case for frameworks (specifically Ember) in their keynote presentation at Fluent 2014: http://youtu.be/jScLjUlLTLI
Both Angular and Ember. I love them both. Sue me.
I've written 2-3 large applications in Angular, I've contributed ~1200 lines to Angular 1.3, and racked up a lot of points on StackOverflow answering questions around Angular.
However, I'm currently working on a pretty crazy real-time app for Netflix that's all in Ember, and I wouldn't have it any other way. I have the pleasure of working with @ebryn there, and it's been an awesome experience.
In this poll, there are really just those two frameworks. The others frankly aren't in the same league right now.
I've yet to read what I thought was an unbiased, honest comparison of the two. Generally, anyone that does a comparison has one favorite, and the other they barely know. I'm hoping to remedy that at some point, but I still feel my Angular experience out-weighs my Ember experience. At least for now.
However, preliminarily, I can say that both frameworks are absolutely brilliant attempts to solve similar problems in completely different ways. I think they both have a LOT they could learn from one another. I prefer a convention-based approach, which is one thing I love about Ember... That said, I prefer Angular's constructor-based DI over the setter-based DI of Ember... That said, both of them have somewhat primitive IOC containers that could be better (which is a whole blog post by itself)... THAT said, Angular allows developers to put too much logic in their templates via expressions (harder to test)... THAT said, Ember's structure and composition isn't quite as easy to pick up if you're new to the framework... THAT said, Angular doesn't require any other libraries and is very compact... THAT said Angular's directives allow for wild-west spaghetti code and give developers enough rope to hang themselves... blah blah blah
... the point is, I could go on forever. Both libraries have REAL advantages over one another, but libraries have REAL disadvantages over one another as well.
# Embular.js in 2016!! Change the world!
What I'm hoping for is that the incredibly brilliant minds behind these two efforts see the light and join forces. Even work with the folks designing ES6/7 and the future of HTML/DOM...
What I'm hoping stops is the "my framework is better than your framework because _______." silliness.
I've written 2-3 large applications in Angular, I've contributed ~1200 lines to Angular 1.3, and racked up a lot of points on StackOverflow answering questions around Angular.
However, I'm currently working on a pretty crazy real-time app for Netflix that's all in Ember, and I wouldn't have it any other way. I have the pleasure of working with @ebryn there, and it's been an awesome experience.
In this poll, there are really just those two frameworks. The others frankly aren't in the same league right now.
I've yet to read what I thought was an unbiased, honest comparison of the two. Generally, anyone that does a comparison has one favorite, and the other they barely know. I'm hoping to remedy that at some point, but I still feel my Angular experience out-weighs my Ember experience. At least for now.
However, preliminarily, I can say that both frameworks are absolutely brilliant attempts to solve similar problems in completely different ways. I think they both have a LOT they could learn from one another. I prefer a convention-based approach, which is one thing I love about Ember... That said, I prefer Angular's constructor-based DI over the setter-based DI of Ember... That said, both of them have somewhat primitive IOC containers that could be better (which is a whole blog post by itself)... THAT said, Angular allows developers to put too much logic in their templates via expressions (harder to test)... THAT said, Ember's structure and composition isn't quite as easy to pick up if you're new to the framework... THAT said, Angular doesn't require any other libraries and is very compact... THAT said Angular's directives allow for wild-west spaghetti code and give developers enough rope to hang themselves... blah blah blah
... the point is, I could go on forever. Both libraries have REAL advantages over one another, but libraries have REAL disadvantages over one another as well.
# Embular.js in 2016!! Change the world!
What I'm hoping for is that the incredibly brilliant minds behind these two efforts see the light and join forces. Even work with the folks designing ES6/7 and the future of HTML/DOM...
What I'm hoping stops is the "my framework is better than your framework because _______." silliness.
ExtJS/Sencha Touch has been the framework of choice where I work. We complain about it a lot, it has a lot of bloat for probably 90% of use cases, a number of bugs, an extremely poor forum community (I'm looking at you, Mitchell Simoens), and you have to pay for it, but...
Well, I was going to say something good about it, but nothing comes to mind. To be fair, we've built some pretty complex applications on it, so clearly it can be made to work. It just doesn't feel natural, and you have to work around a lot of issues.
For some of the mobile development, we evaluated Angular, Knockout, and even briefly Meteor, but there was a desire for pre-canned view components available in the framework instead of writing HTML snippets/templates. It's too bad, because I really liked Angular and Ember (I didn't personally look at Meteor). I'm hoping to be able to use one of these on future projects.
Well, I was going to say something good about it, but nothing comes to mind. To be fair, we've built some pretty complex applications on it, so clearly it can be made to work. It just doesn't feel natural, and you have to work around a lot of issues.
For some of the mobile development, we evaluated Angular, Knockout, and even briefly Meteor, but there was a desire for pre-canned view components available in the framework instead of writing HTML snippets/templates. It's too bad, because I really liked Angular and Ember (I didn't personally look at Meteor). I'm hoping to be able to use one of these on future projects.
Disappointed (but not surprised) to see Twitter Flight missing from this list. Flight + jQuery has been stellar for me, building several applications of varying complexity (one basic CRUD app with a little bit of flair, one pretty client-intensive app, though no client-side routing, and a few in between).
Came here wondering if I'd see anyone else using flight. Really liking it as a light weight framework/lib so far.
As someone who doesn't build a lot of SPA's, it's a godsend. Keeps the UI structured and decoupled, but doesn't get in the way. I wonder if it really classifies as a "framework"? I feel like it does, since if I'm using it I'm not using a more traditional "framework" like Backbone or Angular; but at the same time, it doesn't come with all the usual restrictions of traditional frameworks (nor does it provide everything they do, but that's kinda the point).
Just beware what you are getting into with Angular.
https://github.com/angular/angular.js/blob/master/src/ng/com...
https://github.com/angular/angular.js/blob/master/test/ng/co...
https://github.com/angular/angular.js/blob/master/src/ng/roo...
https://github.com/angular/angular.js/blob/master/test/ng/ro...
https://github.com/angular/angular.js/blob/master/src/ng/com...
https://github.com/angular/angular.js/blob/master/test/ng/co...
https://github.com/angular/angular.js/blob/master/src/ng/roo...
https://github.com/angular/angular.js/blob/master/test/ng/ro...
I'm not quite sure what's your point. Of course the magic has to happen somwehere. I just don't want to bother with it. AngularJS is not so easy to understand, but it works pretty well, for me at least.
The point is that the code is quickly piling up technical debt.
Maybe. But it could also benefit from Google's financial backing if it became as big as the author would like it to be. Then it wouldn't matter.
(By that I mean that there would be efforts made to keep it lean. I don't think Google is Microsoft.)
(By that I mean that there would be efforts made to keep it lean. I don't think Google is Microsoft.)
Can you elaborate?
Besides just four files containing ~10k lines of code?
Two of those are test files. Nothing wrong with more tests, and they seem descriptive to me. And it's a very easily testable framework, unlike some of the others in the thread.
We can't read your mind buddy! But agreed, 10k lines of code in just a few files is a valid point of concern.
It's mostly comments and tests. Seems like exactly what you'd want.
I've worked over the last two years on a library called Falcon.js (http://stoodder.github.io/falconjs/). It's your typically MVC/MVVM structure with similar concepts as Backbone (Models, Collections, Views). But utilizes the awesome data-binding architecture of Knockout. Falcon's core belief is that front-end developers shouldn't explicitly have javascript mixed with html (or vice versa). This is made possible only because of how Knockout handles data binding and templating. Falcon adds common sense architecture around that belief. Take a look! I'm always excited for feedback. I've use Falcon in many production level apps both for desktop web and mobile hybrid apps.
We use Backbone with a view layer that we wrote on top of it called Ribcage: http://github.com/techwraith/ribcage-view
Backbone walks the line between framework and a collection of modules really well. It gives you just enough to be productive without being overly complex or restrictive. If you go the Backbone route, here's some pointers:
- Make sure you have a system in place for model management, having multiple models around for the same data can be a nightmare
- Backbone views are a bit too simple most of the time, you'll want to at least add a view hierarchy system and lifecycle events/methods.
- You can use the router for as much or as little as you'd like, don't feel like you have to have a new URL for every state in your app.
Backbone walks the line between framework and a collection of modules really well. It gives you just enough to be productive without being overly complex or restrictive. If you go the Backbone route, here's some pointers:
- Make sure you have a system in place for model management, having multiple models around for the same data can be a nightmare
- Backbone views are a bit too simple most of the time, you'll want to at least add a view hierarchy system and lifecycle events/methods.
- You can use the router for as much or as little as you'd like, don't feel like you have to have a new URL for every state in your app.
I chose Angualar due to having the largest community, biggest backer (Google), and the positive reviews. I'm a huge fan but sometimes think there's a bit too much "magic" happening. The worst part however is the learning curve, which can be brutal for new javascript devs. Still, the more I hear about Angular 2.0, the more I realized AngularJS was the right choice and will be the dominant framework for the web moving forward.
So I've been using angular almost daily for a year and a half now and I might be biased, but from what I've done on other frameworks angular is still my personal favorite. Good choice.
I'm curious what you mean by "magic." Once you understand how it all works, there's no magic. Though you are right that it takes time to understand. I feel like the magic is just part of that learning curve.
I'm curious what you mean by "magic." Once you understand how it all works, there's no magic. Though you are right that it takes time to understand. I feel like the magic is just part of that learning curve.
IMO depend of the type of the project you're building. I'm using Ember because most of the project I work on right now have multiple pages, views and components. Using any other library/toolset would be much harder to achieve the same results. Ember comes with a lot of things in the box, the routes is definitely a game changer compared with with others.
Backbone (though I want something lighter weight and w/o the jquery dependency), backbone-signal, Handlebars, browserify.
I have a single app model which uses a bunch of reactive signals and other registry data.
The great thing about browserify if it give you commonjs for the client side. commonjs takes care of the structure & naming of your domain logic. It also allows you to create fine-grained modules, which is wonderful for reuse & maintainability.
I wish there was a standalone Handlebars module which allows updates to the data, like what is done in Ember. I'm willing to use another template framework, which can be mimized, that supports data binding. React seems interesting.
I test with jasmine & jsdom. I tried phantom, but it's nice to be able to easily create test doubles as needed. I tend to perform black box (or functional) testing when possible, eschewing unit tests. I use jasmine-flow to test user flows.
I have a single app model which uses a bunch of reactive signals and other registry data.
The great thing about browserify if it give you commonjs for the client side. commonjs takes care of the structure & naming of your domain logic. It also allows you to create fine-grained modules, which is wonderful for reuse & maintainability.
I wish there was a standalone Handlebars module which allows updates to the data, like what is done in Ember. I'm willing to use another template framework, which can be mimized, that supports data binding. React seems interesting.
I test with jasmine & jsdom. I tried phantom, but it's nice to be able to easily create test doubles as needed. I tend to perform black box (or functional) testing when possible, eschewing unit tests. I use jasmine-flow to test user flows.
backbone's only hard dependency is underscore, it's also the lightest library on this list by a solid margin
Spine is even lighter than Backbone. I like Spine because its functionality is not really tied to the DOM or jQuery -- I make native mobile apps with Spine on Titanium, for instance. Spine is built out of components (i.e. Model and Router), which can be used separately or in concert. It's a massively underappreciated framework that has had staying power.
Not to mention, stepping through (or trying to log) the endless anonymous functions created by underscore can be a hassle and straight crashes chrome/node inspector in some situations.
Not to mention, stepping through (or trying to log) the endless anonymous functions created by underscore can be a hassle and straight crashes chrome/node inspector in some situations.
Started with Backbone and found myself using a lot of extensions to get the work done. Switched over to Angular and it seemed like a much more complete framework. Nail in the coffin for Backbone was when a buddy rewrote one of his extensions from Backbone (almost 2000 lines) for Angular (just shy of 800 lines).
I haven't built anything huge with it, but am enjoying how easy it is to work with. I use .Net and MVC quite a bit, so I think the Angular with its "pseudo" (some people argue Angular isn't a "real" MVC framework) MVC approach was easy to pick up. I also like the idea you can use a little for say a navigation or a photo album or a lot for a large scale native application.
Never liked Knockout for a variety of reasons, did some cool stuff with Meteor, but convincing people to use it was a hassle.
In the end, AngularJS wins for me.
I haven't built anything huge with it, but am enjoying how easy it is to work with. I use .Net and MVC quite a bit, so I think the Angular with its "pseudo" (some people argue Angular isn't a "real" MVC framework) MVC approach was easy to pick up. I also like the idea you can use a little for say a navigation or a photo album or a lot for a large scale native application.
Never liked Knockout for a variety of reasons, did some cool stuff with Meteor, but convincing people to use it was a hassle.
In the end, AngularJS wins for me.
Batman.js is production-ready: our company has two production apps and I work full-time on a Rails/Batman.js app. I think the biggest weakness is the low "googleability". Even when shopify was maintaining it, the hype machine never got rolling . I've been adding docs & guides as much as I can, but there's still a lot to be desired.
I've recently been working on a glorified FAQ that would be very helpful if you decide to go the batman.js route: https://www.softcover.io/read/b5c051f3/batmanjs_mvc_cookbook
And I'd love to add to it -- just drop by #batmanjs on freenode! (ps, I kept trying to vote but I didn't see the thing go up ... and I even made a HN account just for the occasion!)
I've recently been working on a glorified FAQ that would be very helpful if you decide to go the batman.js route: https://www.softcover.io/read/b5c051f3/batmanjs_mvc_cookbook
And I'd love to add to it -- just drop by #batmanjs on freenode! (ps, I kept trying to vote but I didn't see the thing go up ... and I even made a HN account just for the occasion!)
Backbone. its a very minimal single purpose library I enjoy and come back to. Wrote several modules to help with redis, socket.io, server side templating and more.. Its APIs are quite mature, the community is great, plays nicely with coffee script and anything I threw at it so far..
I mucked around with a few but found them quite restrictive and generally only pushed issues around as opposed to solving them. As soon as you're dealing with a nasty API you can generally find the limits of a framework and have to start writing your own work arounds to behave inside its designed parameters.
Essentially I've found jQuery the best option as a framework, and only because it reduces the verbosity of straight Javascript. Everything else, as noted above, usually ends up in the "good at first then in wish I didn't" basket.
At the end of the day, the majority of what I do is binding, validation, and event handling... and no framework really reduces what has to be done, they just stops other people from doing it differently.
Essentially I've found jQuery the best option as a framework, and only because it reduces the verbosity of straight Javascript. Everything else, as noted above, usually ends up in the "good at first then in wish I didn't" basket.
At the end of the day, the majority of what I do is binding, validation, and event handling... and no framework really reduces what has to be done, they just stops other people from doing it differently.
Ember, Ember, Ember. Oh, how I love thee.
There are a few types of javascript styles that I've found are pretty common.
- Event Based (jQuery-esq) - Class Based with router (backbone, marionette, et al) - Declarative with routing (Ember, Angular)
Of those, I think the declarative applications tend to build out into easy to maintain systems. State management is easier, extending is easier, and most tend to build easy to digest components that are small and cohesive.
I've found that Ember scratches a number of itches for me when it comes to building out a declarative system. The biggest win for me is the fact that Ember's router is a really, really fantastic bit of engineering. The way that you can build out state into your router and have classes and components that react to those state changes is a super elegant way to develop web applications, for me. Combined with the outlet system for managing complex view trees, and it's a slam dunk.
Ember's system of routes, controllers, and views help me maintain single responsibility principles, because I have a clear definition of what a route does, what a view does, and what a controller does. Things are even easier when you get down to the refactor stage and start moving everything you possibly can into components (which are forward compatible with the upcoming specifications for web components).
The only reservation is that, because the style of MVC that ember follows, the learning curve can be a bit drastic. They've been solidly improving since 1.0 dropped and the wealth of materials out there that are outdated or old (pre RC days) are dropping off of the SERPs pretty rapidly.
Ember's a joy to work with. For 85% of the web applications out there, you probably won't need to venture out of the framework all that much. However, when you DO need to venture out of the framework, it can be a really frustrating experience. The primary example would be integrating something along the lines of D3 or Three.js, or honestly any library that expects to manipulate the DOM directly, as ember's reliance on handlebars is pretty complete. This means that having a view class manage user interaction events really can't be decoupled from the rendering of the view itself, which I feel like is ember's biggest issue right now. Secondarily, there is a personal need for better hooks for view lifecycle events, for providing things like animations / transitions in and out. animated-outlet is a potential solution, but I'd much rather do it the 'ember way' with hooks I can define in my controller classes rather than using a one-size-fits-all style solution (which is what I feel like animated-outlet is).
Don't let these things detract you from really diving into Ember. It's honestly a super refreshing and highly efficient way to build javascript applications. The state management of URLs within the router as well as the very clear and well enforced separation of concerns helps reduce code rot and smells before they even get started. Once you're past the initial learning curve, you'll be shocked at how rapidly you can develop robust, focused applications.
There are a few types of javascript styles that I've found are pretty common.
- Event Based (jQuery-esq) - Class Based with router (backbone, marionette, et al) - Declarative with routing (Ember, Angular)
Of those, I think the declarative applications tend to build out into easy to maintain systems. State management is easier, extending is easier, and most tend to build easy to digest components that are small and cohesive.
I've found that Ember scratches a number of itches for me when it comes to building out a declarative system. The biggest win for me is the fact that Ember's router is a really, really fantastic bit of engineering. The way that you can build out state into your router and have classes and components that react to those state changes is a super elegant way to develop web applications, for me. Combined with the outlet system for managing complex view trees, and it's a slam dunk.
Ember's system of routes, controllers, and views help me maintain single responsibility principles, because I have a clear definition of what a route does, what a view does, and what a controller does. Things are even easier when you get down to the refactor stage and start moving everything you possibly can into components (which are forward compatible with the upcoming specifications for web components).
The only reservation is that, because the style of MVC that ember follows, the learning curve can be a bit drastic. They've been solidly improving since 1.0 dropped and the wealth of materials out there that are outdated or old (pre RC days) are dropping off of the SERPs pretty rapidly.
Ember's a joy to work with. For 85% of the web applications out there, you probably won't need to venture out of the framework all that much. However, when you DO need to venture out of the framework, it can be a really frustrating experience. The primary example would be integrating something along the lines of D3 or Three.js, or honestly any library that expects to manipulate the DOM directly, as ember's reliance on handlebars is pretty complete. This means that having a view class manage user interaction events really can't be decoupled from the rendering of the view itself, which I feel like is ember's biggest issue right now. Secondarily, there is a personal need for better hooks for view lifecycle events, for providing things like animations / transitions in and out. animated-outlet is a potential solution, but I'd much rather do it the 'ember way' with hooks I can define in my controller classes rather than using a one-size-fits-all style solution (which is what I feel like animated-outlet is).
Don't let these things detract you from really diving into Ember. It's honestly a super refreshing and highly efficient way to build javascript applications. The state management of URLs within the router as well as the very clear and well enforced separation of concerns helps reduce code rot and smells before they even get started. Once you're past the initial learning curve, you'll be shocked at how rapidly you can develop robust, focused applications.
I've been working on a less-JS heavy declarative client-side library called intercooler: uses partials, REST-ful url conventions and declarative HTML5-style attributes to drive AJAX-based apps:
http://intercoolerjs.org
Hoping to get some video tutorials up in the next day or two.
http://intercoolerjs.org
Hoping to get some video tutorials up in the next day or two.
I use Backbone because I see it as the C of javascript "frameworks". It doesn't do anything, it doesn't pretend to be all-encompassing but it's small and efficient. The fact that it's been in use for quite some years also created an ecosystem of good practices and additional software to complement what some people consider shortcomings of Backbone itself. But shout out to all the other frameworks who are tackling the problem from different angles and provide choice and competition to the field, this is all very healthy and will make developers and ultimately users happiers in the end.
If you're looking for something reminiscent of Rails, I would suggest Ember.
I'm a junior developer (if that), and I've found the strong opinions and conventions of Ember very refreshing.
I'm a junior developer (if that), and I've found the strong opinions and conventions of Ember very refreshing.
I like Chaplin.js, it provides a very structured way of building Backbone applications with things like memory management and object disposal, which are really nice.
where's react?
Is React really comparable to things like Angular and Meteor? From what I understand, its supposed to be used in conjunction with a lot of other libraries, being only the 'V' in MVC and all.
That would disqualify Backbone too.
I'm not so sure, Backbone seems to do a lot more than React. I could just be talking out of my ass though, I've never messed with Backbone
Backbone offers some base objects/classes around Models, Views and Collections but does not enforce any specific architecture. It's completely up to you how you use it.
yeh i was wondering that too... but that's what I like about React actually. A simple skin for complex views on top of a server-side language (Java/Clojure for me).
It makes more sense to me since I don't want my entire site to be overly Ajax-y. I'd rather only feed a few initialization variables to js & have most of the site logic/navigation/variable-injection coming server-side from a nice persistence layer.
It makes more sense to me since I don't want my entire site to be overly Ajax-y. I'd rather only feed a few initialization variables to js & have most of the site logic/navigation/variable-injection coming server-side from a nice persistence layer.
[deleted]
I personally prefer Ember community than Angular's and I feel the love of Ember team for the project. So I up vote to Ember.
One of the big reasons I chose Ember is because it embraces convention over configuration and I have no patience for boilerplate.
I use Marionette (a very light framework built on top of backbone) and love it - perfect blend of power and ease of use.
Awesome ember doing its thing again. Ok lets go guys, lets put ember at the top. I have used angular, ember and backbone and I feel more at home with ember and I could pretty much pick up any new ember project quickly and figure out where things are.
I use backbone, I like it because it's less of a framework and more of a way of structuring your code, you can decide the rest and there are loads of modules/libraries out there to help you out.
Ember is really fast and well thought out. It's a complete framework that you can build on to of rather than a few pieces that you can assemble into a pile of self-indulgent jank
Meteor is amazing and having been given the opportunity to build out a shop I am going all in with it. I've previously used backbone for large scale(HUGE contracts) projects, and I appreciate it a lot, but meteor makes things ez-mode for me. Basically abolishes front/backend dichotomy(apart from design type stuff, which I'm still abysmal at, but that's why we have designers who can layout in CSS)
the [LEBRON stack](http://lebron.technology/) using many small npm modules is my favorite, but i add Backbone and React when i'm working with others who want something more framework-y.
also DocPad for static sites with more content than code.
also DocPad for static sites with more content than code.
GWT . Still the most RAD option for web dev.
WindowBuilder is free and allows really good GUI construction.
WindowBuilder is free and allows really good GUI construction.
[deleted]
What frameworks and libraries do you use to develop for iOS and Android?
[deleted]
Famous.
It's blazingly fast.
disclaimer: I work for famous.
It's blazingly fast.
disclaimer: I work for famous.
Should specify you mean frontend
I'm using sails.js (on top of express.js and node.js) for an MVC app
I'm using sails.js (on top of express.js and node.js) for an MVC app
I vote for EnyoJS.
I prefer Webix
ReactiveJS
GWT isn't even on there. Why ? Frontend-backend integration. Backend on JVM. Library availability. By far the best integration with other tools and mature backends. Plus statically typed programming that just doesn't suffer from CSRF and the like. Oh and Java offers excellent IDEs, complexity control and a large pool of capable developers (though an equally large contingent of incompetent programmers that have gotten rather good at appearing capable).
Do you know jQuery inside out? If not, you should learn that before you worry about higher level frameworks.
Actually, people should know JavaScript better before even hearing about jQuery... I lost count of how many times I heard people saying they know how to "program in jQuery" and that made me really sad/angry regarding how people lack curiosity and knowledge in their own field...
Not only that, but with current modern browsers, you might not even need jquery at all ;) http://youmightnotneedjquery.com/
Not only that, but with current modern browsers, you might not even need jquery at all ;) http://youmightnotneedjquery.com/
This should be, "Do you know JavaScript inside out?". Native JS is where people should be starting.
Exactly...
As crockford would say "The World's Most Misunderstood Programming Language Has Become the World's Most Popular Programming Language" http://javascript.crockford.com/popular.html
As crockford would say "The World's Most Misunderstood Programming Language Has Become the World's Most Popular Programming Language" http://javascript.crockford.com/popular.html
jQuery -- The world's most popular misunderstanding ...
I barely use jquery at all and build rather large JS applications. YMMV
Angular is making a run at replacing jQuery as we speak. It still lacks some of the easing and visual effects, but can do most of what jQuery is known for.
http://paulhammant.com/2012/03/03/replacing-jquery-with-angu...
"Don’t even use jQuery. Don’t even include it. It will hold you back. And when you come to a problem that you think you know how to solve in jQuery already, before you reach for the $, try to think about how to do it within the confines the AngularJS. If you don’t know, ask! 19 times out of 20, the best way to do it doesn’t need jQuery and to try to solve it with jQuery results in more work for you."
http://paulhammant.com/2012/03/03/replacing-jquery-with-angu...
"Don’t even use jQuery. Don’t even include it. It will hold you back. And when you come to a problem that you think you know how to solve in jQuery already, before you reach for the $, try to think about how to do it within the confines the AngularJS. If you don’t know, ask! 19 times out of 20, the best way to do it doesn’t need jQuery and to try to solve it with jQuery results in more work for you."
... and yes, of course you should know JavaScript inside out first. That's why I wrote https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re...
My first choice at the moment is batman.js which is very similar to rails (where I'm coming from), but I'm worried that it's not so developed like others (at least checking the github repo)