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.
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:
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.
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 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.
Comments
Much slower, why?
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.
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.
It's really great to hear that, thank you. Nice to know the performance crowd's rants are eventually being heard.
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:
http://bredd.it.s3-website-us-west-1.amazonaws.com/
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.
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?
I think it's the firebase api that's slowing everything down.
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 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.
FYI: The angular team is working on server side rendering: https://docs.google.com/document/d/1q6g9UlmEZDXgrkY88AJZ6MUr...
Well, it seems to be loading data in via websockets. Compared to server-side rendering of cached data, that's not going to be performant.