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

91–100 of 168 posts

Re: Why we left AngularJS

#91

Post by Cthulhu_ »

> 3. Slow, complex build tools

Slow... depends on what you're used to; I've worked with Java / Maven and such, and one step worse, Scala; if you want slow, go for those.

Complex. The author links to a certain gruntfile[0] as an example of a large, unmaintainable gruntfile, but apparently people forget that a gruntfile is just a Javascript / NodeJS file, and thus can be broken up into more manageable chunks - like any code[1]. Alternatively, there's newer, less config, more code build tools like Gulp.js[2].

#4 is also no longer valid; Angular's Protractor[3] wraps around Selenium etc and deals with angular's asynchronous behaviour, as long as you stay within angular's framework.

And #5 is to be blamed on the developer for not having attention to performance / total load times, not the framework.

I'm defensive, but then, I don't have a public-facing app.

[0] https://github.com/ngbp/ngbp/blob/v0.3.1-release/Gruntfile.j... [1] http://www.thomasboyt.com/2013/09/01/maintainable-grunt.html [2] http://gulpjs.com/ [3] https://github.com/angular/protractor

Re: Why we left AngularJS

#92

Post by grey-area »

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…

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 interaction. I'd be very wary of solutions that drop those advantages.

There are certainly technical solutions possibly to almost any problem with angular or client-side apps in general, but I'm not sure that rendering everything client-side really gives you enough advantages to warrant it for many websites. What do you see as the main advantages to this approach and do you see it spreading everywhere eventually?

Every website is different and what suits (say) a chat application will not suit a document-orientated website at all. There's certainly room to explore both approaches or even mix them at times.

Re: Why we left AngularJS

#94

Post by robmcm »

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

This is a joke right, asyc loading is somehow bad? If it's that much of a problem hold off rendering untill you have all your data back, of heaven forbid implement item one of Nielsen's list of heuristics, "Visibility of system status" and chuck in a loading gif.

Re: Why we left AngularJS

#95

Post by nathancahill »

akbar501 wrote: post #45

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…

> "Client-side rending (such as Angular/Backbone/etc) really shine when you need a web application (not web site)."

This, 1000x over. I have static landing pages and about pages for search engines, but the app itself is a single page Angular app. The data does not have to be indexed.

Re: Why we left AngularJS

#96

Post by hiphopyo »

johnx123-up wrote: post #73
anonova wrote: post #59

Earlier quoted context omitted.

Discourse is essentially a SPA (see http://try.discourse.org/ ) and designed to be public-facing. It does a good job at providing a very bare, lightweight interface for people with JavaScript disabled and, I'm assuming, for web crawlers.

FWIW.. it looks overkill for me

I'd much rather use Forem.

Re: Why we left AngularJS

#97

Post by discreteevent »

grey-area wrote: post #92
davedx wrote: 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…

" 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 mechanism and that's all?

Re: Why we left AngularJS

#99

Post by CmonDev »

balls187 wrote: post #55

This isn't about AngularJS in particular. This is about using a client-side JS app framework. Substitute any other flavor and the same problems exist.

The problem is using languages designed for animated rich documents for GUIs.

Re: Why we left AngularJS

#100

Post by lifeisstillgood »

lstamour wrote: post #41
lifeisstillgood wrote: post #36

Earlier quoted context omitted.

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

I was able to read the first answer without signing up. And I'm not sure I'd say passively reading is something we ever do on the web. Consider nytimes.com redesign -- it uses app concepts for a sidebar while devoting all attention on the prose in front of you. You can even navigate using arrow keys, though that could be improved: first time I do it, use a popup to let me know what happened and how to undo. The point…

The app-ification of the web implies one does something with an app. Something that produces, creates or alters - simply having a easier navigation for reading an article does not to me qualify. I already have a very good framework for reading - text and books.

we are going to see a million and one ways of presenting the same article of the same tv show, and one million of them will be crap. the other - who knows. I just hope it's worth living with the million others - I will prefer to avoid them and wait for the one announcement.

Post reply on HN