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

151–160 of 168 posts

Re: Why we left AngularJS

#151

Post by davesque »

sanderjd wrote: post #145
grey-area wrote: post #92

Earlier quoted context omitted.

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…

You make some really good points, but I think simple json documents are much simpler and easier to re-use by other clients in interesting ways than simple html pages. I think the API + client (note, not just traditional web browser) rendering is actually a more "pure" interpretation of what the web can be - data sources and data consumers that interpret and present that data on behalf of their users. I'm also not sur…

I'm not sure it makes much sense to refer to a JSON packet as a "document". HTML is truly meant to represent documents, with embedded semantics. JSON is really meant to represent data or objects in the most abstract sense. It has no notion of embedded semantics.

Re: Why we left AngularJS

#152

Post by sqs »

vladgur wrote: post #77
sqs wrote: post #24

Earlier quoted context omitted.

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.

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

#153

Post by iopq »

blueskin_ wrote: post #118
discreteevent wrote: post #97

Earlier quoted context omitted.

" I'd be very wary of solutions that drop those advantages." They are called native applications. I can think of some useful ones over the years, particularly for people who produce rather than consume. I notice that my Bosch drill isn't available for seo and mashing :) Seriously though, it depends on your perspective. What's wrong with saying I'd like to make a native app but use the web as a delivery/installation m…

There's a difference. Photoshop wouldn't work as a website, and HN wouldn't work as a program. Different forms for different use cases.

Photoshop wouldn't work as a website? http://pixlr.com/editor/

Re: Why we left AngularJS

#154

Post by suprfsat »

davedx wrote: post #88
grey-area wrote: post #83

Earlier quoted context omitted.

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

Well that's super. https://solvers.io/projects/7GTeCKo7rGx5FsGkB?_escaped_fragm... takes 15 seconds to load and still doesn't contain any readable content.

Re: Why we left AngularJS

#155

Post by mcgwiz »

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 same Mustache templates on server and client. This doesn't have anything like the complexity described in the article.

> 2. Flaky stats and monitoring

Simply not true. Using Google Analytics and Backbone, you simply listen to the Backbone.history:route event and fire off a pageview using the Google Analytics API.

> 3. Slow, complex build tools

Complex, yes. Slow? Using r.js, no slower than a typical static language build.

> 4. Slow, flaky tests

Slow, yes, but no more so than desktop app test automation. I've found PhantomJS with QUnit (unit-testing), and CasperJS for integration testing to be quite reliable. It took a few days to get everything connected (scripting IIS Express to start and end in the background being the trickiest bit), but that was it.

> 5. Slowness is swept under the rug, not addressed

This is a UX challenge that is known and obvious up-front. Failing to address it is a design problem, not a technological one.

Overall, this seems the result of the ineptitude prevalent in inexperienced, "move fast, break things" teams. Rather than owning up to moving too fast and foregoing due analysis/research, they blame technology. Or, the article is a marketing ploy.

Re: Why we left AngularJS

#157

Post by notjustanymike »

Kiro wrote: 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!

Re: Why we left AngularJS

#158

Post by Illniyar »

Bahamut wrote: post #147
Illniyar wrote: post #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'…

Using PhantomJS to prerender is not a viable solution for everything - for example, fast updating content like forum threads.

Why not? it's not like google and other crawler bots crawl your site every second, we are talking about roughly once a day.

And even then, there are solutions to do PhantomJS rendering on the fly, it might be a bit slower, but shouldn't be drastically so - some of the SAAS solutions I mentioned already provide such an option.

Re: Why we left AngularJS

#159

Post by grey-area »

sanderjd wrote: post #145
grey-area wrote: post #92

Earlier quoted context omitted.

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…

You make some really good points, but I think simple json documents are much simpler and easier to re-use by other clients in interesting ways than simple html pages. I think the API + client (note, not just traditional web browser) rendering is actually a more "pure" interpretation of what the web can be - data sources and data consumers that interpret and present that data on behalf of their users. I'm also not sur…

I think simple json documents are much simpler and easier to re-use by other clients in interesting ways than simple html pages. I think the API + client (note, not just traditional web browser) rendering is actually a more "pure" interpretation of what the web can be - data sources and data consumers that interpret and present that data on behalf of their users.

This is an interesting point - if you are representing numeric data like chart datapoints, a representation like json might make it cleaner and more reusable by other services or clients. Of course much data is actually formatted documents or snippets of text, in which case json is not such a good fit and html is perhaps better. In many ways html is a worse is better solution, but that is probably part of its strength - it is very easy to get started with and munge to extract or insert data.

I'm not sure a separate of concerns between server and client is necessary and helpful to all apps, though I'm sure in some cases it is useful (for example serving the same json or xml to a mobile app, a client-side app and some desktop client, or separate teams working on both), but then a server-based solution can easily output both formatted html for traditional clients (web browsers, which are now and in the future ubiquitous), and a json or xml representation for other clients - this sort of separation of concerns between data and presentation is not really exclusive to client-side solutions.

Re: Why we left AngularJS

#160

Post by hrayr »

taude wrote: 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.
Post reply on HN