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

71–80 of 168 posts

Re: Why we left AngularJS

#71

Post by btown »

elliottkember wrote: post #56
dchuk wrote: post #46

Earlier quoted context omitted.

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.

Precompiling static HTML is a strict sub-problem of the problem most people in this comment thread are referring to, which is development incentives and SEO characteristics for web pages that have non-trivial amounts of dynamic content.

Re: Why we left AngularJS

#72

Post by [deleted] »

jsnk wrote: post #40
lifeisstillgood wrote: post #36

Earlier quoted context omitted.

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

Say goodbye to Quora sign up pop up using https://github.com/niftylettuce/block-quora-login-popup

[deleted]

Re: Why we left AngularJS

#73

Post by johnx123-up »

anonova wrote: post #59
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.

FWIW.. it looks overkill for me

Re: Why we left AngularJS

#74

Post by lstamour »

randomdrake wrote: post #43
lstamour wrote: post #39

Earlier quoted context omitted.

To answer that question -- for the same reason you'd prefer mobile apps on a smartphone. Even in resource-constrained hardware, it makes sense to do things client-side if that's less expensive: no need for server communication on some or all of the app, since it can be cached locally. Sometimes your app can be more expressive than a sequential history of documents loaded one page at a time. Now, do people really thin…

> Even in resource-constrained hardware, it makes sense to do things client-side if that's less expensive: no need for server communication on some or all of the app, since it can be cached locally. Sometimes your app can be more expressive than a sequential history of documents loaded one page at a time. > Now, do people really think that way when they adopt these frameworks? Nope. I mean, they might think about spe…

Cool. Can't argue with any of the above. And sorry for getting nit-picky earlier.

I'd point to react.js as a framework that encourages fast code while discouraging knee-jerk adoption by calling itself a view layer, batteries not included. Of course, that doesn't help people realise whether JS MVC, PJAX or PHP is the best choice for the job. But it does highlight certain desires for client-side rendering that's more generic than "insert this block of HTML here". Like angular, it's most useful when you need to repeat yourself a few times on a page as each new piece of data has to be rendered in real-time to a page. If static, you should have fewer worries. Usually with JS, if it's easy, you're doing something wrong, or using Dart :p (Okay, the last was tongue in cheek)

Re: Why we left AngularJS

#75

Post by pa5tabear »

anonova wrote: post #59
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.

Do they use open source libraries? And otherwise how do they differ from something like Angular?

Re: Why we left AngularJS

#76

Post by rlidwka »

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?

"node.js + express + jade" is a fairly common stack, you can even try to move an existing complex angular.js code there because it's written in the same language

Re: Why we left AngularJS

#77

Post by vladgur »

sqs wrote: post #24
danabramov wrote: post #19

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…

Yes, we did use separate dev and prod pipelines when we used AngularJS. (We used https://github.com/ngbp/ng-boilerplate. ) It took 2-3sec for the dev build (most of which was taken up by recess) and 30-45sec for the prod build (primarily JS uglification). However, probably 5-10 times we deployed a broken site because either 1) the LESS compiler changed the order of our CSS rules or 2) we used AngularJS DI syntax some…

Im curious which DI syntax couldnt be handled by ngmin?

I made it a rule to use the square bracket notation for angular DI and that obviously takes care of any minification issues.

Re: Why we left AngularJS

#78

Post by frio »

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…

  > you can pre-render the initial state of your app
This, I think, is the killer feature of Node, and the reason I'm slowly transitioning from Python for new web projects. You can reuse your server-side templates client-side (without worrying about, say, reimplementing Handlebars Helpers in your server-side language), and can easily render full HTML templates for the client that get enhanced when the client-side JS loads. This also solves UI nuisances -- like your server's markdown renderer being different to your client-side preview (grr).

Meteor and Derby are obviously heading down this path, and while I'm not sold on the rest of Node and the general JS style, having the same language in the browser and the server is too much to pass up.

Re: Why we left AngularJS

#79

Post by potench »

frio wrote: post #78
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…

> you can pre-render the initial state of your app This, I think, is the killer feature of Node, and the reason I'm slowly transitioning from Python for new web projects. You can reuse your server-side templates client-side (without worrying about, say, reimplementing Handlebars Helpers in your server-side language), and can easily render full HTML templates for the client that get enhanced when the client-side JS lo…

If you're coming from python, I'd recommend the 'swig' template library. Django syntax in node and client-side.

Re: Why we left AngularJS

#80

Post by Argorak »

pa5tabear wrote: post #75
anonova wrote: post #59

Earlier quoted context omitted.

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.

Do they use open source libraries? And otherwise how do they differ from something like Angular?

Discourse is open source:

https://github.com/discourse/discourse

It uses ember.js with a Rails backend.

Post reply on HN