6 ms·

Another neat show of letting the client deal with the rendering. From the example[1]: "You see, there is really no need for the server to generate anything fo

Another neat show of letting the client deal with the rendering. From the example[1]: "You see, there is really no need for the server to generate anything for simple article-based sites like this. If the user wants to read your blog they can spend a few processor cyles[sic] to render the page themselves." This paradigm is beyond me and it seems to be growing for whatever reason. Client-side processors rendering bytes through a separate engine, other than the HTML one, only to have it eventually run through the HTML engine so the client can actually read it. The thought that everyone has a decent machine to do the processing is, in my experience, still a false one. This was true 5-10 years ago, and I haven't seen evidence that it isn't still true today. Your server probably has many, many cores. Probably SSD architecture. It is barely blinking to answer a request and deliver text. Why on earth would you leave the simple job of wrapping markup around text, to a machine that you know nothing about? The average Internet user isn't terribly savvy. Their browser is possibly cluttered with add-ons. Their computer more than likely running 100s of background processes they know nothing about. Depending on the stats you look at, in 2014, we're looking at a lot of folks with dual-core machines and a couple GB of memory, if they are lucky. I can't understand why you would want to delay or hinder the experience to getting to your content. While it may load really fast on your Macbook Pro Retina, or ThinkPad X1, that has a few text editors open and an up to date browser, the experience won't be true for everyone. When did it become trendy for developers to put burdens on their clients with all of this front-end first thought? Just because it makes it easier for you to write and deploy, doesn't give you the excuse to put the burden on the user for rendering your stuff. How many more times do we need to read about companies being forced into dropping this ill-conceived paradigm because they realized it made the experience for the client worse, and in many cases, made the development worse as well? In this example, we end up with an HTML file that is all of 6,084 bytes. To get there in this example, we used jr.js, a 5,616 byte file, to load showdown.js, a 14,859 byte file, and render 651 bytes of text. Sometimes, the loading and rendering is so slow, that the code itself has handling for it: // Empty the content in case it takes a while to parse the markdown (leaves a blank screen) jr.body.innerHTML = '<div class="spinner"></div>'; 21,126 bytes to generate 6,084 bytes of text which has to now be rendered (one more time) by the browser. Wouldn't it be great if there was some standard about the bytes that were delivered over the wire that everyone could use and build upon? Folks should get together and build a really good processor of bytes coming over the wire that's delivered in a particular format to be rendered on the screen. It would be great for the Internet! You could browse the entire thing! [1] - http://xeoncross.github.io/jr/ http://xeoncross.github.io/jr/

Xeoncross 12y ago
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. So not to take away from your point, but let me also take this from the other perspective - bandwidth. The 6kB + 15kB Javascript files only initially seem to be a waste. After you think about the bandwidth you save transferring all the additional pages in plain markdown and using the (now) cached JS build each page actually results in much faster loading times even if the browser might have to spend a few hundred milliseconds rendering.
- randomdrake 12y ago
  > 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.

Xeoncross 12y ago

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. So not to take away from your point, but let me also take this from the other perspective - bandwidth. The 6kB + 15kB Javascript files only initially seem to be a waste. After you think about the bandwidth you save transferring all the additional pages in plain markdown and using the (now) cached JS build each page actually results in much faster loading times even if the browser might have to spend a few hundred milliseconds rendering.

randomdrake 12y ago
> 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.