For my Bachelor Thesis i am doing all little research about the usage of webframeworks. The Thesis is about isomorph JavaScript based frameworks but i am also interested what else do you use.
Please evaluate your framework under the following aspects:
1. Time needed for Learning the Framework (in Hours)
2. Overall Development Speed (0-3 Points, greater better)
3. Maintainability of the Code (0-3 Points, greater better)
4. Why did you choose that Framework?<p>I know its difficult to define or measure those things but it will get a helpful overview for my thesis. Thanks in advance for your Time! :)
ReactJS + webpack, though I've used Angular and browserify in the past.<p>1. It's just a component framework. It doesn't do the kitchen sink, like Angular does. A couple hours reading the spec and implementing a small test case gets a seasoned developer up to speed on it. Flux takes a little bit longer to get used to, though, and I'm still not quite sure I'm 'doing it right.'<p>2. Coupled with webpack and an automated testing toolchain, development speed is quick. Webpack provides hot module reloading - no need to refresh your browser when you change a file. Very fast feedback loop. 3/3.<p>3. React with Flux provides a pretty strict but flexible guideline for how to build things. Discrete components, actions and data stores all look similar from a structured point of view. This provides a fantastic environment for unit tests. The favored test runner, Jest, provides automocking for dependencies and code coverage analysis. 3/3.<p>4. Virtual DOM for rendering performance. ES2015-oriented structure. Ease of testing. Enforcement of application structure without being a serious impediment. Warnings against implicit two-way databinding that can lead to disastrous cascading DOM changes. Good browser debug tool. On a purely subjective level, it "feels like the future."
ractive. It's the best kept secret in web development.<p>Want a live binding, 2 way, super performant virtual DOM, that feels less like a framework and more like something that came with JavaScript?<p><pre><code> var binding = new Ractive({
el: '.some-class',
template: '<p>Hi there {{ name }}</p> <input value="{{name}}"/>',
data: { name: 'Alex' }
})
</code></pre>
It's created and maintained by The Guardian interactive team.<p><a href="http://www.ractivejs.org/" rel="nofollow">http://www.ractivejs.org/</a><p>## Time needed for Learning the Framework (in Hours)<p>The basics take 30 seconds because almost everyone is familiar with handlebars/mustache templates, but 4 hours total.<p>Eg, ractive has promises for when stuff changes, and you'll have to decide how to load templates (eg, ES6 template strings, or browserify fs). Once you've done that there's not a lot to learn, which is great.<p>## Overall Development Speed (0-3 Points, greater better)<p>Development speed: 3. It's insanely fast to work with because it's simple.<p>## Maintainability of the Code (0-3 Points, greater better)<p>Maintainability: 3. it's small, so super readable.<p>## Why did you choose that Framework?<p>All of the above, plus the support side. It's been around for two years and everyone I know who's used it loves it.
I think the self-reported data that you're going to get is going to be worthless. Anyone who says (for example) that they learned Angular in 3 hours probably didn't really <i>learn</i> Angular.<p>If I were you (and honestly I wish I was, I loved being a student) I'd focus much less on analyzing an arbitrary list of JS frameworks and instead turn my attention to questions like:<p><pre><code> Why are there so many frameworks in the first place?
What problems are JS frameworks trying to solve?
Why does it seems like new frameworks are constantly being produced?
Why can't any single framework achieve critical mass?
</code></pre>
You might learn some very interesting things about the web as a platform and JavaScript as a language.
I use Marionette: <a href="http://marionettejs.com/" rel="nofollow">http://marionettejs.com/</a><p>1. You can grasp the basics in just a few hours, but obviously this is entirely subjective. A week-long training course will really get you going, though. The nice thing in terms of learning it is that the maintainers consider Marionette the "non-framework framework," in that it's just JavaScript, with no new paradigms to learn.<p>2. Hmmm, 3 for me, but that's also subjective. The more work you put into developing a sane architecture, the higher this number will be, but Marionette doesn't really impose an architecture on you, so YMMV.<p>3. 3, but see caveat from #2. Depends on how you write your code, really.<p>4. I chose it because, as stated above, "it's just JavaScript." I don't have to get my team up to speed on an entirely new development paradigm in order to use it. It's not really a "framework," per se, since you aren't given as much functionality out of the box as you would be when writing an Ember app. This means there's less chance of being hemmed in by the limits of the framework. This is a familiar tradeoff - a larger framework that gets you up and running faster, but with more chance of encountering an edge case that it doesn't fully support, vs. a smaller library that requires more up-front work, but is easier to mold to fit your own ends when necessary. In a few years, as the larger frameworks grow more mature, I'll be more likely to use them in my projects.
I use plain vailla JS with some libraries I like for the functionality I need. I can easly replace any lib when something better or some new functionality that the old lib does not implement comes out:<p>- form2object for form serialization<p>- pnotify for notifications<p>- routie or page.js for routing<p>- jqplot for graphs<p>- jquery for dom manipulation and ajax calls<p>- moment.js for date math<p>- socket.io for websockets<p>- ejs for templating<p>- bootstrap for the layout<p>and not much more really.<p>1. Time needed for Learning the Framework (in Hours): A few months to learn JS really well<p>2. Overall Development Speed (0-3 Points, greater better): 2<p>3. Maintainability of the Code (0-3 Points, greater better): 3<p>4. Why did you choose that Framework?: I didn't want to be locked in to angular when react comes out, or be locked in to react when the next big thing comes out.
My preference is Backbone + Marionette, with Bootstrap for layout. I've tried Angular and Ember and I have to say I'm not a fan.<p>Take my opinion with a (large) grain of salt. I'm not a "professional" JS/front-end developer. I'm a back-end dev (Java/Scala/Python) by day and really only touch frontend stuff when working on my own projects. My "me" time is precious and I don't want to spend it wrestling with some uber-framework :)
I use MeteorJS. It really does feel like the future of web development, so much so that going back to other frameworks feels like drudgery.<p>1. Time to learn: I'd say it took me about 120 hours to really feel comfortable and get down the flow of how to build things with it. The hardest part to really grok is the whole Mongo.Collection publication/subscription model. But once you get it, it's smooth sailing.<p>2. Development speed: 3. You build stuff out with one language, real-time is baked in, packages out there to do almost everything. It's pretty nifty.<p>3. Maintainability: Too early to tell, but you can build things with very few LoC. Less code means less chances for bugs. Also, the community is still shaping out what the best way to structure files/folders are. Since Meteor is lax in that area, everybody has their own flavor of best practices.<p>4. Why did I chose it? I can use React pretty seamlessly in the application. It comes with latency compensation built in. Real time built in. There's a huge thriving community of people using it and building cool stuff with it. It's popular.<p>---<p>Overall I really enjoy my time building things with Meteor. I can focus much more on my features and forget about plumbing code. Here's some more developer feedback on Meteor:<p><a href="http://stackshare.io/meteor" rel="nofollow">http://stackshare.io/meteor</a>
My choice is React.js<p>Time needed: I'm not sure. Rendering something on screen, including setting-up the environment, took an hour, tops. But with all the surrounding terminology and concepts, it may have taken around a week or two as I had just the afternoons. I think around 20 hours of investment would bring you good understanding of how React.js works, accomplishing the boring stuff with it like routing and state-management with something like Flux, understanding how to render from server and share code with the client.<p>Development speed: 1 in the project startup, with an exponential speed increase towards 3 as complexity increases, all relative to Knockout.js and Angular.js.<p>Maintainability: 3. I think this is where React.js shines. If you apply the common design patterns that are popular among many React.js projects, you'll be guided to write maintainable code and your data will flow in a single direction. I can't overstate the burden this removes when you are developing a complex application. Strange things <i>never</i> happen.<p>Why: I try all the frameworks and experiment with them just for the fun of it. I stayed with React.js because it made things easier to maintain, as stated above. Development speed wasn't so attractive in the beginning but later, after finishing a project or two, you get on par with the alternatives.
We use Knockout in our workplace. I particularly like it because it is lightweight (you can mix it with plain JS or jQuery) and because it doesn't involve writing HTML as a string in JS.<p>We write mostly internal apps and so performance/scaling are not usually on the radar, but ease of maintainability across a wide spectrum of developer skill levels is.<p>As for comparing to other frameworks, my biggest concern with some frameworks is the writing HTML templates as strings in JS. I've seen a lot of folks arguing that "it's different this time" and that writing string HTML in JS is OK, but it just is such a smell to me to write one language as a string in another.
So naturally, I've used jQuery for a few years now:<p>1. Time to learn: I think 1-2 hours<p>2. Overall dev speed: initially 3, but as you dive into more complex pages that need to e.g.: retain state between AJAX calls, it moves towards a 1<p>3. Maintainability: 1. Keeping track of selectors grows to be very tricky business.<p>4. Why I chose jQuery: I started with it before the explosion of JS frameworks (and I've always said that jQuery started the golden era of JS that we're in), and I would still choose it today if I need to deal with legacy sites at all.<p>I have also used ReactJS:<p>1. Time to learn: I think between 16-40 React hours to really grok components, their lifecycle and how to communicate between them. It's a little reminiscent of components in Mobile development, but really understanding props vs state can take a while<p>2. Development speed: 2. There's a lot of boilerplate involved (usually render, getInitalState, getDefaultProps)<p>3. Maintainability: 3. Easily the most maintainable and reusable JS code I've ever written<p>4. Why did I choose React? I was tired of writing code for the views in the backend (PHP) and then in JS when the data changed. React makes it easy to write once and control the lifecycle of HTML elements
I like Mithril which is similar to React/Ractive.<p><a href="https://lhorie.github.io/mithril/" rel="nofollow">https://lhorie.github.io/mithril/</a><p>It doesn't abstract away too much from JavaScript and provides good methodologies as outlined in the Learn/Guide section of the site.<p>As per your points:<p>1. A good couple of hours to about 6 depending on expertise just to test the workflow, get comfortable with MSX and to read the docs.<p>2. I've not used it in production as for current as I am still in an experimentation speed, but the whole premise is that it acts as a UI layer amongst the business logic that you may already have. It is fairly transportable.<p>3. This would be on a medium scale level depending how you couple your code and how modular you keep it.<p>4. Because it is fairly straight forward to get up and running. The blog posts alone provide great insight into application structure. Also the benchmark claims are quite appealing.
Backbone models/collections/events bound with React components. The beauty of a data API with the expressive components is something I have really liked so far.<p>I'm actually pretty excited the see React/Meteor happening since it provides a similar paradigm.
I have been using Angular for about 2 years. And just started to have a look at other frameworks yesterday and deciding between going for Angular 2 or something else.<p>I found Aurelia and I think it's the next one I'll learn and use in my projects: <a href="http://aurelia.io/" rel="nofollow">http://aurelia.io/</a><p>1. You can do the tutorial in an hour or so, and get the general idea in I'd say about 4 hours.<p>2. From what I've seen it'd be a 3.<p>3. Looks like a 3 too!<p>4. I've watched a couple of videos from his creator Rob Eisenberg, and the guys knows what he is talking about ;)
Plus, it support the Flux architecture with a plug-in:<p><a href="http://blog.durandal.io/2015/07/23/creating-reactive-loosely-coupled-apps-with-aurelia-and-flux-episode-1/" rel="nofollow">http://blog.durandal.io/2015/07/23/creating-reactive-loosely...</a><p>Also there's been some discussions comparing Aurelia to Angular2 and well, seems like Aurelia has the best architectural decissions in, for example:<p><a href="http://blog.durandal.io/2015/03/17/aurelia-angular-2-0-code-side-by-side-part-2/" rel="nofollow">http://blog.durandal.io/2015/03/17/aurelia-angular-2-0-code-...</a><p>A very important thing for me is that it sports a set of tools for quickly setting up a development environment (yeoman generator, jspm, gulp, browsersync).<p>It also supports modern Javascript (ES2015/ES2016) from the start (with Babel).
EmberJS, once u learned it u will get enormous amount of productivity.<p>1. It took me month and documentation is sufficient well enough to learn it faster. (I'm slow at learning, of course learning speed is vary, depends on habit of people)<p>2. I would give point 3<p>3. also 3<p>4. reasons why I choose this framework are it's productivity, u will get good development habits, good patterns while using it and it's good ecosystem<p>sorry my bad english.
In my job we use Angular<p>1. It depends, you can make something quickly but when it comes debuging or make strange things you need a deep understanding of what is going on. I would say between 30 to 40 hours.<p>2. At first it's like 2.5, but when strange things start happening, it can slow to about 2.<p>3. I would say 2.4<p>4. It was really popular, has a lot of resources available and made development really easy.<p>Now for my personal projects I'm learning ReactJS<p>1. The framework is really easy, and it can take about 10 hours to learn it deeply. The difficult part is thinking the way they propose you with Flux. That can be as long as angular with 30 o 40 hours.<p>2. Productivity can be a little worse than angular with 2.0, but results are much better.<p>3. This is the best part. Although I haven't build a big project, at first sight it might seem this is the best part of react. I give it 3.0<p>4. Speed, control of what is going on in the views, popularity, the idea of having the possibility to easily port my apps to native with React Native, the tools such as browserify make even better.<p>I hope it helps you, sorry for my english.
Backbone
1. Learning is relatively easy (I can’t give Hours, for my first code I needed like 2h, for totally understanding the whole lib in depth (at least possible) probably 1 or 2 Months)
2. 1 (Relatively much Boilerplate code)
3. 1-2 (depends on your skills and if you use any extensions that help you structuring your code)
4. It is easy to understand and to extend. I work a lot with interactions like Drag/Drop, custom Widgets etc. Using those was a chore in other frameworks (and needed much binding code and/or extensions), in Backbone it can be just bridged to jQuery (UI).
I'm not a javascript guru and there was a time I was reluctant to use any framework - such a luck we grow up from silly ideas :-)<p>jQuery: 1) 4 hours 2) 3 3) depending on code base, maintainability can be extremely easy but it can also be extremely spaghettti 4) cross-browser compatibility of client-side scripts that manipulate DOM<p>linked-in dust: 1) ~1 hour 2) 3 3) 3 4) cross-browser compatibility, small size, one of the fastest<p>jQuery-ui: 1) ~1 hour 2) 3 3) 3 4) cross-browser compatibility, granular control over what features I deploy
After months of agonizing, for my startup I settled on Ember.js for desktop apps, and Cordova + jQuery for tablet apps (we'll see if we need an actual framework, and if we'll want/need phone apps).<p>I chose Ember because its programming model feels like you're programming with classes, and in general, it's the most object-oriented of the top contenders (the others being React and Angular) and provides, in my opinion, the best way to organize your code.<p>Note: nothing significant has been built yet on the client-side (we are currently building the back-end with Django and Django Rest Framework). But having read documentation and done tutorials for Angular, Ember, and Knockout, plus courses for Backbone and Ember, I felt Ember, while requiring some initial commitment to learn, would give the best return on our investment.<p>The way the Ember project is managed also inspires confidence. "Stability without stagnation" means there won't be big, bad rewrites, or breaking changes introduced without enough of a heads up to facilitate a smooth migration to a newer version.<p>Edit: you mention isomorphic frameworks. One of the top contenders there is Meteor, but it currently gives you no choice but to use MongoDB, which rules it out for a lot of people.<p>Edit 2: fixed a typo.
do you have a Google Form/Spreadsheet or anything similar set up for this, or are you planning to scrape the comments here later? Might be tough to filter out en masse the comments answering your questions from the strictly discussion comments, even at the top level, depending on response. You'd also probably get better responsiveness with an easy form for folks to fill out, especially considering the structure of the responses you want
<a href="http://vuejs.org/" rel="nofollow">http://vuejs.org/</a><p>1. 5 hours to learn 80% of it
2. 3 Very productive
3. 3 Easy to extend and change
4. Easy to learn, easy to use, simple to understand, and highly productive. It is based on ES5 using getter/setter js features to make N-way bindings and data updates easy. Key was looking at todomvc in less code while being very easy to understand how it worked.
I'm a big fan of virtual-dom and the ecosystem of very sharp single-purpose libraries that people have built up around it, usually not even coupled to virtual-dom at all.<p>For me, virtual-dom + main-loop is a pretty great combo for front+back universal javascript. I made some repos about setting up virtual-dom, main-loop, routing, and browserify/watchify with npm run scripts:<p>* <a href="https://github.com/substack/virtual-dom-starter" rel="nofollow">https://github.com/substack/virtual-dom-starter</a> - bare-bones main-loop + virtual-dom setup
* <a href="https://github.com/substack/virtual-dom-universal-starter" rel="nofollow">https://github.com/substack/virtual-dom-universal-starter</a> - universal (front+back)end js example with shared routing and single-page pushState<p>I usually use an ordinary EventEmitter to rig up the unidirectional flow (but I dislike how "flux" makes this a big deal). Here's an example of that: <a href="https://github.com/substack/virtual-dom-unidirectional-example" rel="nofollow">https://github.com/substack/virtual-dom-unidirectional-examp...</a><p>If jsx is your thing, I made an example of setting up jsx in virtual-dom land too: <a href="https://github.com/substack/virtual-dom-starter-babel-es6-jsx" rel="nofollow">https://github.com/substack/virtual-dom-starter-babel-es6-js...</a><p>As far as the research questions go for 1-3, I don't think sampling people about their subjective opinions will lead to any interesting findings, but for question #4:<p>I chose virtual-dom and main-loop because each piece has a singular concern and performs that concern well. I don't want to use a tool that does a bunch of unrelated things because I want to be confident that in the future I can discard pieces of my tooling at will as my requirements change. With bigger tools with larger scope that is not so easy.
Aurelia.<p><a href="http://aurelia.io" rel="nofollow">http://aurelia.io</a><p><a href="https://github.com/aurelia" rel="nofollow">https://github.com/aurelia</a><p>It has the most streamlined, elegant conventions of any framework I've looked at, it focuses on writing in plain, modern JavaScript (ES2015/2016), it's highly modular and plugable, and it tries as much as possible to always comply with modern standards.<p>Hopefully performance is on par with React when it hits official release so that at least a few more people take a serious look at it. It's unfortunate that so much hype surrounds Angular and React simply due to Google and Facebook backing them.<p>Don't get me wrong. I also like React. However, the hype is a little unwarranted. People treat it as if it's the end-all, be-all way to write JS from now until the end of time.
AmpersandJS (<a href="http://ampersandjs.com" rel="nofollow">http://ampersandjs.com</a>), which is more a set of rules for modular libraries than a framework (but it's still a framework).<p>1. One or two weeks to learn and let it start sinking in.<p>2. Speed: probably 3. I can make the code do what it needs to without much effort.<p>3. Quite maintainable. In fact, I've contributed a few bug fixes and feature improvements to the source repos. In my own code, making changes also happens quickly.<p>4. I chose it after reading Human Javascript (<a href="http://humanjavascript.com" rel="nofollow">http://humanjavascript.com</a>) (which AmpersandJS is based on) and poking around with the boilerplate generator app. It all instantly clicked.
Angular<p>1. 2 months<p>2. 3 (and code reuse is great)<p>3. 3<p>4. Directives is a greatest idea we had in 2011<p>Those who are writing "15 hours" to learn a framework - I think it's the time to read basic APIs, not the time needed to learn how to write effective and reusable code, not "it works!" mess.
At my job we're starting to use angular as it helps us separate business logic from UI and even IO.<p>1. I would say no more than 2 hours at worse. The biggest issue for me is understanding the creation of methods for an object (I'm use to C# and Java, so JS is generally alien to me).<p>2. 1.5 - 2.<p>3. 2.5 once you have the core logic for your object models laid out.<p>4. Because it was what my employer mandated, unfortunately, I prefer Knockout but it all seems to the same in terms of end result. There's minor differences in terms of templating your pages such as for tabular data. The rest seems to be purely a matter of preference and familiarity.
Been using all kinds of frameworks going back to PureMVC and RobotLegs in AS3, backbone and Angular in JS. Built a great many sites small and large.<p>I finally made the step to make my own framework, utilizing the best parts of what I've come across. The first version was ok, but the thirds version that I'm currently using makes me a blazing fast Javascript contractor.
We're running production apps based mostly on Knockout.js and jQuery. We also use lodash and moment.<p>The problem with getting stuck into one particular framework is that then become an "X" programmer, not a web programmer. If you need a fully fledged bells and whistles one though, Angular is probably top dog at the moment.
I'm using intercooler.js:<p><a href="http://intercoolerjs.org/" rel="nofollow">http://intercoolerjs.org/</a><p>It's kind of an crypto-javascript front end framework in that it makes AJAX a declarative, HTML-based tool, so the isomorphism is with respect to HTML and more traditional web development, rather than with respect to server side logic. There are events and a JS API to hook into to, though.<p>The docs lay out the isomorphism:<p>---<p><pre><code> <a href="http://intercoolerjs.org/">Get Intercooler</a></code></pre>
This tells a browser:<p>"When a user clicks on this link, issue an HTTP GET request to '<a href="http://intercoolerjs.org/'" rel="nofollow">http://intercoolerjs.org/'</a> and load the response content into this browser window".<p>Intercooler builds on this simple concept:<p><pre><code> <a ic-post-to="/button_click">Click Me!</a>
</code></pre>
This tells a browser:<p>"When a user clicks on this link, issue an HTTP POST request to '/button_click' and load the response content into this element".
Would you be able to share your findings? Not the thesis, just a (very) short summary of anything interesting that you found. There are 46 other comments as I write this, and sooooooooo many frameworks being used.
I use Meteor.js and I love it. As for time needed to learn the framework, I'd suggest 80 hours. Overall development speed, 3. Maintainability of the code -- can't judge yet.
A place to share which framework you use and why you use them? <a href="http://www.stackbus.com/" rel="nofollow">http://www.stackbus.com/</a>
This question is asked ad nauseum on any web forum of any type. Can't you just visit those and glean the same answers? You could get new answers on an almost daily or weekly basis from the same sites and those answers change annually.