Angular is naturally a poor choice for social networking sites.
The reason being, is because the 2 way data binding requires a metric crap ton of listeners. Once you hit about 1000 listeners Angular tends to crap out a bit.
It is better for dynamic sites hosting more or less static content. Not for social.
Angular 2 is built for tomorrow. It uses a lot of apis either not available (and so must be shimmed which is slow) or not optimised in today's browsers.
If tomorrow means we're going to give up serving any HTML on first render and pretend that performance doesn't matter, then yes, it's built for tomorrow.
As an aside: Meteor is in the same slowly sinking boat. React is not as you can easily render server side before pushing that initial page to the client.
It's all coming around. React taught the value in using a virtual DOM for isomorphic rendering. Ember is adopting it with Fastboot, and I'm sure Angular will end up doing something similar.
I'm not an Angular user(Ember here), but in time all of the major frameworks will allow for serverside rendering. The React model works very well, and most projects are taking a lot of ideas from it. Ember will have fastboot in a couple of months to match the same idea, and it won't even require any custom code- it'll be little more than 'drop in, run server', and you're good for life.
I expect a lot of other frameworks take a similar approach not long from now.
Yup. And Ember's getting even ridiculously fast post-load, too, thanks to Glimmer. When it comes out, it should be the fastest full-fledged framework. I'm sure the others will catch up super soon though!
So much misinformation here. For one, Angular 2 will allow for server side rendering as well, as it doesn't rely on a DOM.
Secondly (and I already linked this in a separate comment), I built a very ugly but effective reddit angular client that receives no HTML whatsoever and renders pretty much instantly. This is in Angular 1.3 and much slower than Angular 2.0:
That's kind of a waste for something like the HackerNews site. It's just dog-simple HTML. There are a handful of vanilla JS functions to run the voting buttons (at least that I can see). It seems like a use-case that would be perfect for server-side templating like Razor.
This is not a critique to the author, but for me, who just did classic webdev (server side templated html), this was very surprising.
I am not that into webdev, but shouldn't a page like HN be fast TODAY, as it has very basic functionality (CRUD)? I mean if this is slow, how can I expect acceptable performance from involved applications?
The problem is the site is not sending any (useful) HTML during the first HTTP request. Therefore the browser has to wait for the JS to render the page before it can even think about displaying anything.
The fact the site then loads content from firebase is obviously a problem, but it's not so much firebase's problem as it is of the codebase itself - in an ideal world it should be rendering the initial HTML to send to the client on the server.
I have seen React based websites with server side rendering work with firebase with much better performance.
That's not the point of sample projects like these. It's to showcase what's possible with the technology and allow developers to see how something can be implemented.
The developer was having fun with the technology and showing others how it could be done. Let's encourage this type of behavior.
"I created this to see what it's like to create an AngularJS 2.0 application. I've previously experimented creating a Hacker News clone with AngularJS 1 so this was fun to play with."
Hacker News loads in milliseconds, why does this take over 10 seconds to even start showing comments?
It's not so much a showcase as a reason to ever never use this in any product, it's obviously unsuitable for displaying even the most simple, static data without taking forever and making FireFox stutter. It's not an isolated situation with this either, other websites like this perform terribly even thought they are written in the hippest language with the most popular libraries on the market.
Hacker News loads in milliseconds because the content is generated on the server and insanely optimized. It's different architecture. Optimized server side page loads will always load faster than client size AJAX API calls + page 2x page rendering.
Of course Angular doesn't make sense for a site like HN but this is just a demonstration of what's possible with a site we're all familiar with.
A real world example of Angular is when you're working with HIPAA complaint applications which depend on 3rd party data storage sites, such as http://TrueVault.com. None of the patient information is stored on the application server. Instead, it makes client side API requests to the TrueVault storage and updates the page with the data.
Yes, Angular doesn't make sense for a majority of the websites in existence but it does work well for certain applications.
Or let's encourage using the right tools for the right applications. Let's encourage speed and simplicity as desirable goals again. Let's not do it the Google Blogger way, let's not create services that take several seconds to display few lines of text. There's a great framework for that, it's called HTML.
Seconding that, this is far more useful than another TodoMVC implementation for getting a feel for how an Angular 2 app is put together, with multiple pages, data from an API and at least one component with more complex display logic.
This is interesting, when I opened the link I thoguht to myself "this might be a nice and faster way to browse HN" ... but wow, this thing I slow. Not just slow, but the back button isn't working as well. Or maybe it is, but it loads the whole content again when you click back?
The Firebase API is pretty quick after the initial connection, here's an un-optimised React version (i.e. no shouldComponentUpdate hooks) which uses the Firebase API, for comparison: http://insin.github.io/react-hn
This is pretty cool, thanks for sharing. I may start using this to browse HN all the time, since it does have the one feature that I miss from the normal site, e.g. highlighting new comments since the last time I viewed a thread. It also appears to autoload new items? I assume this must be cookie/session based, but I'll have to look at it.
I think I've taken it as a given that any website that uses XHR to load parts of pages will necessarily be slow because of all the rest of the bloat (e.g. jQuery + 10 plugins + Angular) required to make the UI actually work while still keeping the code somewhat readable to the programmers. Basic HTML Gmail is also a ton faster than the normal version ...
You can however use CSS transitions effectively to make the user think the page is faster. Just have some action flying around (it's offloaded to the GPU if you're doing it "right") while things are being processed and it won't "count" towards the user's perception of page load speed.
e.g. Your HTML-only page loads in 200ms, your XHR-/Angular/jQueryified version loads in 1000ms, but you want the user to use and like the latter. Make the page dance around for the first 900 ms, and the user will "feel" that your new version loads in 100 ms. You don't want to push this "effective loading speed" all the way to 0 or else the user will become aware of your trick. Keep it at a perceptual minimum and the user will be like "Woah!"
You cannot just paper over everything. If you're having to resort to tricks due to inherent flaws in your application stack, it may be worth reexamining your application stack.
Also, I wondered who creates that sort of annoyance. Now I know. Having half of mobile webpages have animations all over the place only makes me go "whoa" in the sense of "whoa, how do I disable this and go back to the (relatively sane) desktop site". It doesn't make it "feel" as though it loads in 100ms instead of 1000ms. 900ms instead of 100ms, perhaps, and that's stretching it. But loading in 1/10th the time? Nope.
Yeah; unfortunately the "flaws" aren't something that most people can control. HTML5+JS+CSS+[insert JS frameworks] is inherently inefficient because it's a lot of band-aids on top of band-aids. But we as front-end developers just have to live with those band-aids; we don't get to reengineer the user's browser. If jQuery and Angular were implemented in C
Compare the loading speeds of these two on your own Google account and you'll see.
Like seriously, even opening a message is faster in the basic HTML version (on my system about ~300 ms vs. ~600 ms) despite it re-loading all the page chrome. I'm 99% positive that's because of all the bloat caused by the all the UI framework they used to make it happen in the regular version. The basic HTML version is so fast that it doesn't even need a progress bar on load!
But of course, you as a developer want to develop the full-blown HTML5 experience because there are tons of features you can't do with basic HTML only. Also, basic HTML makes your site look dated (want a nice-looking button? You'll a bunch of jQuery bloat instead of just a <button> tag. Want a nice-looking text box that maintains a consistent height across browsers? That's a bunch of CSS bloat and putting a text box inside a fake <div> to ensure its height because different browsers have different interpretations of your CSS. Want a text box with tagging ability? That's going to be a massive, inefficient bloat of JavaScript because you essentially have to re-invent the text box from the ground up in JS)
In these cases, sometimes using effects to play tricks on the user to make it "feel" faster does help, because there's nothing we can really do about it ...
And that's why I use the "basic" interface on the (two) webmail providers I have email accounts with. Much faster, and actually handles things like open in new tab properly, among other things.
When the fancy chrome gets in the way of basic functionality, I take the functionality every time.
There is a solution. Or rather, a way of mitigating it. Namely, unlike so many developers, when you look at a "feature", consider the drawbacks, not just the positive side. When you're considering adding something to a button that pulls in umpteen billion JS frameworks, consider if the bloat is worth it. When you're starting to reinvent the text box just so you can have tags, consider if the inefficiency is worth it. When you're considering reimplementing scrollbars in JS, consider if the UI problems you'll have are worth it.
And, you know, if/when you run across something that's problematic to do well, consider feedback. Among other things, the number of features of CSS that ultimately boiled down to someone going "there isn't a good way to do <x> currently"...
I'd be interested to see the other effects of effects. I've seen things on perceived time - but that's not the whole story. Does it affect user retention? Clickthrough rates? User mood?
I'd contend that these aren't problems with HTML/CSS/JS, but with their categorical misuse under the guise of simplicity. Things like jQuery are orders of magnitude slower than both alternatives and native implementations, and using many of these bloated libraries will only multiply the inefficiencies.
It is a mistake to assume a browser supports javascript.
Angular/meteor/etc do not generate sane output, as throwing up what is essentially an empty body tag (literally so, in some cases) is not only totally unusable outside the one use-case you have planned for, the page being generated is equivalent to a server error.
The correct solution, of course, is to render the page server side (and cache it, if you're sane), and progressively enhance any features such as XHR-style loading. Some comments later in this thread have mentioned that this might be an upcoming feature in the near future, which is great.
Without server-side rendering? That is still no excuse to serve up an empty page. Put some sort of fallback there, or a link to some alternative page. At a minimum, at least have a proper error message about how your site only only works in browsers that support javascript.
> It is a mistake to assume a browser supports javascript.
I really feel at this stage in the battle that that argument is hurting the call for server side rendering. Don't get me wrong, I have been a pusher for PE for many years but it quite clearly is falling on deaf ears these days.
The reason being is that it's very easy for someone to turn around and say "none of our users that we care about turn js off". However it is much harder to ignore the fact that initial page load times with server side rendering are minimal in comparison to the render-via-js frameworks of today.
I believe we need to follow the performance argument.
You throw the term 'isomorphic' around a bunch in the descriptions of this project. It would be nice if the README explained what that meant. I know what an isomorphism is, but have no idea what this means in this context.
They use the term isomorphic to mean that it is written in one language throughout the app. Typically, JS on the front and back end.
They really should be saying something like isoglossic (not a Greek scholar here) to imply that it's in the same language, instead of isomorphic, which implies a lot more than what they intend.
Is everyone missing the point of this? It's a proof-of-concept app using an alpha[1] framework that, in a year or two, will likely be one of the dominant frameworks on the web. I for one find real examples like this much more useful than underwhelming "Todo"[2] examples. Yes, it's slow. Yes, it has lots of bugs but hell, at least the author is giving it a shot. I just hope they write a decent blog post about it with some of the lessons learned.
This is a great example why you shouldn't use a client-heavy stack for a site like HN. You could, in theory, make something that's a bit better than original HN, but it requires way more work and/or quite possibly something else than Angular.
To people who are complaining that this is slow, please understand that
1. Doesn't have to do with Angular
2. Doesn't even have to do with a single page implementation
I made a really shit take on a single page reddit client, and I'm sure you'll see that the browsing experience is actually quite nice (and much faster than using native reddit). This was written in Angular 1.3, and Angular 2.0 is MUCH faster.
My point is that implemented correctly, even a content site like reddit or hackernews could work quite well with a single-page implementation. Don't blame Angular for this demo, its server responses are just impossibly slow
If author see result is slow and reason is not ng2, then don't publish it. Otherwise everybody will think ng2 is slow and in next article with click-catching-title this example will be taken as proof of some "sensational" statement. Nobody will read explanations - people more trust own feelings than explanations.
64 comments
[ 4.6 ms ] story [ 54.1 ms ] threadThe reason being, is because the 2 way data binding requires a metric crap ton of listeners. Once you hit about 1000 listeners Angular tends to crap out a bit.
It is better for dynamic sites hosting more or less static content. Not for social.
If tomorrow means we're going to give up serving any HTML on first render and pretend that performance doesn't matter, then yes, it's built for tomorrow.
As an aside: Meteor is in the same slowly sinking boat. React is not as you can easily render server side before pushing that initial page to the client.
I expect a lot of other frameworks take a similar approach not long from now.
Secondly (and I already linked this in a separate comment), I built a very ugly but effective reddit angular client that receives no HTML whatsoever and renders pretty much instantly. This is in Angular 1.3 and much slower than Angular 2.0:
http://bredd.it.s3-website-us-west-1.amazonaws.com/
I am not that into webdev, but shouldn't a page like HN be fast TODAY, as it has very basic functionality (CRUD)? I mean if this is slow, how can I expect acceptable performance from involved applications?
The fact the site then loads content from firebase is obviously a problem, but it's not so much firebase's problem as it is of the codebase itself - in an ideal world it should be rendering the initial HTML to send to the client on the server.
I have seen React based websites with server side rendering work with firebase with much better performance.
The developer was having fun with the technology and showing others how it could be done. Let's encourage this type of behavior.
"I created this to see what it's like to create an AngularJS 2.0 application. I've previously experimented creating a Hacker News clone with AngularJS 1 so this was fun to play with."
It's not so much a showcase as a reason to ever never use this in any product, it's obviously unsuitable for displaying even the most simple, static data without taking forever and making FireFox stutter. It's not an isolated situation with this either, other websites like this perform terribly even thought they are written in the hippest language with the most popular libraries on the market.
Of course Angular doesn't make sense for a site like HN but this is just a demonstration of what's possible with a site we're all familiar with.
A real world example of Angular is when you're working with HIPAA complaint applications which depend on 3rd party data storage sites, such as http://TrueVault.com. None of the patient information is stored on the application server. Instead, it makes client side API requests to the TrueVault storage and updates the page with the data.
Yes, Angular doesn't make sense for a majority of the websites in existence but it does work well for certain applications.
Or let's encourage using the right tools for the right applications. Let's encourage speed and simplicity as desirable goals again. Let's not do it the Google Blogger way, let's not create services that take several seconds to display few lines of text. There's a great framework for that, it's called HTML.
Angular is a good tool for web apps that have information stored on 3rd party websites that have to be called via client side API requests.
Really enjoyed looking through the source on this.
https://github.com/insin/react-hn/blob/master/src/utils/stor...
You can however use CSS transitions effectively to make the user think the page is faster. Just have some action flying around (it's offloaded to the GPU if you're doing it "right") while things are being processed and it won't "count" towards the user's perception of page load speed.
e.g. Your HTML-only page loads in 200ms, your XHR-/Angular/jQueryified version loads in 1000ms, but you want the user to use and like the latter. Make the page dance around for the first 900 ms, and the user will "feel" that your new version loads in 100 ms. You don't want to push this "effective loading speed" all the way to 0 or else the user will become aware of your trick. Keep it at a perceptual minimum and the user will be like "Woah!"
Also, I wondered who creates that sort of annoyance. Now I know. Having half of mobile webpages have animations all over the place only makes me go "whoa" in the sense of "whoa, how do I disable this and go back to the (relatively sane) desktop site". It doesn't make it "feel" as though it loads in 100ms instead of 1000ms. 900ms instead of 100ms, perhaps, and that's stretching it. But loading in 1/10th the time? Nope.
Compare the loading speeds of these two on your own Google account and you'll see.
https://mail.google.com/mail/?ui=html
https://mail.google.com/
Like seriously, even opening a message is faster in the basic HTML version (on my system about ~300 ms vs. ~600 ms) despite it re-loading all the page chrome. I'm 99% positive that's because of all the bloat caused by the all the UI framework they used to make it happen in the regular version. The basic HTML version is so fast that it doesn't even need a progress bar on load!
But of course, you as a developer want to develop the full-blown HTML5 experience because there are tons of features you can't do with basic HTML only. Also, basic HTML makes your site look dated (want a nice-looking button? You'll a bunch of jQuery bloat instead of just a <button> tag. Want a nice-looking text box that maintains a consistent height across browsers? That's a bunch of CSS bloat and putting a text box inside a fake <div> to ensure its height because different browsers have different interpretations of your CSS. Want a text box with tagging ability? That's going to be a massive, inefficient bloat of JavaScript because you essentially have to re-invent the text box from the ground up in JS)
In these cases, sometimes using effects to play tricks on the user to make it "feel" faster does help, because there's nothing we can really do about it ...
When the fancy chrome gets in the way of basic functionality, I take the functionality every time.
There is a solution. Or rather, a way of mitigating it. Namely, unlike so many developers, when you look at a "feature", consider the drawbacks, not just the positive side. When you're considering adding something to a button that pulls in umpteen billion JS frameworks, consider if the bloat is worth it. When you're starting to reinvent the text box just so you can have tags, consider if the inefficiency is worth it. When you're considering reimplementing scrollbars in JS, consider if the UI problems you'll have are worth it.
And, you know, if/when you run across something that's problematic to do well, consider feedback. Among other things, the number of features of CSS that ultimately boiled down to someone going "there isn't a good way to do <x> currently"...
I'd be interested to see the other effects of effects. I've seen things on perceived time - but that's not the whole story. Does it affect user retention? Clickthrough rates? User mood?
Angular/meteor/etc do not generate sane output, as throwing up what is essentially an empty body tag (literally so, in some cases) is not only totally unusable outside the one use-case you have planned for, the page being generated is equivalent to a server error.
The correct solution, of course, is to render the page server side (and cache it, if you're sane), and progressively enhance any features such as XHR-style loading. Some comments later in this thread have mentioned that this might be an upcoming feature in the near future, which is great.
Without server-side rendering? That is still no excuse to serve up an empty page. Put some sort of fallback there, or a link to some alternative page. At a minimum, at least have a proper error message about how your site only only works in browsers that support javascript.
I really feel at this stage in the battle that that argument is hurting the call for server side rendering. Don't get me wrong, I have been a pusher for PE for many years but it quite clearly is falling on deaf ears these days.
The reason being is that it's very easy for someone to turn around and say "none of our users that we care about turn js off". However it is much harder to ignore the fact that initial page load times with server side rendering are minimal in comparison to the render-via-js frameworks of today.
I believe we need to follow the performance argument.
Did you really open a link about an angularjs project, with javascript disabled, just to be able to say it's broken?
(source: https://github.com/jsdf/hacker-news-mobile)
They really should be saying something like isoglossic (not a Greek scholar here) to imply that it's in the same language, instead of isomorphic, which implies a lot more than what they intend.
I find it easier to follow if you're looking around for alternatives.
1- https://github.com/angular/angular/blob/master/package.json#...
2- http://todomvc.com/
The web... has changed.
1. Doesn't have to do with Angular 2. Doesn't even have to do with a single page implementation
I made a really shit take on a single page reddit client, and I'm sure you'll see that the browsing experience is actually quite nice (and much faster than using native reddit). This was written in Angular 1.3, and Angular 2.0 is MUCH faster.
http://bredd.it.s3-website-us-west-1.amazonaws.com/
My point is that implemented correctly, even a content site like reddit or hackernews could work quite well with a single-page implementation. Don't blame Angular for this demo, its server responses are just impossibly slow