Live data from Hacker News

Why we left AngularJS

sourcegraph.com

161–168 of 168 posts

Re: Why we left AngularJS

#161
If you describe something as "a content site", then implementing it as "single-page app" is ridiculous by definition.

Content site is not app. Single-page app frameworks are for apps, not for content sites.

Re: Why we left AngularJS

#162
These are just difficulties that need to be addressed, not deal-breakers. All new technologies have a transitional period where the rough edges need to be sanded off (Node.js, HTML5, etc.). As for people making comments that SPA should only be made for back ends and never a content site, USAToday.com is a SPA, and they rank just fine in Google.

Re: Why we left AngularJS

#163
post #155

This is perplexing to me. > 1. Bad search ranking and Twitter/Facebook previews This problem is patently obvious to the most cursory examination of single-page applications. If SEO is important, and you want to do an SPA, then you must be willing to bear the cost of addressing HTML requests. For my startup, I wanted to keep things DRY, which lead me early on to the Nustache engine for ASP.NET, allowing me to use the…

This a thousand times. I read the article and thought it a little weak on perspective. I've used Mustache+Backbone+Require.js stack like the one you're alluding to and it worked quite well together.

Re: Why we left AngularJS

#164
post #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?

Concatenating your large collection of controllers, services and directives. Running internationalization jobs, running unit tests, running JSLint, running LESS compilation. Creating a versioned file so you have a fallback. And more!

Sometimes, we just create our own problem. I fell into that trap before, and my toolbox is more minimal now. And btw, gulp is a better replacement for Gunt. But still, consider adding too many plugins into it before it's too late.

Re: Why we left AngularJS

#165
post #152
post #77

Earlier quoted context omitted.

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.

For us, the most common case was non-square-bracket DI syntax in the "resolve" values of Angular UI-Router[1] route definitions. [1] https://github.com/angular-ui/ui-router

good to know. Im sticking to my square-bracket syntax :)

Re: Why we left AngularJS

#166
post #160
post #139

One thing people don't really think about is that this whole notion of SPA is kind of a pipe-dream, overkill. There might be some apps that are really a single page application (likely just those simple, demo add task apps), but most really can be broken down and composed of many mini-applications. For example, how often do your users go to their settings page? Does that need to be part of the SPA? Have a complex Set…

This is exactly how I'm planning to architect my front-end code. Is Angular ideal for such environments or are there better suited frameworks.

I have one project using Angular in this manner, and it's great for it (I don't use Angular's routing system). Another project is using Knockout.JS. I prefer the Knockout method when integrating with a lot of 3rd party/external JQuery components.

In general for a Web apps, you won't go wrong using different pages as a module system. It's proven and when your app gets big enough, you don't necessarily have to worry about a huge up-front download.

BTW, if you develp web apps to be shimmed into native apps, like PhoneGap, or something, then definitely look into the routing aspects of these libraries.

Re: Why we left AngularJS

#167
post #88

Earlier quoted context omitted.

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

It's not really a single page application if you are serving separate pages is it? BTW, the page you linked to says 'Uh-oh! Couldn't find that page.' before loading and displaying the content... ouch. One of the things I love about the web is that it uses incredibly simple building blocks like simple html pages at defined stateless URLs, dumb servers and dumber clients, and builds complex systems through their intera…

Hah, yeah, I finally got that one fixed this morning: https://github.com/solvers/solvers/pull/122

Turns out I wasn't using Iron Router properly. My bad.

It is a single page application if you don't make your browser reload the page from the server each time you navigate within your app. URLs here are implemented using HTML5 pushState -- the browser isn't loading or refreshing the page when the URL changes, except for the first page load.

My point is you get the best of both worlds there: static, representative URLs that live forever (as they should); and the responsiveness you get when you only need to load data and move some divs around instead of reloading everything from scratch each time.

In fact Meteor takes things even further with latency compensation: it predicts how things will change as you interact with the app and does eventual consistency with the server state. This makes updates/deletes feel even faster.

But yeah, it's a trade off. And right now it's a big trade off -- my productivity has dropped in some places, compared to writing a simple app in express or Rails.

Re: Why we left AngularJS

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

Totally agree, but you still have the analytics/tracking problems. Unless you're not tracking clicks/activities/views on your various features. But if that's the case, you have bigger problems :)

Can anyone elaborate on the problems? Are there problems with analytics while using Angular?
Post reply on HN