Hacker News written with Angular 2.0
hswolff.github.io
hswolff.github.io
1- https://github.com/angular/angular/blob/master/package.json#...
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
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?
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.
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
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:
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.
<div class="bodyContainer">
<hacker-news></hacker-news>
</div>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?
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.
The web... has changed.