5 ms·

Interesting coincidence. This week I've been tasked with looking into a JavaScript framework to replace our pure-Clojure stack at work. One of the front-end ca

Interesting coincidence. This week I've been tasked with looking into a JavaScript framework to replace our pure-Clojure stack at work. One of the front-end candidates is Angular. But we're considering cutting it from the race. The three main things we're looking for in a front-end framework: 1. Longevity: we don't want to adopt yet another fad framework that we'll have to replace in 2017. The current trend looks to be moving towards React-style FRP, and Angular seems to be catching up in version 2, but nobody seems to be using that yet, which means nobody will start using it. It looks like another Python 3 problem to me. I don't see Angular lasting long. 2. Flexibility: we want to quickly be able to change what pages we have and what's on them, without needing to tear down and rewrite the entire front-end. If Angular is only just now beginning to adopt React-like patterns, how can I be assured that it got them right, and that I won't run into rigidity issues 2 weeks into writing Angular code? 3. Convention over configuration: our data will live in MongoDB, so all our models are straightforward JSON. I'm hoping to find a stack that assumes this and doesn't require me to write tons of boilerplate that should be assumed for me by my frameworks. I'm not sure how Angular fares in this, but so far none of the candidates really shine in this area. For the record, we're currently looking into Sails + Ember + Mongo. But we're not super excited about this since it still doesn't look like it'll hit all three of our needs really well. I'm particularly concerned that Ember is going to have the same issues as Angular, especially if the community is looking to regularize tools around React.

Hendrixer 10y ago
React is great, but it's just a lib. Angular 2 is in release candidate 4, and there are already ton of people using it. If you want a complete solution, I'd use Angular. TypeScript is awesome too. Angular comes with all the stuff you need, http, animations, routing, etc. I wouldn't cut it out just yet, seeing how it's on the horizon.
- _alexander_ 10y ago
  Could you share real projects(not todo-like applications) which use NG2?
  - ergo14 10y ago
    Not NG2, but people for some weird reason try to ignore polymer here - and you have plenty of real-life appications starting from Google Music and Youtube to EA Battlefield1 and IBM and General Electric tools.
JustSomeNobody 10y ago
> Longevity: we don't want to adopt yet another fad framework that we'll have to replace in 2017. No such thing. They're all pretty much fad frameworks.
- sdegutis 10y ago
  Looking back, though, I might have said the same thing about Rails or Sinatra or Laravel, but they stood the test of time, and people still use them. A lot of what gives a framework longevity is just whether or not big players adopt them and developers love them, these two factors will go a long way in ensuring a framework continues to get upgrades and continuous maintenance. At least longer than Backbone, anyway.
  - davidw 10y ago
    So Angular is the COBOL of Javascript frameworks? Actually, I think it's probably more comparable to some kind of Java FactoryProviderServiceFactory thing.
- rendezvouscp 10y ago
  JavaScriptMVC/DoneJS has a pretty long history: http://blog.bitovi.com/longevity-or-lack-thereof-in-javascript-frameworks/ http://blog.bitovi.com/longevity-or-lack-thereof-in-javascri... CanJS, the MVVM part of DoneJS, is currently coming up to its third major/breaking version. I think that’s a pretty good track record for us/Bitovi.
ausjke 10y ago
sails + vuejs + postgresql will be my choice.
- sdegutis 10y ago
  Interesting. How will you handle dynamic front-end routing though? Or will you rely entirely on Sails for server-side routing?
- Hendrixer 10y ago
  Take a look at Feathers js, so much better than Sails
  - ausjke 10y ago
    Thanks. Saw this somewhere before but it's less known. The good part of feathers.js is that it does express4, and I think sails.js is still with express3.
whatever_dude 10y ago
Can't comment on 2 and 3, but for 1... I'd say it's the opposite. I believe the Angular team took a long, hard look at what was working with React (and others) and that's why they decided to take their time to get Angular 2 right. If anything, React-* is the stack that has a longevity problem from my point of view. Everything I do on the web I use React, and my impression is that even if I'm using a modern stack, everything breaks 6 months later because things have changed considerably. Many of the extensions React naturally need either fall out of fashion, or go through deep changes, or are just not that good. On every new project I assemble, I start from the assumption the architecture will be outdated very fast. I hope Angular will make that kind of stuff a bit more solidified. We don't need a new store solution on every new project.
mmargerum 10y ago
Sounds like Aurelia might be a nice match. Much less boilerplate
pbreit 10y ago
If it's an internal app or if it otherwise doesn't need to be single-page-app, save yourself some brain cells and do something simple like Rails or Django. If JavaScript is absolutely required, stick with Sails/Mongo and skip the Ember/Angular SPA.
- sdegutis 10y ago
  How does that help with a rich front-end? We're not looking to use JavaScript simply for the sake of using JavaScript. We want it in particular for a richer front-end. As far as I can tell, Sails isn't going to help with that any more than Rails does. That's why we're looking into Ember or Angular.
  - pbreit 10y ago
    OK, wasn't clear to me that "rich front end" was important or necessary. I see a lot of projects choose JS front-ends because they are neat or cutting edge, not because they are useful or necessary.
  - rimantas 10y ago
    What is reach front end? The one where you wait your js to arrive only for it to issue own API calls, then wait data to arrive, then it to be parsed and finaly shown? It would not surprise my if some dumb turbolinks staff would beat a lot of fancy frameworks performance an UX wise.
    - nilliams 10y ago
      > What is reach front end? The one where you wait your js to arrive only for it to issue own API calls, then wait data to arrive, then it to be parsed and finaly shown? No, that's your own straw man definition. > It would not surprise my if some dumb turbolinks staff would beat a lot of fancy frameworks performance an UX wise. Turbolinks absolutely does not beat a well written SPA UX-wise.
maxfurman 10y ago
By pure-Clojure stack, do you mean you use ClojureScript on the front end currently? If so, Om and Reagent are both Clojure-y wrappers around React anyway, so that would probably the smoothest transition for your team. And if not, why not? :-)

Hendrixer 10y ago

React is great, but it's just a lib. Angular 2 is in release candidate 4, and there are already ton of people using it. If you want a complete solution, I'd use Angular. TypeScript is awesome too. Angular comes with all the stuff you need, http, animations, routing, etc. I wouldn't cut it out just yet, seeing how it's on the horizon.

_alexander_ 10y ago
Could you share real projects(not todo-like applications) which use NG2?
- ergo14 10y ago
  Not NG2, but people for some weird reason try to ignore polymer here - and you have plenty of real-life appications starting from Google Music and Youtube to EA Battlefield1 and IBM and General Electric tools.

JustSomeNobody 10y ago

> Longevity: we don't want to adopt yet another fad framework that we'll have to replace in 2017. No such thing. They're all pretty much fad frameworks.

sdegutis 10y ago
Looking back, though, I might have said the same thing about Rails or Sinatra or Laravel, but they stood the test of time, and people still use them. A lot of what gives a framework longevity is just whether or not big players adopt them and developers love them, these two factors will go a long way in ensuring a framework continues to get upgrades and continuous maintenance. At least longer than Backbone, anyway.
- davidw 10y ago
  So Angular is the COBOL of Javascript frameworks? Actually, I think it's probably more comparable to some kind of Java FactoryProviderServiceFactory thing.
rendezvouscp 10y ago
JavaScriptMVC/DoneJS has a pretty long history: http://blog.bitovi.com/longevity-or-lack-thereof-in-javascript-frameworks/ http://blog.bitovi.com/longevity-or-lack-thereof-in-javascri... CanJS, the MVVM part of DoneJS, is currently coming up to its third major/breaking version. I think that’s a pretty good track record for us/Bitovi.

ausjke 10y ago

sails + vuejs + postgresql will be my choice.

sdegutis 10y ago
Interesting. How will you handle dynamic front-end routing though? Or will you rely entirely on Sails for server-side routing?
Hendrixer 10y ago
Take a look at Feathers js, so much better than Sails
- ausjke 10y ago
  Thanks. Saw this somewhere before but it's less known. The good part of feathers.js is that it does express4, and I think sails.js is still with express3.

whatever_dude 10y ago

Can't comment on 2 and 3, but for 1... I'd say it's the opposite. I believe the Angular team took a long, hard look at what was working with React (and others) and that's why they decided to take their time to get Angular 2 right. If anything, React-* is the stack that has a longevity problem from my point of view. Everything I do on the web I use React, and my impression is that even if I'm using a modern stack, everything breaks 6 months later because things have changed considerably. Many of the extensions React naturally need either fall out of fashion, or go through deep changes, or are just not that good. On every new project I assemble, I start from the assumption the architecture will be outdated very fast. I hope Angular will make that kind of stuff a bit more solidified. We don't need a new store solution on every new project.

mmargerum 10y ago

Sounds like Aurelia might be a nice match. Much less boilerplate

pbreit 10y ago

If it's an internal app or if it otherwise doesn't need to be single-page-app, save yourself some brain cells and do something simple like Rails or Django. If JavaScript is absolutely required, stick with Sails/Mongo and skip the Ember/Angular SPA.

sdegutis 10y ago
How does that help with a rich front-end? We're not looking to use JavaScript simply for the sake of using JavaScript. We want it in particular for a richer front-end. As far as I can tell, Sails isn't going to help with that any more than Rails does. That's why we're looking into Ember or Angular.
- pbreit 10y ago
  OK, wasn't clear to me that "rich front end" was important or necessary. I see a lot of projects choose JS front-ends because they are neat or cutting edge, not because they are useful or necessary.
- rimantas 10y ago
  What is reach front end? The one where you wait your js to arrive only for it to issue own API calls, then wait data to arrive, then it to be parsed and finaly shown? It would not surprise my if some dumb turbolinks staff would beat a lot of fancy frameworks performance an UX wise.
  - nilliams 10y ago
    > What is reach front end? The one where you wait your js to arrive only for it to issue own API calls, then wait data to arrive, then it to be parsed and finaly shown? No, that's your own straw man definition. > It would not surprise my if some dumb turbolinks staff would beat a lot of fancy frameworks performance an UX wise. Turbolinks absolutely does not beat a well written SPA UX-wise.

maxfurman 10y ago

By pure-Clojure stack, do you mean you use ClojureScript on the front end currently? If so, Om and Reagent are both Clojure-y wrappers around React anyway, so that would probably the smoothest transition for your team. And if not, why not? :-)