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

51–60 of 168 posts

Re: Why we left AngularJS

#51

Post by est »

untog wrote: post #12
Eric_WVGG wrote: post #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.

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 .

> dumping them out into a Google-indexable static resource just blows my mind.

You can do that, however if you dump static page to Google bot IP only it's an SEO cheating.

Re: Why we left AngularJS

#52

Post by srgpqt »

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.

Re: Why we left AngularJS

#53

Post by dkersten »

lifeisstillgood wrote: post #36
randomdrake wrote: post #25

This mayaswell be titled: "Why we're paying for re-discovering client-heavy apps are hard or bad." Angular, or doesn't particularly matter. Twitter learned it[1]. Lots of us learned it when we were experimenting as Web 2.0 was being born. Things were far more obvious, far more quickly then, as bandwidth and resources weren't anywhere near what they are today. Back then, we quickly realized that just a couple of delay…

That Quora link is behind a sign up wall - would you mind giving a précis? Additionally I have to say Angular (or any client side framework) seems a poor choice for a consumer facing content driven site. Apps are for actively doing something - not passively reading. Of am I missing the point

Append ?share=1 to the end of the URL and no more signup wall.

Re: Why we left AngularJS

#54

Post by m0th87 »

Try prerender [1]. We use it in production with backbone. This combined with keeping the most content not-client-rendered has alleviated most of our issues.

In the long-term I'd love to see a web framework that uses react on the server-side, kind of like how rendr uses backbone on the server-side [2]. Seems to make sense because react works against a virtual DOM, so it would allow you to avoid the hacky ways of working with an actual DOM in node.

1: https://github.com/prerender/prerender 2: https://github.com/airbnb/rendr

Re: Why we left AngularJS

#56

Post by elliottkember »

dchuk wrote: post #46
EC1 wrote: post #32

Earlier quoted context omitted.

What would you use for a public facing application?

Any sort of standard server side rendering, or possibly a front end framework that can be rendered server side as well (I think React can do that, same as Backbone). Basically, SPA frameworks are useful when you are working with lots and lots of data moving back and forth. A good example is something like Intercom.io's interface. They have tons of tables and modals and data flying around. This isn't conducive to the…

> Render it server side, cache it, and fire it to my browser as fast as possible.

Shameless plug, but we've been trying to do something similar with Forge (getforge.com). We built a Javascript library called TurboJS that precompiles a static HTML build into a JS manifest and loads it all. It's SEO-friendly and super-fast. Our other site, http://hammerformac.com/ uses it, for example.

Re: Why we left AngularJS

#57

Post by ben336 »

Maybe I'm missing something but I don't get "4. Slow, flaky tests". I understand that Selenium et al can be a pain, but how does server side generated code excuse you from using it? Are you only validating the html structure and not testing any of the interactive capabilities?

Re: Why we left AngularJS

#59

Post by anonova »

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…

Discourse is essentially a SPA (see http://try.discourse.org/) and designed to be public-facing. It does a good job at providing a very bare, lightweight interface for people with JavaScript disabled and, I'm assuming, for web crawlers.

Re: Why we left AngularJS

#60

Post by spicyj »

est wrote: post #51
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 .

> dumping them out into a Google-indexable static resource just blows my mind. You can do that, however if you dump static page to Google bot IP only it's an SEO cheating.

No, this is explicitly endorsed by Google:

https://developers.google.com/webmasters/ajax-crawling/

Post reply on HN