Hacker News Reader

Comment by ForHackernews | Hacker News Reader

Am I the only one that kind of thinks most websites should just be static pages? Like, I get pretty irritated when I go to read a blog post on Medium or wherever and it loads a header and a blank page, and then loads a bunch of javascript (mostly tracking and analytics frameworks), and finally goes out and gets the actual content. And then if I scroll down, it has to load some more garbage from Disqus or something.

PLEASE JUST GIVE ME A STATIC PAGE WITH YOUR CONTENT.

I really do not care if the comments don't refresh live.

View on HN

So, you read an article about how easy server-side rendering is with React, and your first impulse is to rant about client-side rendering? Did you not read the post or did you just feel an overwhelming urge to posture?

>So, you read an article about how easy server-side rendering is with React

The article just says it's easy. It doesn't provide any concrete examples.

I imagine it would be easy in Node to do this but what about Ruby, Python etc.

> The article just says it's easy. It doesn't provide any concrete examples.

It doesn't provide code, but it points out that you can render to a string. It is literally that easy — you can just call React.renderComponentToString instead of React.renderComponent, though in practice there are Node libraries that make this even easier.

> I imagine it would be easy in Node to do this but what about Ruby, Python etc.

Well, it's a JavaScript library. If you can run JavaScript, you can render React templates. For example, Instagram is a Django app that runs a Node subprocess to render templates.

I think the author largely agrees with your beefs, since he's proposing this as a client-side and server-side rendering solution.

> I've thought for a long time (and blogged about it previously) that the ideal solution would fully render the markup on the server, deliver it to the client so that it can be shown to the user instantly. Then it would asynchronously load some Javascript that would attach to the rendered markup, and invisibly promote the page into a full app that can render its own markup.

That is, everything is rendered server-side for the reasons you outline, but that rendering logic also lives on the client should something need to update. This post doesn't detail exactly how to do all that, but it sounds like it's scheduled as a future topic.

My understanding is that since React has a virtual DOM, it can just render everything on the server with Node.JS, instead of evaluating it in a browser.

initial rendering should definitely be on the server, his premise to render content on the server side and then async load it in is flawed, he adds latency and the dom still has to parse a string at the end of the day and put them on the display tree, so the only bit he offloaded was a bunch of string concatenation (given he used a sane templating system) at the cost of latency. bad trade off IMO.

the downside to his reasoning is that he is tying himself to a single back end (node) if he used something like mustache he coulkd use any backend, but mustache implies parsing templates on the client. googles closure compiles to javascript functions and I am sure something like that exists for mustache and this would seem very sensical.

Converting a large string to a dom element is not expensive, it is when that dom element is added to the actual display tree when things go a bit awol, this is to be expected, redrawing any GUI costs a lot.

React is an excellent library and I am glad people use it, none of the ideas are radical however.

The important thing with this technique is you can render before any JS has been downloaded, parsed and executed, which is a huge amount of time relative to HTML parse and paint.

fwiw, React isn't tied to Node: I've used it with Django via PyExecJS (which just uses raw JavaScriptCore).

I started with this line: >initial rendering should definitely be on the server

this technique is called pre-rendering, and yes, I am amazed people don't do it.

"PyExecJS (which just uses raw JavaScriptCore)." this seems pretty slow or can you cache the execution function. (aka you don't have to parse the js multiple times)

Our backend is jvm so we decided on closure, with this on startup we compile our templates on the server and then pass the rendering functions around pumping the data into it to render initial pages. At the same time, we compile the same templates into javascript functions which are included into our app via the closure dependency system to render on the client. This has the advantage of not having to parse and "compile" a template at the point of delivery.

This is why I think react is an excellent library, because it allows anybody to do this and brings this notion into the minds of developers who jump easily on bandwagons.

I also think that the react team are well on their way to building a library which would fair excellently under all sorts of static analysis

PyExecJS is slow :)

We are actively working on more static analysis tools for React: it's certainly one of our major priorities.

i assume you work on the team at FB. Are you considering writing jsx compilers for platforms like the jvm?

Our approach is going to make js interop performant with our stack (which is not jvm). We don't have a concrete plan at this time. You would need more than jsx to make this work through (jsx is just sugar)

I suppose Rhino can also be used? :)

we use rhino for some types of testing. brutally slow.

I get your gripe, but there's a good use case for this stuff in building dynamic web applications. Just because a technology is misused doesn't mean the technology is to blame.

Browsers aren't general purpose applications. They can't fill every application role on the computer. The more "web dev" tries to push them in that direction, the slower, more difficult to develop and maintain, and generally poor they will be, and then the "dynamic web applications" that run on them will suffer.

What, for instance? Your comments seem heavy on condemnation but light on substance. Sure there are certain donation specific tools such as Photoshop or 3dsmax or ableton etc that wouldn't work in the browser, but for your day to day business 99% application, the user generally does not need to do anything that the browser cannot.

The fact is, the web world is evolving at an extremely fast rate, and leaving the native world in the dust.

I don't argue that the browser cannot be made to do something. I merely point out that making it do "everything" will only end up in disaster for browser creators and maintainers, and for app developers alike.

The "web world" hasn't even caught up to the native world yet. It may be evolving very rapidly, faster than native, even, but it's still behind.

What do you propose, exactly?

It's always easier to criticize than rectify.

I've just addressed that elsewhere in this thread:

https://news.ycombinator.com/item?id=7120285

For content sites, you are correct. But what about an in browser app, like Trello. Obviously in those cases javascript significantly improves the experience. So its just a case by case scenario. But I agree with the general point you are trying to make, and I work as a front-end dev who builds a lot of js heavy web pages/apps for a living.

The internet isn't all blogs. The use cases for React are kind of for the interesting web applications. Or even unity games with coherent ui.

Yes, Instagram is super slow because of all its useless Javascript. And it took Twitter years of optimization to make it about as fast as static HTML.

Actually, Twitter gave up on it every performing and everything is rendered server-side.

Actually, it gave up on performing _everything_ client-side, and now renders the first page server-side, and then handles subsequent rendering client-side.

It found a performant happy medium, which is something I hope React will enable a lot more people to do with a lot less work.

It doesn't. Subsequent requests are also rendered server-side and are passed down as HTML embedded in JSON that is splatted into the DOM. It isn't a lot of work to do this.

IMHO this is a bacon-salad problem:

Add some bacon (js) to your salad and you have a healthy and balanced meal.

make a "salad" out of bacon and and mayo dressing and you have a problem.

To a large degree I agree with your sentiment. I have never had to manage a site with thousands of pages but I would assume even then any template changes would not be that hard to render and then upload to a CDN.

http://mnmlist.com/w

Not all use cases are equal. Static pages might work great for static content, but what about something like GitHub? Wouldn't it be nice to see the issues list refresh live when somebody else closes one?

I find such stuff annoying, at least using it everywhere just because you can. Imagine you're reading hackernews, and halfway through reading a comment, it gets deleted. Or, say, you want to compare a page with the changed page one hour later -- easy, just open it in a new tab (and maybe do a hard refresh), right? Well, if everything is "real-time", that's not even possible.

Yes, there are use cases for it. But doing it just because you can, because it's supposedly "cool", is also hurting other use cases.

> Wouldn't it be nice to see the issues list refresh live when somebody else closes one?

Maybe a tiny bit. I guess. Really, I'd just reload the page if I wanted to see recent changes.

That's actually a perfect use-case for this render-serverside-update-clientside paradigm.

What are the cases for that feed role?

Why not deliver an RSS/Atom feed with the page and a standard feed reader within HTML that could present the content, polling at specified intervals.

In the same way that HTML finally standardized on HTML5 semantic page markup (not that HTML1.0 was grossly inadequate), and we're finally getting integrated video / multimedia support (though lacking the ever crucial "off" switch), once you dig through all the bullshit and hype, most of Web 2.0 corresponds to "we can update the page you're looking at while you're looking at it".

Some client-side capabilities to sort and filter content would finish off about 90%+ of the use cases. Good enough.

And you'd end up with far fewer monstrosities such as Facebook, Gmail, G+, etc., in which a simple content stream has a client-side footprint of 1-2 GB. SRSLY?

Yes, the standard problem of having users upgrade their client software to support the featureset remains, but there are still huge numbers of what are effectively Web 1.0 sites (Craigslist comes to mind) that are phenomenally useful and successful.

I've had a very late and passionate come-to-Jesus love affair with RSS/Atom feeds. Taking Craigslist, for example I can get an RSS feed of any given category search:

http://www.craigslist.org/about/rss

Remember "Web agents", you know "a personal online assistant that would scour the Internet for you"? Well, this is it.

Combine that feed with rsstail and multitail, and you can track items of interest in a console window. Find something particularly useful? Fire off an email alert to yourself.

http://www.reddit.com/r/dredmorbius/comments/1udv6i/further_...

I've got Chromium running on my Thinkpad T520i, sucking down about a gig and a half of RAM. newsbeuter tailing 85 feeds is around 300 MB (a single Chromium browser tab), and rsstail weighs in at about 145 MB resident. Since they're only intermittently active, they swap out with very little performance overhead.

The existing Web design model is a fucking trainwreck waiting to happen. The browser-as-app-platform metaphor has its advantages, mostly in rapid development, though that's also a weakness (users HATE change), and it's a bastardization of two competing uses (content vs. app).

Much of the design and feature set serves advertisers and NSA water-carriers far more effectively than it does users. Sadly, that's where the funding comes from, so it's no real surprise. Be careful what you incent for, you'll get it.

With the amount of inane FUD you're spreading I can't work out if you're genuine or a troll. Your text only/image minimal feed reader is using less RAM than a browser designed to load hundreds of images and get the most out of the RAM available to it? Shock and horror! And this "train wreck" you're referring to... I don't see it. I see happy clients that can pay once and get an application that is useable on any platform, from anywhere in the world, is as fast as a native application, and can be seamlessly scaled up to meet demand. Where is the downside in that? Game over, purely native apps, you lost the war (except for specific things that need to operate locally). Sure there are native phone applications, but they are essentially thin clients for web applications anyway.

You're absolutely correct that browser-based applications offer some very compelling advantages: they're run-everywhere (or at least, many wheres), they're rapid-deploy, they're particularly well-suited to data presentation and interaction tasks (which constitutes a large fraction of all apps), and rather importantly for small development shops, they offer a compelling path out of legacy support hell. These are all true.

So are my critiques. In particular, that the Web alternatives aren't as fast or light as native apps.

Purely native apps haven't "lost the war". They are the battleground for the most part on mobile devices, as you note, though you omit the observation that these typically operate via an API, which is in fact the direction I'm leaning as a hybrid browser/app model. Fully native apps retain crucial advantages in many spaces.

I'm curious as to what aspects of this you consider to be FUD? I'm reporting actual memory utilization for apps doing comparable tasks, at least as far as rendering raw information is concerned. If you want to consider graphical presentation, I've also got a number of PDF files open using xpdf and evince, both of which perform full graphical rendering including images. The maximum RSS for these is 14 MB, and the 20 or so processes running here have far less system impact than my chromium child processes.

The train wreck I'm describing is precisely that. Light websites are generally not an issue, but the full-fledged app instances, again, Google+, Gmail, and the like, cause wild amounts of swapping and instability, to the point that I make minimal use of them, and where possible find alternatives. The RSS/Atom readers I mention aren't doing the full work of a Web browser, but that's precisely the point: for keeping me informed of an information stream, they're far more than sufficient, and require far fewer resources. I can open an item in a console-mode browser (and yes, that's old-school and an acquired taste), or pop over to a browser and read the item. It's far less overhead than keeping the stream in my browser at all times, and as I noted, the RSS readers offer hooks to perform other local actions if I choose.

I've written recently of the frustrations I'm increasingly having with browsers in general: they serve neither the needs of application users nor of content readers particularly well. Quoting myself:

"It's neither a good reading environment -- for that you'd want something like Readability, Pocket, Instapaper, or an eBook management tool such as Moon+Reader, Kindle, or (bad as it is) Calibre -- nor a decent applications environment: it's bloated, crash-prone, slow, full of security holes, and underfeatured relative to native applications.

"However in both cases the browser's ability to load and display or run arbitrary content makes it convenient."

https://news.ycombinator.com/item?id=7062219

I see a few possible directions things could head:

⚫ Continue down the current path. This is the course of least resistance.

⚫ I don't know where the HTML working group(s) are headed, but continuing the pattern of HTML5 of offering highly semantic markup and leaning in the direction of an API model of HTML rather than a designer model (or in addition to) could be useful.

⚫ We now have <header> <article> <aside> and <video>. How about a <stream> as I described, and perhaps native <plot> features which could present graphics based on realtime data updates? Again, a huge class of applications now essentially consists of "poll regularly for new data, update stream, present graphics, respond to user inputs".

⚫ A content-oriented browser which strips out virtually all distractions, and provide vastly improved content management and referencing capabilties (see: zotero). Readability, Instapaper, Pocket, etc. approach this. I presently have a local "unstyled.css" stylesheet which I apply to many sites. It works best on bare-naked pages (without any native styling or table/frame based page layout) but works pretty well on most minimally-styled pages. And it is, for my purposes at least, almost always a huge improvement over native presentation. In other cases I've extensively modified how pages present themselves. See: http://www.reddit.com/r/dredmorbius/comments/1tniu3/user_sit...

⚫ An application-development platform based on (mostly) standard APIs and an HTML/SHTML transport back-end. This would be the area you're most interested in.

I'm not convinced this is the way things should go, but it seems it would resolve some of the present tensions in Web development and use.

Kids these days, not around in the 90s when all web pages were static and every link refreshed the entire page.

There's a happy middle ground between heavyweight javascript SPAs and static pages.

Frankly I love it when I interact with a web page and it doesn't have to reload the whole page just to update a single element, article, etc that I requested.

But neither am I fan of overly heavy frontend JS apps, like how Twitter used to be [1], or Quora seems to be, for example. Especially since I'm a chronic browser tab abuser where JS-heavy pages bring my browser to a halt or make it chug.

So yeah, aim for that sweet spot happy middle ground when possible.

[1]:https://blog.twitter.com/2012/improving-performance-on-twitt...

I agree. Static pages (with proper markup semantics) are automatically optimized for all browsers.

I know this may sounds sarcastic, but I am totally serious.

But not for all use cases. A completely blank static document will have the best possible performance characteristics, but the lowest possible utility. Writing needlessly slow things is stupid, but the blind pursuit of performance is missing the point.

I mind if it's not fast. I think everyone does. Doesn't matter if it's just or not. If it's not fast, I'll be irritated.

Statistically speaking, yes, you are the only one.

And when that old shopping cart demands a full page refresh: FOR FUCK SAFE JUST WRITE SOME JAVSCRIPT TO UPDATE THE QUANTITY

Completely agree with your point. It doesn't mean that we don't want/need dynamic user interface, of course. But the Web was designed to be static mostly. That's why the best experience we can enjoy is from the static web sites. Let's just recall what HTTP term means: Hypertext Transfer Protocol!

Sometimes you need interactivity. Yes, it comes at a price (small imo) but it's pretty useful.

I want to get you a beer at some point.

Ghostery+ABP end up blocking most of these annoyances (tracking, analytics, disqus). Very calming.

You're not the only one.

did some searching... turns out you can get medium content as rss feeds as well.

>Am I the only one that kind of thinks most websites should just be static pages?

No, the majority of people agree. And contrary to what javascript happy dumbasses keep repeating, the majority of new development is absolutely not doing everything client side. It is sad that the web is so fad driven, but this stupid fad will pass just like flash intros and spinning under construction animated gifs.

As long as enterprise continues to shift to a no-install web application based IT infrastructure, fad driven client based "web dev" will continue to increase in frequency and prominence. If (when?) people realize that the browser actually can't do everything this might change, but I wouldn't hold my breath. It's too easy to save a buck now by minimizing application development and support costs (browser-based web app vs. native) and let the poor idiot who takes over management five years from now worry about the fallout.

This is ridiculous. Building business applications as web applications have many advantages such as portability, network accessibility, speed of development, ease of development, speed. Over native apps. The sheer fact that you can hand off processing to the server and not block your entire ui makes the majority of web apps far better than the majority of poorly coded win forms garbage I've used.

Building an application by rendering static webpages is just a horrible cludge. How did we even get here? How are we still even considering that the godawful turd that is string concatenation of DOM descriptors polished by a layer of templating languages is actually a decent way of writing applications?

Do you seriously believe this?

The virtual DOM is probably the biggest elephant in the room. It begs the question: why the hell isn't the REAL DOM like that?

If you have to pose a really terrible strawman to argue for client side templates, you are basically conceding the argument. It is even worse given that moving it to the client doesn't change anything you complained about.

Haha, this got parodied by the horse. Anyway, I use angular.js. It tries to suggest a reasonable path forward for evolving the the DOM into something which is usable for applications. (resulting with web components, shadow DOM etc)

But yes I realized I'm arguing about the wrong thing - about web applications, not (most) websites. Whoops.

Internet itself was called "a fad" by some.

Reply on news.ycombinator.com