7 ms·

Ask HN: Which JavaScript frameworks do you use?

• ramtatatam 11y ago
  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 :-) 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 linked-in dust: 1) ~1 hour 2) 3 3) 3 4) cross-browser compatibility, small size, one of the fastest jQuery-ui: 1) ~1 hour 2) 3 3) 3 4) cross-browser compatibility, granular control over what features I deploy
  • warfangle 11y ago
    I'd argue that none of those are frameworks: they're utility belts.
• kenbellows 11y ago
  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
• nazrak 11y ago
  In my job we use Angular 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. 2. At first it's like 2.5, but when strange things start happening, it can slow to about 2. 3. I would say 2.4 4. It was really popular, has a lot of resources available and made development really easy. Now for my personal projects I'm learning ReactJS 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. 2. Productivity can be a little worse than angular with 2.0, but results are much better. 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 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. I hope it helps you, sorry for my english.
  • hmottestad 11y ago
    I'm in your camp. Used angular for 2 years at work, and for a bunch of personal stuff. Now I'm trying out react, and even though it uses 10-100x as many lines as angular to do simple things. I'm hoping that for more advanced systems it will be on par, with better modularity and maintainability. Performance is a + with react. Even though you can build performant systems with angular, it just seems to come more natural with react.
• simulo 11y ago
  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).
• jononomo 11y ago
  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.
• crabasa 11y ago
  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 learn Angular. 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: 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? You might learn some very interesting things about the web as a platform and JavaScript as a language.
  • mod 11y ago
    Hopefully they can at least self-report on what they're using professionally. I also wouldn't trust any 'number of hours to learn' responses. I've been working in React/Flux for one project, and though I was writing code within maybe 4 hours, I'm still learning the framework after ~2 weeks. I'm also not typically a front-end guy, so that is relevant.
    • crabasa 11y ago
      A couple of things: 1) You will likely see in the comments that developers will self-report that whatever FRAMEWORK X they are using right now is amazing. Super fast and super maintainable. It's just the nature of how people feel about their current tool of choice. 2) I think it's fascinating that unlike native/mobile application development, there is no clear and dominant application framework for the web. I think this is a topic worth exploring IMHO.
  • ccordle 11y ago
    There are many frameworks because there are many, many JS programmers. The web is the farthest reaching platform you can code on, and as a result, there are more programmers targeting the web than any other platform. As a result, you get a diversity of frameworks to choose from. Frameworks like Angular and Flux/React offer different paradigms of development and there's nothing wrong with that.
  • 11y ago
• nailer 11y ago
  ractive. It's the best kept secret in web development. Want a live binding, 2 way, super performant virtual DOM, that feels less like a framework and more like something that came with JavaScript? var binding = new Ractive({ el: '.some-class', template: '<p>Hi there {{ name }}</p> <input value="{{name}}"/>', data: { name: 'Alex' } }) It's created and maintained by The Guardian interactive team. http://www.ractivejs.org/ http://www.ractivejs.org/ ## Time needed for Learning the Framework (in Hours) The basics take 30 seconds because almost everyone is familiar with handlebars/mustache templates, but 4 hours total. 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. ## Overall Development Speed (0-3 Points, greater better) Development speed: 3. It's insanely fast to work with because it's simple. ## Maintainability of the Code (0-3 Points, greater better) Maintainability: 3. it's small, so super readable. ## Why did you choose that Framework? 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.
  • jFriedensreich 11y ago
    I also use ractive for everything i can. Everytime i have to work with something else i want to shoot myself in the head after some time.
  • rmurri 11y ago
    Also using ractive here. Very happy with it.
  • kitd 11y ago
    Agreed. I very much appreciate tools that do one thing well, and Ractive falls exactly in that category. DeloreanJS [1] complements it well for Flux-y architectures. [1] - http://deloreanjs.com/ http://deloreanjs.com/
  • callum85 11y ago
    "best kept secret in web development" – agreed, Ractive has the lowest hype:quality ratio of any library I've used. It makes React look over-engineered and slow (and React is one of the best).
• sharavsambuu 11y ago
  EmberJS, once u learned it u will get enormous amount of productivity. 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) 2. I would give point 3 3. also 3 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 sorry my bad english.
• joeyspn 11y ago
  Let the framework wars begin...
• diverted247 11y ago
  http://vuejs.org/ http://vuejs.org/ 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.
• warfangle 11y ago
  ReactJS + webpack, though I've used Angular and browserify in the past. 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.' 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. 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. 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."
  • ronjouch 11y ago
    > 3. [...] The favored test runner, Jest, provides automocking for dependencies and code coverage analysis. 3/3. Thanks for sharing! A few questions about Jest: a. Are you happy with Jest auto-mocking? How do you keep a team from banging its head on this "exotic" behavior? (Typically, devs would be stuck on a test for a few hours, only to notice they failed to unmock something in the chain being tested). Have you tried the alternative of eschewing Jest and doing vanilla Jasmine, including lots of mocks? b. You mention "code coverage analysis". Is it working now? Last time I used it, it was broken and in need of a dependency (Istanbul) revamp/upgrade. c. Do you do "semi-end-to-end" DOM tests (i.e. those booting a micro Selenium-like browser/js environment [1] and letting you do DOM assertions like `findRenderedDOMComponentWithClass` and others at [2])? Last time I worked with React, the team initially loved the ability to do those (as an in-between of unit tests & real end-to-end tests) but after adding a bunch of them, tests took 2min to run instead of 2s, and we were considering removing/splitting them. [1] Don't quote me on that, I have no idea how these environments work but it's certainly not Selenium :P . BTW, can anyone detail the machinery / underlying engine making those work? [2] https://facebook.github.io/react/docs/test-utils.html https://facebook.github.io/react/docs/test-utils.html
• neals 11y ago
  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. 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.
  • robmcm 11y ago
    > makes me a blazing fast Javascript contractor ... and a nightmare to the poor developer that has to maintain it.
• justwannasing 11y ago
  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.
• egeozcan 11y ago
  My choice is React.js 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. 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. 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 never happen. 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.
• omgtehlion 11y ago
  http://vanilla-js.com/ http://vanilla-js.com/
  • deleted 11y ago
    [deleted]
• d_luaz 11y ago
  A place to share which framework you use and why you use them? http://www.stackbus.com/ http://www.stackbus.com/
• deleted 11y ago
  [deleted]
• y0ghur7_xxx 11y ago
  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: - form2object for form serialization - pnotify for notifications - routie or page.js for routing - jqplot for graphs - jquery for dom manipulation and ajax calls - moment.js for date math - socket.io for websockets - ejs for templating - bootstrap for the layout and not much more really. 1. Time needed for Learning the Framework (in Hours): A few months to learn JS really well 2. Overall Development Speed (0-3 Points, greater better): 2 3. Maintainability of the Code (0-3 Points, greater better): 3 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.
  • robmcm 11y ago
    > 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. This is a very valid point and something we consider a lot as our application will likely take 5 years to be production ready. However for the vast majority of projects they will be dead before the next big thing arrives, and frameworks really help as a one stop shop for most of what you need.
• ralmidani 11y ago
  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). 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. 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. 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. 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. Edit 2: fixed a typo.
• deleted 11y ago
  [deleted]
• steven777400 11y ago
  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. 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. 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.
  • hardwaresofton 11y ago
    Have you started using the new components available in knockout? http://knockoutjs.com/documentation/component-overview.html http://knockoutjs.com/documentation/component-overview.html As a knockout enthusiast I was excited to see that get developed.
    • steven777400 11y ago
      Yes (and I like them too), but I don't put the template as text. Instead I use one JS and one HTML file per component, loaded with require.js.
      • hardwaresofton 11y ago
        Yeah I'd imagine most people don't use the template as text -- one of the best parts about knockout is it's natural (HTML) feeling templates. What do you use for routing? I've been dreaming up a framework that's actually knockout +/- routing +/- requirejs +/- model management...
        • steven777400 11y ago
          I haven't done any client-side routing. Normally each page is either static HTML/JS or is served by ASP.NET MVC on the server side. Then APIs are used to load the models on the client side and perform interaction. In other words, we're not making any effort to move to "single page" applications.
• norea-armozel 11y ago
  At my job we're starting to use angular as it helps us separate business logic from UI and even IO. 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). 2. 1.5 - 2. 3. 2.5 once you have the core logic for your object models laid out. 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.
• rish 11y ago
  I like Mithril which is similar to React/Ractive. https://lhorie.github.io/mithril/ https://lhorie.github.io/mithril/ It doesn't abstract away too much from JavaScript and provides good methodologies as outlined in the Learn/Guide section of the site. As per your points: 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. 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. 3. This would be on a medium scale level depending how you couple your code and how modular you keep it. 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.
  • bpicolo 11y ago
    If the benchmark claims are true I think it'd be super cool! Would have to see for myself though.
• jcadam 11y ago
  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. 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 :)
  • ralmidani 11y ago
    It depends on how large your projects are. At some point, the time required to learn an "uber-framework" like Ember is eclipsed by the time needed to implement things not included with a smaller framework like Backbone.
• clschnei 11y ago
  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. I'm actually pretty excited the see React/Meteor happening since it provides a similar paradigm.
• techpeace 11y ago
  I use Marionette: http://marionettejs.com/ http://marionettejs.com/ 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. 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. 3. 3, but see caveat from #2. Depends on how you write your code, really. 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.
  • hardwaresofton 11y ago
    I'm surprised you didn't mention backbone once... Are you using marionette without backbone? BTW, skeletor here (I think we may have worked together before, very very recently)
    • techpeace 11y ago
      Haha, hey man! No, it's not really possible to decouple Marionette from Backbone, I just don't like typing "Backbone Marionette" every time, so I just use "Marionette." But for the uninitiated, Marionette is indeed a layer on top of Backbone.
• abrkn 11y ago
  frontend: react + react-router + redux. pack with webpack
• dhritzkiv 11y ago
  AmpersandJS (http://ampersandjs.com http://ampersandjs.com), which is more a set of rules for modular libraries than a framework (but it's still a framework). 1. One or two weeks to learn and let it start sinking in. 2. Speed: probably 3. I can make the code do what it needs to without much effort. 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. 4. I chose it after reading Human Javascript (http://humanjavascript.com http://humanjavascript.com) (which AmpersandJS is based on) and poking around with the boilerplate generator app. It all instantly clicked.
• carsongross 11y ago
  I'm using intercooler.js: http://intercoolerjs.org/ http://intercoolerjs.org/ 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. The docs lay out the isomorphism: --- <a href="http://intercoolerjs.org/">Get Intercooler</a> This tells a browser: "When a user clicks on this link, issue an HTTP GET request to 'http://intercoolerjs.org/' http://intercoolerjs.org/' and load the response content into this browser window". Intercooler builds on this simple concept: <a ic-post-to="/button_click">Click Me!</a> This tells a browser: "When a user clicks on this link, issue an HTTP POST request to '/button_click' and load the response content into this element".
• sergiotapia 11y ago
  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. 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. 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. 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. 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. --- 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: http://stackshare.io/meteor http://stackshare.io/meteor
  • chrisquinnr 11y ago
    For 1), the hardest part for me coming from LAMP stack apps was shifting over to the way routing works (see https://github.com/iron-meteor/iron-router https://github.com/iron-meteor/iron-router) and attaching your subscriptions to routes. For 3) I've used meteorchef's excellent base package (https://github.com/themeteorchef/base https://github.com/themeteorchef/base) for two big projects so far and it's great.
    • sergiotapia 11y ago
      FWIW don't use IronRouter. It's considered an antipattern now to tie your router to your subscriptions and generally to have reactivity in your router. Use FlowRouter and BlazeLayout, both found on Atmosphere. It's like yeah Martini is popular in the Go ecosystem, but it's now considered bad to use now that people know better.
• joshburgess 11y ago
  Aurelia. http://aurelia.io http://aurelia.io https://github.com/aurelia https://github.com/aurelia 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. 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. 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.
• lobo_tuerto 11y ago
  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. I found Aurelia and I think it's the next one I'll learn and use in my projects: http://aurelia.io/ http://aurelia.io/ 1. You can do the tutorial in an hour or so, and get the general idea in I'd say about 4 hours. 2. From what I've seen it'd be a 3. 3. Looks like a 3 too! 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: http://blog.durandal.io/2015/07/23/creating-reactive-loosely-coupled-apps-with-aurelia-and-flux-episode-1/ http://blog.durandal.io/2015/07/23/creating-reactive-loosely... Also there's been some discussions comparing Aurelia to Angular2 and well, seems like Aurelia has the best architectural decissions in, for example: http://blog.durandal.io/2015/03/17/aurelia-angular-2-0-code-side-by-side-part-2/ http://blog.durandal.io/2015/03/17/aurelia-angular-2-0-code-... 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). It also supports modern Javascript (ES2015/ES2016) from the start (with Babel).
• arenaninja 11y ago
  So naturally, I've used jQuery for a few years now: 1. Time to learn: I think 1-2 hours 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 3. Maintainability: 1. Keeping track of selectors grows to be very tricky business. 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. I have also used ReactJS: 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 2. Development speed: 2. There's a lot of boilerplate involved (usually render, getInitalState, getDefaultProps) 3. Maintainability: 3. Easily the most maintainable and reusable JS code I've ever written 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
• vijayr 11y ago
  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.
• talves 11y ago
  Make sure before you include some of the recommendations here that they are truly an Isomorphic Javascript Framework and not just UI libraries.
• substack 11y ago
  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. 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: * https://github.com/substack/virtual-dom-starter https://github.com/substack/virtual-dom-starter - bare-bones main-loop + virtual-dom setup * https://github.com/substack/virtual-dom-universal-starter https://github.com/substack/virtual-dom-universal-starter - universal (front+back)end js example with shared routing and single-page pushState 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: https://github.com/substack/virtual-dom-unidirectional-example https://github.com/substack/virtual-dom-unidirectional-examp... If jsx is your thing, I made an example of setting up jsx in virtual-dom land too: https://github.com/substack/virtual-dom-starter-babel-es6-jsx https://github.com/substack/virtual-dom-starter-babel-es6-js... 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: 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.
• doobiaus 11y ago
  We're running production apps based mostly on Knockout.js and jQuery. We also use lodash and moment. 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.
• EugeneOZ 11y ago
  Angular 1. 2 months 2. 3 (and code reuse is great) 3. 3 4. Directives is a greatest idea we had in 2011 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.
• ackava 11y ago
  For first three points, I will say Atoms.js is very fast to learn and easy to maintain. Fur fourth point l will say I built it.