8 ms·

If Angular is not The Thing (a premise which I have no trouble believing), then what is a Good Thing to perform the task of, for example, consuming Django Rest

by jMyles 12y ago

If Angular is not The Thing (a premise which I have no trouble believing), then what is a Good Thing to perform the task of, for example, consuming Django Rest Framework endpoints and making a frontend of them?

andybak 12y ago
My front-end guy is totally sold on react/flux. He came to that decision just after we committed to angular... :(
- pedalpete 12y ago
  I was fairly sold on react/flux after trying it because it is very simple and you can build very quickly. I've been trying Mercury.js over the last week as I thought the 'cycle' of flux/react was a bit more than necessary. Your front-end guy might be sold on Mercury next.
  - antihero 12y ago
    I did initially think the cycle of flux was a bit too much, but since having to have actions be created from various sources, etc, I've come to realise that it's actually a really good balance. Having a glance at Mercury. Looks interesting, but react is working so well for my projects I'd need a damn good reason to give it up.
  - MrBuddyCasino 12y ago
    Looks very clean, thanks for bringing this up. It might be a good cultural fit for Clojure devs, which is why I'm going to have a closer look. To save the next guy some googling: https://github.com/Raynos/mercury https://github.com/Raynos/mercury
- scardine 12y ago
  At first I was pretty sold on react too. Now I'm trying to figure out if the bad parts in Angular are worst than the bad parts in React. I don't have an answer yet. The only thing I'm sure is that the virtual-DOM thing is a good idea and most frameworks are likely to converge here.
  - ttty 12y ago
    >are worst than the bad parts in React Which are...?
shawabawa3 12y ago
HTML and JavaScript?
sebslomski 12y ago
Personally, I use Angular for Backoffice tools and Backbone.Marionette for customer facing frontends.
- misiti3780 12y ago
  what is your opinion about Backbone.Marionette. i have been looking at it for a while but have not jumped in
  - acemarke 12y ago
    If you're using Backbone, Marionette is pretty much a must-have. It provides some great classes for common Backbone use cases like rendering a template and showing views for models in a collection. It also provides some additional application-level abstractions. Fills in a lot of common boilerplate and functionality. My current app is actually still back on Marionette 1.0.4 for various reasons, so I'm not as familiar with the changes in the latest versions of Marionette. Looks like they've added a considerable amount since then.
gasping 12y ago
It's ReactJS. See my previous comments and surrounding comments for some discourse.
grey-area 12y ago
Perhaps also consider whether front-end frameworks are a Good Thing given your requirements? Many of the largest sites on the internet don't use them in any significant way, and you could just as easily use Django to server HTML/CSS to browsers, as well as a Rest endpoint for mobile apps or other users of your data.
- crdoconnor 12y ago
  I think in a lot of cases they actually aren't a good thing at all. I have used a fair number of websites recently which used front end frameworks badly and ended up causing all sorts of havoc (not being able to save the page, random {{ things like this }} appearing all {{ over }} the place at inconvenient times, pages just not loading, janky controls, etc.) In short, bugs that don't happen when you have static web pages and forms and a smatter of javascript. In almost all of these cases I think users would likely not have noticed a substantive difference between an angular-style web app and simple HTML forms.
joshcrowder 12y ago
It depends if you actually need one. Do you need a full javascript frontend or can you sprinkle JS on top. I'm a huge fan of Backbone. Its small enough to learn the in's and outs of it and also allows you to control the structure / design of the application. This definitely has pro's and con's but for us it means we can swap developers and theres a design pattern thats easy to understand and implement. We're actually building a pretty large Ember project at the moment (a project management tool called Matterhorn). Its been a great experience and we're planning on using it for all of our client projects going forward. The learning curve is a little high and the 'plugin' eco-system is lacking to say the least. I actually think this is a good thing though as most people write terrible plugins. Roll your own and own it.
atirip 12y ago
IMHO Good Thing is to have set of libraries and not a framework at all. Start with handcrafting all HTML,CSS with interactions you need. You HTML skeleton will depend greatly on what you want to achieve - like when one page changes to other and theres a ajax call between - where you put the wait screen: as separate, on old page, then wait, transit to new at once, then wait and so on. If that is done you know broadly what you need. Example configuration may be React for rendering, cherry picked Model (or State) from Ampersand, Backbone Events Standalone for event bus. Something for History/routes too, can't recommend anything specific because my projects did not had one (yes, you can build web-app without back button support). This way if something better comes up, you can switch, if something is abandoned, gets your way, you can switch. Or you can rewrite it in-house fairly easily. I imagine that when you discover that React is too much, too heavy, too bloaty (for example, i'm not saying, that it is, we are happy React users now), then preserving all API calls and replacing it with few lines of Mustache templates is doable. Not trivial, but doable.
- deleted 12y ago
  [deleted]
- mattgreenrocks 12y ago
  Meta: digging the downvotes in lieu of actual discussion here. Stay classy.
  - cloakandswagger 12y ago
    The comment above yours is a giant, unbroken paragraph of dogma. I'd say it's worthy of downvotes.

by jMyles 12y ago

andybak 12y ago

My front-end guy is totally sold on react/flux. He came to that decision just after we committed to angular... :(

pedalpete 12y ago
I was fairly sold on react/flux after trying it because it is very simple and you can build very quickly. I've been trying Mercury.js over the last week as I thought the 'cycle' of flux/react was a bit more than necessary. Your front-end guy might be sold on Mercury next.
- antihero 12y ago
  I did initially think the cycle of flux was a bit too much, but since having to have actions be created from various sources, etc, I've come to realise that it's actually a really good balance. Having a glance at Mercury. Looks interesting, but react is working so well for my projects I'd need a damn good reason to give it up.
- MrBuddyCasino 12y ago
  Looks very clean, thanks for bringing this up. It might be a good cultural fit for Clojure devs, which is why I'm going to have a closer look. To save the next guy some googling: https://github.com/Raynos/mercury https://github.com/Raynos/mercury
scardine 12y ago
At first I was pretty sold on react too. Now I'm trying to figure out if the bad parts in Angular are worst than the bad parts in React. I don't have an answer yet. The only thing I'm sure is that the virtual-DOM thing is a good idea and most frameworks are likely to converge here.
- ttty 12y ago
  >are worst than the bad parts in React Which are...?

shawabawa3 12y ago

HTML and JavaScript?

sebslomski 12y ago

Personally, I use Angular for Backoffice tools and Backbone.Marionette for customer facing frontends.

misiti3780 12y ago
what is your opinion about Backbone.Marionette. i have been looking at it for a while but have not jumped in
- acemarke 12y ago
  If you're using Backbone, Marionette is pretty much a must-have. It provides some great classes for common Backbone use cases like rendering a template and showing views for models in a collection. It also provides some additional application-level abstractions. Fills in a lot of common boilerplate and functionality. My current app is actually still back on Marionette 1.0.4 for various reasons, so I'm not as familiar with the changes in the latest versions of Marionette. Looks like they've added a considerable amount since then.

gasping 12y ago

It's ReactJS. See my previous comments and surrounding comments for some discourse.

grey-area 12y ago

Perhaps also consider whether front-end frameworks are a Good Thing given your requirements? Many of the largest sites on the internet don't use them in any significant way, and you could just as easily use Django to server HTML/CSS to browsers, as well as a Rest endpoint for mobile apps or other users of your data.

crdoconnor 12y ago
I think in a lot of cases they actually aren't a good thing at all. I have used a fair number of websites recently which used front end frameworks badly and ended up causing all sorts of havoc (not being able to save the page, random {{ things like this }} appearing all {{ over }} the place at inconvenient times, pages just not loading, janky controls, etc.) In short, bugs that don't happen when you have static web pages and forms and a smatter of javascript. In almost all of these cases I think users would likely not have noticed a substantive difference between an angular-style web app and simple HTML forms.

joshcrowder 12y ago

It depends if you actually need one. Do you need a full javascript frontend or can you sprinkle JS on top. I'm a huge fan of Backbone. Its small enough to learn the in's and outs of it and also allows you to control the structure / design of the application. This definitely has pro's and con's but for us it means we can swap developers and theres a design pattern thats easy to understand and implement. We're actually building a pretty large Ember project at the moment (a project management tool called Matterhorn). Its been a great experience and we're planning on using it for all of our client projects going forward. The learning curve is a little high and the 'plugin' eco-system is lacking to say the least. I actually think this is a good thing though as most people write terrible plugins. Roll your own and own it.

atirip 12y ago

IMHO Good Thing is to have set of libraries and not a framework at all. Start with handcrafting all HTML,CSS with interactions you need. You HTML skeleton will depend greatly on what you want to achieve - like when one page changes to other and theres a ajax call between - where you put the wait screen: as separate, on old page, then wait, transit to new at once, then wait and so on. If that is done you know broadly what you need. Example configuration may be React for rendering, cherry picked Model (or State) from Ampersand, Backbone Events Standalone for event bus. Something for History/routes too, can't recommend anything specific because my projects did not had one (yes, you can build web-app without back button support). This way if something better comes up, you can switch, if something is abandoned, gets your way, you can switch. Or you can rewrite it in-house fairly easily. I imagine that when you discover that React is too much, too heavy, too bloaty (for example, i'm not saying, that it is, we are happy React users now), then preserving all API calls and replacing it with few lines of Mustache templates is doable. Not trivial, but doable.

deleted 12y ago
[deleted]
mattgreenrocks 12y ago
Meta: digging the downvotes in lieu of actual discussion here. Stay classy.
- cloakandswagger 12y ago
  The comment above yours is a giant, unbroken paragraph of dogma. I'd say it's worthy of downvotes.