Live data from Hacker News

Why we left AngularJS

sourcegraph.com

1–10 of 168 posts

Re: Why we left AngularJS

#3
I've been working on an Angular alternative called IntercoolerJS:

http://intercoolerjs.org/

The idea is to keep a lot of the advantages of the traditional web development model, but, via HTML5-style attributes, RESTful URL design and partial driven UX, achieve a better UX.

It's not for everyone or for every problem, and it is still in pre-alpha (we are going to change from a preamble to HTTP headers for meta-directives, for example) but, if you find Angular too heavy-weight and foreign for your UI, it might be of interest.

Please contact me if you are interested in contributing.

Re: Why we left AngularJS

#4
post #2

[deleted]

It's funny because I find myself going the other direction from server-side page generation to angular.

One of the main reasons is angular forces you to separate your controller logic from DOM manipulation. Without directives I tend to see a pile of jQuery on every page.

How do you address this?

Re: Why we left AngularJS

#5
I’m as big an Angular evangelist as anyone, but that bit about search rankings is an absolute killer.

You talk about these server-side webkit parsers as tricks that “slow things down,” which indicates that you at least ultimately got them working. I never got that far.

Re: Why we left AngularJS

#6
I am curious to know why you go for a full js app approach from the begining, knowing that your app would be very dependable from content that needed be indexed by search engines overall?

Re: Why we left AngularJS

#7
post #4
post #2

[deleted]

It's funny because I find myself going the other direction from server-side page generation to angular. One of the main reasons is angular forces you to separate your controller logic from DOM manipulation. Without directives I tend to see a pile of jQuery on every page. How do you address this?

The separation between DOM and logic is indeed a nice part about AngularJS. We took a look at how much client-side logic our particular site actually needed, and it was much less than we thought. Most of the page logic can be implemented using Go's template library's own AngularJS-like server-side templates. We implemented the remainder in jQuery, which you can see at https://sourcegraph.com/static/js/web.js. (If someone in the future comes along and that link is 404, email me at sqs@sourcegraph.com if you want to see it.) It's actually a surprisingly small amount of code.

So I would say you should ask yourself how much of your controller logic needs to be done on the client? If most of it can be done on the server, then the amount of jQuery you need will probably be quite manageable.

Re: Why we left AngularJS

#8

I’m as big an Angular evangelist as anyone, but that bit about search rankings is an absolute killer. You talk about these server-side webkit parsers as tricks that “slow things down,” which indicates that you at least ultimately got them working. I never got that far.

[deleted]

Re: Why we left AngularJS

#9
post #6

I am curious to know why you go for a full js app approach from the begining, knowing that your app would be very dependable from content that needed be indexed by search engines overall?

(OP here) This was definitely a bad choice on our part (my part, as I'm the one who made the decision originally). It was super simple to get started with AngularJS, and I had a fair bit of experience with it. Part of the motivation for this post is to tell other developers in a similar position (who have used AngularJS/Ember/etc. in the past and are starting on a new project) that they should consider server-side generated pages as well, even though they are often considered old-fashioned.

Re: Why we left AngularJS

#10
A lot of people seem to think that Single Page App frameworks like Angular/Ember are suitable for use on the public facing client side. I've always believed that SPAs are meant to be behind a login, where you don't have to also deal with spiders and other sub-optimal browsing devices, and you have a little bit more wriggle room when it comes to routing and web history.

Just look at Blogger...their client-side rendering is annoying as all get out. It's just a blog post, render it server side and give me the content, then sprinkle on some gracefully degrading JS on top to spice it up.

I say this as a huge proponent of Angular who uses it for all his web app projects who also wouldn't ever use it on a public facing application.

Post reply on HN