Live data from Hacker News

Why we left AngularJS

sourcegraph.com

81–90 of 168 posts

Re: Why we left AngularJS

#81
post #23
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.

The angularjs.org sites are indexed, just by using a trivial nginx directive to selectively serve partials to crawlers. All of the angularjs.org apps still rank fairly well using this strategy.

This isn't always appropriate of course, those apps aren't really relying on data from a database, they're proper SPAs. But as noted by others, there are ways to fool crawlers if it's something you want to do.

Generally though, the feeling is that crawlers not executing JS is going to end, and the problem will go away on its own.

Re: Why we left AngularJS

#82

This is really a case of picking the wrong tool for the job. __This is in no way a slight of the author__...b/c I have done worse on more than one occasion, so thanks for sharing. To anyone reading, you really should understand your workload before picking tools. And, you need to understand the difference between Web Application vs. Web Site: Which are you building? Server-side rending is the winner for content sites…

Most cogent perspective here.

Re: Why we left AngularJS

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

I agree that things like blogger are a great example of what not to do, but I'd go further and say that treating something as a single page web app running on the client side throws away most of the advantages of the web:

URLs which can be stored and shared and are idempotent

Mostly stateless operation for anonymous use (fast to serve/load/cache)

Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways

What you call suboptimal browsing devices are what makes the web special and distinct from native apps. These are not trivial advantages, and most websites would benefit from these strengths of the web, even if they are an app.

As an example of where something like a single page app can shine on a public site, I've seen chat software which used it which worked really well (using socket.io I think), but only because people didn't care about sharing individual messages and the chat was ephemeral.

Re: Why we left AngularJS

#84
Really, this seems to be more of a case of the wrong tool being used for the wrong job than a tool with flaws and no real use. AngularJS positions itself as a fit-all solution for great Javascript based applications, when in reality it is meant for use only in an authenticated user setting. Look to an application like Asana (built on a similar internal Javascript framework), you only get the Javascript application version after you've logged in, not before.

It's like creating an online store and deciding to choose MongoDB or any other NoSQL branded database and then discover it doesn't support transactions and having to move over to a RDBMS like MySQL or PostgreSQL. The caveats listed in the article are definitely true though. As someone who's used AngularJS enough to know its downfalls, it's definitely not a one sized fits all solution and much like anything it comes with both its own pros and cons.

It's important you spend the extra amount of time when planning your project to ensure you choose the right tools for the right job (well at least at the time). If your requirement is to be indexable via search engines, choose a solution that allows that and so on. Don't use something just because it's the flavour of the day on the HN front-page.

Re: Why we left AngularJS

#85
All these arguments seem like lowly excuses to not do proper work and instead blame the framework you are using. If you have any kind of interactiveness the feel of a fat client is so much better then template rendering.

Look at the site: https://sourcegraph.com/github.com/tomchristie/django-rest-f...?

Is that the best interface you can get? In 2014 everything I click reloads the page? a tabbed interface that doesn't load the content in the window is noticeable by users these days. No pop ups of any kind? why do I need to reload the page to see a list of 4 contributers. You've gained maintainability at the cost of user experience, a lot of user experience for very little maintainability.

There are sites that benefit little from client-side rendering- blogs and news site for instance, but most will gain a lot.

1) Indexing with PhantomJs is a breeze, truely. Not only are there a ton of libraries that already do it, there are even SAASes that will do it for you for a fee. If you are really unable to come to terms with this, you can use react.js, which solve the SEO indexing issue completely.

2) If the only thing that you are doing on the site is measuring page loads then your site either lacks interactiveness completely or you aren't measuring everything you should. You aren't measuring to where a user left your site (and incredibly important metric) or any action he does (assuming there is any he can do) that isn't navigation.

With Angularytics (and a thousand other libraries) adding analytics is maybe 5 lines of code, and you get declarative analytics on any link you want.

3) This site's js is neither minimized nor concatenated, so I'm not sure what build tools you need for angular either then the ability to serve static content? But in any case it's js, you are going to need to minimize and concatenate it at some point for performance, doesn't matter if you use a fat client or some custom jQuery plugin. Even with Grunt, though I don't like it very much, the build file is maybe 10 lines long, and the build process takes miliseconds.

4) And the alternative is what? using manual QA on every build? You have a website with even minimal interactivity you are going to need to use a browser based testing solution. Karma is a breeze, and with the new setup, the only thing you need to install is node and karma. Takes exactly 3 seconds, and you get one of the best isolated unit testing framework for client side code. Angular is actually built around the ability to unit test it.

5) So your saying that the solution to slowness is to have 43 unique resources loaded and rendered on every navigation? Page reload slowness is one of the major hassles that Ajax, and fat clients as a consequence, are trying to overcome. Your site takes, to me, about 3 seconds to load from page to page (6 seconds to finish rendering), there is obviously no wait time indicator that you can add and no tricks to minimize this. Not to mention that rendering is slow, and server-side rendering is not only extremely slow it can also cause parallel load which will make things worse. If you don't care about your speed it doesn't matter what framework you use.

For the sake of this you are losing interactiveness, speed and lower bandwidth to name just a few.

Re: Why we left AngularJS

#87

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…

This approach looks very promising; I agree with the other reply that this is the way forward. Best of luck.

Re: Why we left AngularJS

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

I agree that things like blogger are a great example of what not to do, but I'd go further and say that treating something as a single page web app running on the client side throws away most of the advantages of the web: URLs which can be stored and shared and are idempotent Mostly stateless operation for anonymous use (fast to serve/load/cache) Document formats that anything (including dumb crawlers and future gadg…

> URLs which can be stored and shared and are idempotent

If you use a decent router, you get shareable idempotent URLs: https://solvers.io/projects/7GTeCKo7rGx5FsGkB

> Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways

As in the article, you can use phantomjs to serve up static HTML to crawlers. They are correct in that it does slow you down and add complexity.

The main problem I think is that SPA tech is still immature and getting all the moving parts to build a public facing SPA working together is a time sink.

Re: Why we left AngularJS

#89
> 3. Slow, complex build tools

I'm building a big AngularJS app and I'm not using any build tools. Apart from minifying, what would you use it for?

Re: Why we left AngularJS

#90
post #76
post #32

Earlier quoted context omitted.

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

Is node really a good choice for static non-real time sites? I'm thinking something like Django or Ruby on Rails is better.
Post reply on HN