4 ms·
SEO was our first concern, but then we realized performance was the big win. Serving the user a full page of HTML rather than waiting for JS to download before
by frontendbeauty 13y ago
SEO was our first concern, but then we realized performance was the big win. Serving the user a full page of HTML rather than waiting for JS to download before rendering HTML makes a big difference, especially on high-latency or low-bandwidth connections (mobile).
EDIT: We decided against using something like PhantomJS or node-chimera because why deal with a DOM if you don't have to? DOM is complicated and slow, compared to string-based templating. Plus, it's another moving part, another process to keep up and running. The Meteor guys aren't too excited about the PhantomJS approach either, and IIRC they'd like to be able to serve HTML without firing up a DOM.
- msoad 13y agoDoes this mean Rendrjs applications will run in a JavaScript disabled browser? That would be a big win!
- frontendbeauty 13y agoYep! Because links use full URLs which get intercepted by JavaScript, if JS is disabled, you can still navigate around the app, getting full HTML from the server. Of course, any client-specific code wouldn't run (slideshows, etc).
- jonny_eh 13y agoSo far, this is the most convincing argument I've heard for Rendr.
- bilalq 13y agoI'm a little confused here. Maybe I'm just not seeing it, but how does that make Rendr any different from any other server-side framework that responds with HTML?
- WickyNilliams 13y agoBecause you're using the same JavaScript code for rendering on either the client or the server.
- deleted 13y ago[deleted]
- pbiggar 13y agoCool stuff, thanks for the response!
- aristus 13y agoHow do you measure performance? I'm interested specifically in where & how you instrument, and how you collect the data.