Hacker News Reader

Comment by jMyles | Hacker News Reader

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?

View on HN

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.

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.

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.

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.

Meta: digging the downvotes in lieu of actual discussion here. Stay classy.

The comment above yours is a giant, unbroken paragraph of dogma. I'd say it's worthy of downvotes.

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

My front-end guy is totally sold on react/flux.

He came to that decision just after we committed to angular... :(

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.

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.

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

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.

>are worst than the bad parts in React

Which are...?

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

what is your opinion about Backbone.Marionette. i have been looking at it for a while but have not jumped in

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.

HTML and JavaScript?

Reply on news.ycombinator.com