Content site is not app. Single-page app frameworks are for apps, not for content sites.
Why we left AngularJS
161–168 of 168 posts
Re: Why we left AngularJS
#162Re: Why we left AngularJS
#163This 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…
Re: Why we left AngularJS
#164> 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!
Re: Why we left AngularJS
#165Earlier 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
Re: Why we left AngularJS
#166One 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.
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
#167Earlier 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…
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
#168A 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 :)