> A server should serve. I to think too much front-end magic will slow down a site.
> However, I actually created this on that dual-core laptop you are talking about.
Right, which is why you have stuff in your code about dealing with the fact that sometimes rendering the bytes coming down the wire is painfully slow. You commented out the spinner GIF, which has replaced the Java applet loading, or the Shockwave loading, we knew so well in the 90s and 00s.
> So not to take away from your point, but let me also take this from the other perspective - bandwidth.
It would take visiting 3.4 posts of the size in the example before you would even reach the necessary bandwidth of the very first post.
Blog posts, by and large, get traffic for the single post in which someone is visiting and very, very rarely get hit up for a 2nd, and even more rarely a 3rd story on the same site.
Taking that into consideration, who is wasting more bandwidth?
> even if the browser might have to spend a few hundred milliseconds rendering
Gather up 3 or 4 times waiting a few hundred milliseconds and now you're waiting multiple seconds. Which is more than enough time for folks to hit the back button.
I'm not dogging your efforts or your library. I hope you don't see it that way. I am simply saying that the amount of work going into client-heavy development these days, and the amount of folks hopping on the: "Wow, that's such a great idea!" bandwagon, should be limited (educated).
A server should serve clients. There are human beings attached to the requests. We, as developers, should hold ourselves to a higher standard of doing whatever we can to remove burden from the clients.
I don't know where the idea that developers should be unburdened and servers shouldn't work hard came from, but it stinks.
Pay $0.00000001 to ask the 16 CPUs to wrap text in markup. Sheesh.
I'm sure there exist edge cases where the average user's browsing experience is slowed more by the additional bandwidth used downloading gzipped HTML tags on the fourth and fifth pages they visit than by the rendering script download on the first page and their browser running a script to generate a static layout features on every page.
But even then I'd wonder if the answer to save all that wasted time and bandwidth wasn't "maybe we could do even better if we compressed those images?"
I think the "edge case" here is "many if not most mobile connections" - not everyone has LTE and even among those who do, it's a highly variable experience.
In addition you are hitting those clients with a double-whammy: slow load over a slow connection, and slow rendering on a [relatively] slow CPU.
The edge case is one where the extra bytes in a set of plain old HTML files are actually more of a significant overhead than the JS/markdown alternative, which has a higher page weight for the first visit anyway as well as making more demands on client-side renderers. (In retrospect I could have worded the first post more clearly). Mobile is hardly likely to be this edge case since as you point out yourself mobile browsers will have a more perceptible delay when it comes to generating a page on the client side in javascript (and also can't display anything until the script is downloaded which is possibly a big first page performance hit, and aren't necessarily effective at caching the script for repeat visits)
Who suggested that having the client bear some of the load unburdens developers? I've done that kind of work, and it was some of the hardest work I've ever done.
And "servers shouldn't work hard" is a similar oversimplification, perhaps even a misapprehension. It's not so much that the server's cores should ideally sit idle, as that in almost any non-trivial application where scalability is even a concern, the server is probably already working hard, and having the client bear some load where it makes sense to do so can offer vast improvements in how quickly and well you're able to scale the application to meet demand.
> However, I actually created this on that dual-core laptop you are talking about.
Right, which is why you have stuff in your code about dealing with the fact that sometimes rendering the bytes coming down the wire is painfully slow. You commented out the spinner GIF, which has replaced the Java applet loading, or the Shockwave loading, we knew so well in the 90s and 00s.
> So not to take away from your point, but let me also take this from the other perspective - bandwidth.
It would take visiting 3.4 posts of the size in the example before you would even reach the necessary bandwidth of the very first post.
Blog posts, by and large, get traffic for the single post in which someone is visiting and very, very rarely get hit up for a 2nd, and even more rarely a 3rd story on the same site.
Taking that into consideration, who is wasting more bandwidth?
> even if the browser might have to spend a few hundred milliseconds rendering
Gather up 3 or 4 times waiting a few hundred milliseconds and now you're waiting multiple seconds. Which is more than enough time for folks to hit the back button.
I'm not dogging your efforts or your library. I hope you don't see it that way. I am simply saying that the amount of work going into client-heavy development these days, and the amount of folks hopping on the: "Wow, that's such a great idea!" bandwagon, should be limited (educated).
A server should serve clients. There are human beings attached to the requests. We, as developers, should hold ourselves to a higher standard of doing whatever we can to remove burden from the clients.
I don't know where the idea that developers should be unburdened and servers shouldn't work hard came from, but it stinks.
Pay $0.00000001 to ask the 16 CPUs to wrap text in markup. Sheesh.