Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we left AngularJS

sourcegraph.com

Post reply on HN
Print view View original

61–70 of 168 posts

Re: Why we left AngularJS

#61

Post by uptown »

EC1 wrote: post #32
dchuk wrote: post #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 renderi…

What would you use for a public facing application?

I recommend PJAX. It degrades gracefully for search engine indexing.

Re: Why we left AngularJS

#62

Post by encoderer »

dchuk wrote: post #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 renderi…

Totally agree, but you still have the analytics/tracking problems. Unless you're not tracking clicks/activities/views on your various features. But if that's the case, you have bigger problems :)

Re: Why we left AngularJS

#63

Post by darrellsilver »

dchuk wrote: post #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 renderi…

The Blogger example doesn't seem fair: Any app can overload the user with too many animations or other distractions.

At Thinkful (http://www.thinkful.com/) we're building our student / education app in Angular, and are moving all browser-side code to Angular as well – both public and private.

In a lot of our splash or SEO-enabled content we're not making use of all of angular's features, but the upside of using it is that we have a single, unified codebase in which we can share libraries, team knowledge and design patterns. Simply put: Using Angular everywhere allows us to keep DRY. Testing the front-end using purely Angular is yet another core asset at Thinkful.

One framework for writing code and testing is much better than a hybrid of server-side rendering and Angular.

Our biggest challenge was SEO, but this was reasonably easily solved with using BromBone (http://www.brombone.com/).

There are reasons to stick with non-angular or JS frameworks, so it's not always a slam-dunk. For example, if Thinkful had millions of SEO pages that we needed to load as fast as humanly possible Angular would be a bit much... But that's not what we're optimizing for: We're building a phenomenal user-experience that we can support long-term, is well tested, can have a lot of developers use, and can have non-developers do their job inside our codebase (everyone at Thinkful codes).

For all this and more Angular has proven a great choice for both logged-in AND public sites.

Re: Why we left AngularJS

#64

Post by carsongross »

srgpqt wrote: post #52
carsongross wrote: post #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-directiv…

I think this method is the way forward for most document based sites/apps. Last year I built something similar to intercooler (nice lib btw) for our product to great success. Makes things so much simpler to develop and maintain.

Thanks man. Please, clone. I barely have any idea what I'm doing. ;)

Re: Why we left AngularJS

#65

Post by wheaties »

I just want to say thank you to the author for showing me backbone.anayltics. Absolutely fantastic and everything I had been looking for recently. Funny how one thing teaches about something else.

Re: Why we left AngularJS

#66

Post by onedognight »

cozuya wrote: post #23
untog wrote: post #12

Earlier quoted context omitted.

As someone who is familiar with AngularJS but hasn't used it much, the idea that the best answer running WebKit on the server, indexing your client-side generated pages and dumping them out into a Google-indexable static resource just blows my mind .

What's really interesting is that "google" didn't see this coming - they made angular, they should in theory be huge advocates of SPA, but in reality their primary product doesn't support it well at all.

Googlebot renders client side JS just fine. Notice how the OP didn't list them and instead listed FB/Twitter.

Re: Why we left AngularJS

#67

Post by Navarajan »

Yes Client side rendering will not give any advantages for static contents, Its more useful for Dynamic content providing applications.

And if you want to deliver your content in mobile devices with there native app then Client Side Framework will be handy for you.

Re: Why we left AngularJS

#68

Post by flaxin »

balls187 wrote: post #55

This isn't about AngularJS in particular. This is about using a client-side JS app framework. Substitute any other flavor and the same problems exist.

the title is misleading - it should have said 'client side js frameworks are bad'

keep in mind that client side JS have to work with the DOM - which is pretty awful

Post reply on HN