Live data from Hacker News

Why we left AngularJS

sourcegraph.com

31–40 of 168 posts

Re: Why we left AngularJS

#31
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…

Agreed - there is a wealth of applications that are not in the massive scaled consumer market - and making those clean, easy to maintain and deliver is an enormous win. That said, there is a wealth of consumer apps that don't have massive market shares either so the market for learning these lessons is pretty rarefied

Re: Why we left AngularJS

#32
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?

Re: Why we left AngularJS

#33
post #22

We've transitioned from Angular to ReactJS with great success. Much smaller learning curve. Using Backbone to handle the models and React for the view is a great combination.

How do you update React views when BB models change?

Most approaches I've seen use `forceUpdate` although it is arguably more React-ish to [pass along pure JSON][1].

We're currently sticking with passing JSON top-down and calling `renderComponent` when model changes so `props` never mutate.

What is your experience with this?

[1]: (http://stackoverflow.com/a/21710111/458193)

Re: Why we left AngularJS

#34
post #12

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 .

I heard something similar in a Reactjs conference by Pete Hunt, at the time i was like , "huh?".

Re: Why we left AngularJS

#35
post #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 ge…

Hey OP! We did the same EXACT thing as you. Our end user experience was super slick using Angular, but this doesn't bode well for things that, well, aren't users (we migrated back to Rails). Your post looks like it got HN-hugged so I can't read the whole thing. Either way I'd be happy to share (so we can compare/contrast) our own findings and conclusions via email. As you said, educating other developers is great!

Re: Why we left AngularJS

#36

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

Re: Why we left AngularJS

#37
post #35
post #9

Earlier quoted context omitted.

(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…

Hey OP! We did the same EXACT thing as you. Our end user experience was super slick using Angular, but this doesn't bode well for things that, well, aren't users (we migrated back to Rails). Your post looks like it got HN-hugged so I can't read the whole thing. Either way I'd be happy to share (so we can compare/contrast) our own findings and conclusions via email. As you said, educating other developers is great!

[deleted]

Re: Why we left AngularJS

#38
post #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 ge…

I'm well-versed in Angular, and I too made that mistake on one project as well. There's something to be said for picking the right tools for the right job.

Re: Why we left AngularJS

#39

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…

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 think that way when they adopt these frameworks? Nope. I mean, they might think about speed, but we all know that loading a bit of static HTML and CSS is faster than any JavaScript execution.

That said, I'll ignore my point above and get a bit technical here: Unless you're using Opera Mini, client-side rendering is indeed all we have for "textual document model rendering". That's what we call "HTML" folks when we're not "viewing source". So ... I'd give the client-side a bit of credit here, things will improve with time.

Use the right technology for the job. And that advice keeps changing. Right now, I'm most influenced by http://www.igvita.com/slides/2013/breaking-1s-mobile-barrier... but once you've caching/native, it's a whole different game. And if you add pre-fetching...

Re: Why we left AngularJS

#40

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

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