
Instant Web Application - grabeh
https://glebbahmutov.com/blog/instant-web-application/
======
bahmutov
The blog post author (Gleb Bahmutov) here.

Thanks for commenting, this is a cool experiment I worked on, just trying to
eliminate the bootstrapping delay. Will be happy to answer any questions here,
via issues in the demo repos ([https://github.com/bahmutov/instant-vdom-
todo](https://github.com/bahmutov/instant-vdom-todo)), or in the library repo
[https://github.com/bahmutov/bottle-
service](https://github.com/bahmutov/bottle-service)

The demo itself runs from [https://instant-
todo.herokuapp.com/](https://instant-todo.herokuapp.com/) (please use Chrome
or Opera or enable ServiceWorker in the Firefox for now)

PS: Here is a little bonus, my current exploration where ServiceWorker might
be useful - run your server (like ExpressJS) inside the ServiceWorker ;)
[https://github.com/bahmutov/express-
service](https://github.com/bahmutov/express-service)

------
dham
Compare how over engineered this "instant web application" is with this todo
written in turbolinks [http://todomvc-
turbolinks.herokuapp.com/](http://todomvc-turbolinks.herokuapp.com/)

Basically just re render the app after each change. Works pretty well and no
need to setup pre rendering flux capacitor dual node virtual dom isomorphic
gulp flow.

~~~
ricardobeat
Turbolinks does not solve any of the problems that client-side frameworks do,
it's still just server-side rendering with enhanced performance. If you can
build your app with it, great, but these are different animals.

~~~
dham
Not really. I've done pretty well in my current app with Turbolinks partial
replacements. You can do more fine grain changes such as appends. You can tell
Turbolinks which part of the page you want to update. So if you have a counter
in the nav and a counter in the footer, when someone clicks a button your
response can update those other sections as well.

We've never had anybody complain about speed. If you can return responses in
100-300ms your good to go.

I do know it's limitations and that's keeping a lot of state in the client. In
that case I'll usually fall back to rivets or vuejs. Yes I said fall back.
People tend to go to a JS framework as the first solution. In my experience
that's usually not a good idea. You'd be surprised how little you need a JS
library, with a solution like Turbolinks

~~~
ricardobeat
> I do know it's limitations and that's keeping a lot of state in the client.
> In that case I'll usually fall back to rivets or vuejs

Exactly. We have always been able to do ajax loading even before Turbolinks.
Client-side applications are a whole different matter, they have a level of
interactiveness that is way beyond what's possible by sticking to server-side
rendering. This is not a pissing contest, I just think your comment missed the
point.

~~~
dham
Funny thing is, I haven't had a single customer asking for platform agnostic
backend services. I'll make sure I ask them about that though.

I can do all those things pretty easily with partial replacement. By a lot of
state I mean things like highly interactive forms. This is where I've
typically used Knockout or Angular in the past.

From what I see, developers these days use javascript frameworks for
ridiculous things, and it's out of hand. I haven't been to a single website
that uses React, Angular or EmberJS that actually needs it.

From what I can tell the background of React is, Facebook couldn’t create a
notification indicator on Facebook.com, so they create this over engineered
dump pile to solve that problem. Now they can tell you how many unread posts
you have while downloading 15 terabytes of Javascript.

Sprint.ly wrote a kanban board in React. As a customer I didn't care, there
service already worked fine. Seems they've abandoned it at this point though.
Probably couldn't take the React churn, or all the engineers have jumped to
the next latest framework.

Don't get me started on Discourse. Netflix.com, viewing some movies and
ratings? Been to several article sites that use React. For what? Yahoo.com re
wrote mail client in React. Guess what no one cared. It worked fine when they
owned Zimbra.

Catch my drift?

~~~
alextgordon
It's primarily a speed-of-light issue. If the server is on the New Jersey and
I'm in London, it takes a perceptible amount of time for the signal to travel
between continents.

The only way to remove this latency is for the client to take full
responsibility for building the UI, instead of playing a complicated game of
ping pong across the Earth.

While I don't particularly like React, that's what they're aiming for.

~~~
dham
The funny thing is, a lot of websites I visit that use client side frameworks
don't make optimistic/eager updates to the UI. You click a button, it hits the
server does the update, then updates the button state. Therefore they're
waiting for the roundtrip to the server before making the update anyway.

Just because something is possible doesn't mean people are actually using it.
To make some optimistic updates you have to duplicate logic on client and
server. It just gets really hairy especially when you're using auto increment
id's in your database. That's just one of the problems. The complications it
creates isn't even worth it. I'd rather just put a server in London. A lot
less hassle then dealing with this over engineered client side bullshit.

~~~
nilliams
> A lot less hassle then dealing with this over engineered client side
> bullshit.

I like to deal with client-side apps which talk to a simple JSON API. It's a
lot less hassle than dealing with this over engineered server side bullshit.

~~~
dham
JSF with Java EE. That was over engineered.

This Redux flux capicator, isomorphic, 4 Terabyte NPM install, 45 Babel
plugin, flow, dumb component pure functional, immutable js, virtual dom. Now
that's over engineered.

I built more complicated stuff with Knockout.js in 2011 then half the stuff I
see people building with React(which from what I see is just news sites and
forum software)

------
revelation
Yes, that is a nice solution to the _users randomly pressing reload_ problem,
if you consider that one.

For everyone else, there is server side rendering.

~~~
patrickaljord
It's not only for people hitting reload, it's also for people visiting the app
more than once such as slack, gmail, facebook or inbox. Pretty cool. It
doesn't solve the first load though that's ok for web apps.

------
mchahn
The idea of saving the rendered version of the app instead of recreating it
server-side is very interesting. However I think this implementation limits
its usefulness.

It would be very interesting to explore just sending the newly created page
back to the server and then using it for new page loads. The state could be
updated after the load. Code is needed to update the state anyway in normal
usage.

~~~
jplur
You're suggesting people send their html back to the server when they've
finished reading it.

~~~
mchahn
Actually I thought it would go back to the server immediately after loading
and rendering. Having more time to think about it, I think maybe it's a stupid
idea. You could render it in the server with ghost or something just as
easily.

------
imaginenore
Unfortunately local storage is limited by 5MB. It's probably enough for simple
apps, but will it work with any real world projects?

~~~
bahmutov
The app saves its state in whatever form it wants. The demo saves it in
localStorage that is very limited. One really should look at something better
like IndexedDB or WebSql (or something that hides the technical details, like
localForage or PouchDB).

~~~
imaginenore
WebSQL is not supported by IE nor FF, and is limited by 50 MB.

IndexedDB is limited by same 50MB, 5MB on mobile, and is only partially
supported by IE, Safari and iOS.

~~~
bahmutov
That's why I recommend using PouchDB to work with whatever API is available.
Storage limits are harder to work around, but if your HTML snapshot weights
more than 50MB (or even 1MB!) that it is a problem by itself.

------
sotojuan
Curiously enough, the Ember TodoMVC[1] doesn't seem to suffer from the issue
here, at least for me. Can anyone say why? I don't know much about Ember.

[1]
[http://todomvc.com/examples/emberjs/](http://todomvc.com/examples/emberjs/)

~~~
bahmutov
seems to flash for me, add a few todos and then hit reload

------
bikamonki
I did something similar for a Backbone app. I have the last rendered html on
cache (when it is too big I have to use the server, although I store it as
plain static html). Only after 'instant render' the page I find exisiting DOM
elems and create+assign the corresponding views. Voilà!

~~~
bahmutov
Exactly!

------
alttab
This makes me shake my head for so many reasons. Way, way too clever for 99%
of Web applications.

