Don't depend on JavaScript to render your page
blog.donnywals.com
blog.donnywals.com
Hm, don't depend on a database when rendering your page? scnr
http://kephra.de/blog/Make_here_CMS.html <- shameless plug ;-)
This static site generator only requires make and bash. Being bilingual requires JS at the client, and the picture galleries are created by a 7 lines XSLT/PHP script under makefile control.
https://www.digitalocean.com/community/tutorials/how-to-inst...
I actually have javascript disabled on one of my mobile phone browsers simply for speed reasons.
However some STUPID developers need to be named and shamed.Like this one :
voxxed.com
that displays A BLANK PAGE ON PURPOSE WHEN JS IS TURNED OFF.
proof : in their css :
.hidden, .no-js {
display: none;
}
Rendering static content client side using JavaScript is a bad idea, even if you have fast network in terms of latency and speed.
The main problem with this AJAX antipattern is, that it blocks all spiders and search engines. So you should not do that, if you are not Google docs, who can inject the content into their own search engine, and wants its content not to appear on other search engines.
As a rule of thump: Do not use JavaScript for anything that should be indexed by a search engine. Instead use JS only when interacting with humans, e.g. for blog comments, checkout and payment. Hiding comments by making the comment system AJAX might be a good policy for a blog, if you do not want the comments to appear in search. But the blog posting itself should be static content.
And don't forget about other search engines. It's not very good to keep site indexable by Google and not indexable by other search engines.
Do you think the latter would work?
This conflicts with the goal, that blog post itself should be at delivered as a static content, at best from a static file, to withstand a HNDDoS even on low budget.
So one solution could be to run the comment system as AJAX, moderate user comments a few times a day. Click [x] on every comment, you want to appear in the static page, and [generate comments] to generate a new static page, with the new public available comments.
Give each user a cookie and a localStorage, to show their comments in their own AJAX version, even if you blocked them from both the AJAX comment system and the public one.
I believe the theory is that your application may take a little longer to load initially, but subsequent interactions should be much faster, since all rendering is happening on the client, and the server is only delivering API interaction. There is also the potential for even the initial render to be faster depending on what server-side rendering logic is being transferred to the client.
It depends on what you are actually doing and how much you cache client side, but for most cases that isn't going to make things faster for the end user.
Take the example of a theoretical blog post that takes 10ms to get from the database and 50ms to render on the server. You could potentially save server capacity by shifting that 50ms of rendering* from the server to client, but in actual fact the client (a low powered mobile device) probably renders it slower than the server.
The main thing though is this doesn't take into account the 2500ms round trip time it takes the mobile device to make a HTTP request. This is going to be the same whether you render on the client or server.
Now I agree it makes sense in some cases, if you cache the data on the client (ie an email client could cache the 100 most recent emails) then it will be faster, but the most services that use client side rendering aren't doing this, so there is no real benefit to the end user.
(Apologies if I'm just repeating the article, but it's down for me)
*Serialising into whatever format you API uses is still rendering, so you aren't actually saving 50ms.
But...
Clissold Leisure Centre is run by a charity. They've clearly gone for the cheap option here. Sometimes cost outweighs the benefit of spending more on the site - they needed a feature rich online booking application and got one that's a bit slow. It's possible that this is the best they could afford. It's also possible that the rendering time of the site has no impact on the signups or bookings that the leisure centre takes. In which case you have to ask - why should they spend more on a better app if there's no benefit to their business?
If it's not the case, you shouldn't use Angular at all.
If something really is dynamic, use a dynamic technique. If something is static, use a static mechanism.
Simple really...
I am currently using virtual DOM to render and I have no problem "rending my page using JavaScript" Even with an insane amount of page data that is rendered dynamically.
using pre-computed pointers to your page element makes so much sense coming from a background in embedded systems.
I have no idea how web-developers think they can get away with adding so much overhead to something as simple as rendering a page. we have bigger problems in the world like hunger and machine learning and why are you guys suck on figuring out how to render a page ??
[edit] someone gave me my first down-vote for posting this. I'll stand by it.
Developers are always struggling to find a solution of their problem. The best developers I know usually have in their pocket a big list of possible tools that they use in the appropriate time for the right job.
Handlebars Moustache Angular is something that is so popular that even this fact makes it "non-retard".
Virtual DOM is something new, but if you can find a solution not to use any dynamic DOM modifications, it would be even better.
Take a look at some complicated one-page apps ( pinterest, mixcloud ) and don't judge so much about the overhead.
Best
Probably because it's thought to maximize profit. Typically developers are expensive, but web site viewers have relatively fast computers. In addition, this decision to maximize profit over optimization is often decided by not the developers but for example the product owner.
http://www.downforeveryoneorjustme.com/http://blog.donnywals...
[1] http://webcache.googleusercontent.com/search?q=cache:9UMu5i7...
History seems to repeat itself. First there where dumb terminals where the mainframe did all the work. Then the age of the PC with heavy clients. Then the age of dumb browsers where the server did all the work again. Now the age of heavy browsers running javacsript.
The thing is, you have a capable programming language able to utilize distributed CPU resources in a safe manner, why would you not want to take advantage of it? Because a dumb spider can't crawl it? Simple fact is this is happening because it's obvious and it would be like fighting the rising tide to deny it, IMO.
No, he just didn't take his philosophy far enough.
The real way to do this is to make your pages static and serve them from a caching proxy. If you don't need dynamism then you shouldn't use it at all on production.
Without seeing his server and his backend code it's hard to make specific recommendations, but a single server with an nginx front-end can handle a lot of load. I've seen Wordpress handle a full-on Slashdotting without even breaking a sweat.
Is the web just supposed to be a bunch of static documents?
If you visited the site before, maybe the javscript rendering engine is already cached, all you need is the latest data not the layout.
Again maybe this isn't the best choice for a static site, but there is a continuum of sites from static to completely dynamic web apps. It's nice now that the developer has the choice to involve the clients resources at the point in that continuum of their choosing rather than it being off limits.
I agree JSON isn't always a big win compared to HTML, but it is lighter and typically contains only data rather than layout metadata, making it even lighter, along with doing partial update etc.
Going back to the old 2-tier client server days the database protocols such as SQL server TDS where binary extremely compact and efficient to parse requiring as little overhead as possible on the server to render and as little network overhead as possible. You are starting to see a resurgence of these ideas with bson, msgpack, protobuff etc. If you pair client side rendering with say msgpack you get even bigger wins in network overhead and server CPU time for parse and serialize.
The benefit of compression is that if you send a value once, sending it again in the same document is nearly free. This makes rendered HTML very inexpensive to send over the wire once compressed - there aren't that many HTML tags.
Plus, compression is quite inexpensive when compared to the overhead incurred by SSL.
> but it is lighter and typically contains only data rather than layout metadata
That layout metadata is still being sent to the client, only in the case of client side rendering it's sent in the form of JMX, or the initial HTML page, or... The only difference lies in the ability of the client to cache the layout (which works as well in a hybrid model).
> If you pair client side rendering with say msgpack you get even bigger wins in network overhead and server CPU time for parse and serialize.
This comparison (done by someone else) makes me think that this requires a bit more research before blindly following this advice.
Again on the server messagepack should be faster and use less CPU and require less bandwidth than json, the client will require more CPU but you have many more client CPUs than server CPUs.
Compression layered over text isn't free in any context, the closest it comes is pre-compressed static content, which would be great for the layout HTML,JMX and js files. Binary serializers like messagepack give you some space saving while also saving server CPU cycles rather than trading one for the other.
As I said there are a continuum of web sites from static text to dynamic and graphical. Benchmarks could be made at any point in the continuum to validate a specific approach.
My "argument" is simply that it is a good thing we can choose the approach rather than being limited to a server side model only. In many instances it can be more efficient allowing less server resources for a given load and lead to a better and richer user experience.
A blog, corporate landing page, forum... none of these are really that dynamic. Or where they are dynamic, they could be first served as static, letting Javascript take over once it's all been loaded.
At the very least, the initial data required by JS should be loaded with the rest of the page, letting JS start rendering the page immediately, instead of after another network round trip.
I think it will tend toward a homogenous compute environment, you can almost get a feel for it with javascript, node and say postgresql with plv8. Now your code runs anywhere in the stack you please, it's nice even if js ins't the best, but what is?
Deleted comment
So you don't trust the client and still need to do validation on the server, fine at least you can avoid sending invalid requests to the server and give the user instant feedback.
So you want to render a partial change to your page, have the server render a bunch of HTML from a database, or serialize the data minimally and have the client render the HTML. What about rendering visualizations of your data, chart, graphs etc, server rendering and sending jpegs, or client using canvas/svg? Nice to have that choice.
I started programming in the heavy client days, writing VB6 against Access databases or SQL server. This is how your typical business app was made and it completely consumed the mainframe/terminal model because you could scale on commodity hardware taking heavy advantage of the now relatively powerful distributed client resources. The server did as little as possible to get the data to the client for rendering/presentation also you could do offline partially connected things. Of course there where issues with this model, deployment was much harder and you had to trust the clients, plus databases generally didn't scale out at the time.
Then browsers came about, and everyone realized you could write business apps in them, but the old guys laughed at us because it was the dumb terminal model all over again. All validation done on the server, no deployment issues, no need to trust the client, network connection always required. Then javascript started getting better, hey I can do validation in the client again, but maybe do on the server still if you don't trust the client, but the user gets instant feedback, best of both worlds.
The choice about which layer your code executes in is important, it lets you make that CPU vs Memory vs IO trade off without leaving the client CPU on the table. I think this is one reason the mobile app model is so popular as well.
There is even a grunt module that uploads the generated site to S3, which is HN-traffic proof.
Of course if you need some dynamic content I also prefer not depending on javascript, which will allow proper bots crawling.
I would comment more if I can read the article, though.
The real way to do comments is the same way we've been doing it for years. Post to a form, load the new ones with a new page load. Better yet, push that functionality off to a system designed to handle it, i.e. HN.
Rendering only with javascript is only useful when the client loads and runs the javascript. The rest of us that see javascript as a very serious security and privacy issue get the actual page that is served up. I strongly recommend making that page a useful page in some way.
If a tool or framework doesn't provide that page, then maybe it's time to start filing bug reports about that tool's broken output.
Although to be fair, the number of people on HN who care about the security implications of javascript are grossly out of proportion to the general case. Near enough to 100% of people have javascript turned on by default that everyone else might as well be a rounding error.