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

11–20 of 168 posts

Re: Why we left AngularJS

#11

Post by dlau1 »

Have you tried react.js [1] ? If you use node to serve your content, you can pre-render the initial state of your app. When everything loads up, react will take a checksum of the rendered portions to ensure that it doesn't re-render the same DOM. This should come close to solving your SEO/test issues with minimal work.

In my opinion, a setup like this is close to what the next big wave of frameworks will use.

You can break your layout up into parts and have a site that is partially dynamic and partially static. You just pass the html that react renders to your templating engine.

Getting everything setup correctly can be a little hassle, but gulp is fast enough when doing a watch on the compilation step. Of course, because everything is javascript you share the exact same component code between client and server.

This is a good example that helped me a bit[2]

[1] http://facebook.github.io/react/ [2] https://github.com/mhart/react-server-example

Re: Why we left AngularJS

#12

Post by untog »

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.

Re: Why we left AngularJS

#13

Post by cies »

I'm currently playing with Fay (haskell2js compiler)... It's awesome.

It type checks like haskell and allows code sharing between serverside and clientside of the app. This means i can use code to generate a complete HTML site (for SEO purposes) when the URL is hit directly and modify the DOM from there once the app is loaded... with the same code!

Obviously this is code sharing is mostly interesting to app written in haskell. But I'm so excited about it that i had to share... :)

G'luck! The "javascript problem" (try google for that) is a hard one.

[edit] i call it "playing with Fay", but im certain this will end up on production for me.

Re: Why we left AngularJS

#14

Post by sqs »

dlau1 wrote: post #11

Have you tried react.js [1] ? If you use node to serve your content, you can pre-render the initial state of your app. When everything loads up, react will take a checksum of the rendered portions to ensure that it doesn't re-render the same DOM. This should come close to solving your SEO/test issues with minimal work. In my opinion, a setup like this is close to what the next big wave of frameworks will use. You can…

Haven't tried it, but I heard great things about it from bradfitz, who uses it on http://camlistore.org/ (and whose opinion definitely deserves respect). Is React an all-or-nothing thing, or can you sprinkle it in certain places on your site without needing to make the whole site in React?

Re: Why we left AngularJS

#15

Post by dlau1 »

sqs wrote: post #14
dlau1 wrote: post #11

Have you tried react.js [1] ? If you use node to serve your content, you can pre-render the initial state of your app. When everything loads up, react will take a checksum of the rendered portions to ensure that it doesn't re-render the same DOM. This should come close to solving your SEO/test issues with minimal work. In my opinion, a setup like this is close to what the next big wave of frameworks will use. You can…

Haven't tried it, but I heard great things about it from bradfitz, who uses it on http://camlistore.org/ (and whose opinion definitely deserves respect). Is React an all-or-nothing thing, or can you sprinkle it in certain places on your site without needing to make the whole site in React?

The great thing about it is that you can sprinkle it in just where you need to have some dom manipulation.

TBH, a lot of sites really overdo the client-side rendering thing.

Re: Why we left AngularJS

#16

Post by danabramov »

sqs wrote: post #14
dlau1 wrote: post #11

Have you tried react.js [1] ? If you use node to serve your content, you can pre-render the initial state of your app. When everything loads up, react will take a checksum of the rendered portions to ensure that it doesn't re-render the same DOM. This should come close to solving your SEO/test issues with minimal work. In my opinion, a setup like this is close to what the next big wave of frameworks will use. You can…

Haven't tried it, but I heard great things about it from bradfitz, who uses it on http://camlistore.org/ (and whose opinion definitely deserves respect). Is React an all-or-nothing thing, or can you sprinkle it in certain places on your site without needing to make the whole site in React?

We're replacing one Backbone view at a time as soon as they need to get more dynamic. So far I'm impressed.

Re: Why we left AngularJS

#17

Post by kirushik »

For sake of correctness — recent versions of Phantom.js are not dependent on Xvfb or any other variant of X, and there are grandmotherly prepared binary builds on the official website (kinda statically linked, so no dependency on WebKit as well). Not that it changes the author's arguments that much, but just worth pointing out.

Re: Why we left AngularJS

#18

Post by jbeja »

sqs wrote: post #9
jbeja wrote: 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 ge…

Thank you for sharing your experience, and i hope that this post teach people a lesson about context (e.j: in your case you were using the wrong tool for certain context), consider that either serve-side or client-side rendering are not competing to each other to claim which better, it always "depends" on the context that they are implemented and lastly that server-side redering is not something that should be percieve as "old-fashioned", there is a duality between the two techniques that address specifics problems and is our job to choose what is best for the job.

Re: Why we left AngularJS

#19

Post by danabramov »

We're using Backbone+React so this may not be applicable.

However...

“You can separate your dev and production build pipelines to improve dev speed, but that’s going to bite you later on.”

In my experience, you must separate dev and prod pipelines. It has never bitten me because I make hundreds dev (local) and dozens kinda-prod (staging server) builds a day.

For dev builds, Grunt just compiles LESS but doesn't touch the scripts so there is literally no delay there. In dev environment, we load scripts via RequireJS so there is no need to maintain a properly sorted list of scripts too.

For production, we concat them with grunt-contrib-requirejs with `almond: true` so RequireJS itself is stripped out completely. Production build takes time (10 to 15 seconds; we're also running Closure Compiler), but it's never a problem.

Even adding JSX (Facebook React) compilation didn't cause a slowdown for dev builds because grunt-contrib-watches compiles them on change and puts into a mounted directory.

Re: Why we left AngularJS

#20

Post by gildas »

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.

If you're OK to delegate the scraping process to a SaaS then you may be interested by SEO4Ajax [1] which will make it much simpler. Disclaimer: I'm one of the co-founder.

[1] http://www.seo4ajax.com

Post reply on HN