Skip to content
This repository has been archived by the owner on May 7, 2024. It is now read-only.

Javascript frameworks

sesteva edited this page Oct 29, 2013 · 3 revisions

A discussion of current JavaScript frameworks. Love them or hate them, they are here to stay!

Backbone.js, AngularJS, EmberJS, Knockout and anything else you can imagine.


notes from Derick Bailey

knockout, backbone, ember, durandal, angular, marionettejs, batman, can, etc.

todomvc project

two camps of projects: html attributes vs "pure" javascript frameworks

knockout: syntax can be awkward due to proxies (ko observable) - do i need to unwrap this? makes it hard to understand how to get the value, sometimes

durandal: rob eisenberg made knockout better

angular: seems to simplify code, scope makes life easier

knockout: too light weight maybe? needs to bring in other things

backbone vs ember: backbone being scalable, ember being large scale

ember: ember vs ember data. ember is all about the front end, doing the DOM and SPA stuff. ember-data seems to be low opinion

ember and backbone: both event driven, so makes them feel similar? similar styles of code?

scalability: scale # of users vs scale # of features. Derick Bailey talks about scaling # of features in Single Page Apps (SPA)

question of which framework to use for large scale teams and user bases

framework choices often come down to whether you want to do your own thing, put it together your self, vs be handed "the way" to do things

documentation: all the big players are doing it well

unsolved problems? duplicating models between backend and front end, and duplicating urls + having to write entire url in javascript code, everywhere

raiff needs more coffee :D

picking a framework is not about which one is best, which one is going to be around or not lock you in. you're going to be locked in to an extend. pick the one that matches your team's style the best

don't try to create seams or insulation layers in between a js framework and your js code. bad idea a this point, due to the way these frameworks are built right now

dirty checking and other things that people think are performance problems typically aren't, because js is so fast right now and the # of fields on your form are not that large

performance on desktop vs mobile devices... virtualizing large data to scroll, etc, for mobile devices

how your code grows from small to large scale:

backbone: easy to adopt if you're already heavily in jquery

backbone -> Marionette; don't re-invent a lot of what marionette already has

marionette -> ember; kind of live side by site; ember is large scale where marionette is scalable

jquery -> knockout -> angular path

angular can be used in small apps and grown

ember is opinionated and will make you do it "the right way" - high learning curve

angular, easier to pick up and run with it

backbone can be easy for teams to pick up good javascript habits, writing well structured code, before moving in to large SPA stuff

biggest transition from backbone to ember is backbone.view and how it's odd vs real controllers and scoped DOM stuff

may be easy to think of backbone.view as a "presenter" from Model-View-Presenter patterns

which framework to choose? iphone vs android. pick the one you like.

angular easier for people that aren't so good with javascript?

convert existing app, or grow from existing app? (gabe using Silverlight, so rewrite is needed anyways)

http://amirrajan.github.com/Oak#peeps to compare some frameworks in an actual app

breeze.js to aggregate data from multiple, disparate back-ends

html manipulation can cause problems between designer who wants perfect html / css, and dev who wants to use js framework

angular may be the worst right now, since it wants directives instead of regular html. but future of web components is necessary, and devs/designers will have to do this eventually, anyways

SEO: can be huge problem. possible solutions exist, but no one here seems to have good answers

microformat 2? possible SEO stuff...

testing: can be difficult, angular has built in. don't mock the DOM layer or test it w/ "unit test" - use functional tests and acceptance tests for that stuff

Links

  • ng-learn.org a site for learning Angular JS - Upcoming Free Workshop!

Peeps

Santiago Esteva