6 ms·

Instant Web Application

128 points by grabeh 11y ago

deleted 11y ago
[deleted]
- Spone 11y ago
  seems off-topic to me :)
- cjhveal 11y ago
  I'd say it's no advantage in itself when it comes to software. In general I'd say most people view it as a negative signal because grad school delays entry into industry by a few years (reducing practical in-the-wild experience) and tends to be associated with "ivory tower" concerns rather than pragmatism. That being said, most hiring decisions I've seen (at companies with good software recruiting practices) have been based on what you can produce, rather than what your credentials are. You might get a phone screen with some high level questions to make sure no one's time is wasted, but after that, the candidate sits down with the team and builds something. If you can work well in the environment and have skills that complement the existing team, what you did in school tends not to matter as much. This can be different if the role requires specific knowledge and deeper understanding, such as building distributed systems under certain parameters, cryptography, database architecture, or machine learning, to name a few. But even still, simply having a Ph.D. isn't necessarily an advantage. In this case, I think the author's understanding of bleeding-edge web standards, demonstrated ability to build a prototype using them to enhance user experience, and clear exposition of the problem and his solution would be much stronger signals as to his employability than his education.
revelation 11y ago
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 11y ago
  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 11y ago
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 11y ago
  You're suggesting people send their html back to the server when they've finished reading it.
  - mchahn 11y ago
    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.
- NickNameNick 11y ago
  Surely that would open you up to the worst possible kinds of XSS.
imaginenore 11y ago
Unfortunately local storage is limited by 5MB. It's probably enough for simple apps, but will it work with any real world projects?
- gkop 11y ago
  Good point. The behavior documented in the videos (refreshing the page) could make use of session storage as well as local storage, which might buy a bit more space. But unlike local storage, session storage is not shared across tabs/windows nor persisted over browser restarts. So session storage isn't really useful for the bigger problem.
- bahmutov 11y ago
  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 11y ago
    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 11y ago
      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.
alttab 11y ago
This makes me shake my head for so many reasons. Way, way too clever for 99% of Web applications.
sotojuan 11y ago
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 11y ago
  seems to flash for me, add a few todos and then hit reload
dham 11y ago
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.
- sotojuan 11y ago
  Code here for anyone interested: https://github.com/nateberkopec/todomvc-turbolinks https://github.com/nateberkopec/todomvc-turbolinks
- ricardobeat 11y ago
  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 11y ago
    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 11y ago
      > 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.
bikamonki 11y ago
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 11y ago
  Exactly!
bahmutov 11y ago
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

128 points by grabeh 11y ago

deleted 11y ago

[deleted]

Spone 11y ago
seems off-topic to me :)
cjhveal 11y ago
I'd say it's no advantage in itself when it comes to software. In general I'd say most people view it as a negative signal because grad school delays entry into industry by a few years (reducing practical in-the-wild experience) and tends to be associated with "ivory tower" concerns rather than pragmatism. That being said, most hiring decisions I've seen (at companies with good software recruiting practices) have been based on what you can produce, rather than what your credentials are. You might get a phone screen with some high level questions to make sure no one's time is wasted, but after that, the candidate sits down with the team and builds something. If you can work well in the environment and have skills that complement the existing team, what you did in school tends not to matter as much. This can be different if the role requires specific knowledge and deeper understanding, such as building distributed systems under certain parameters, cryptography, database architecture, or machine learning, to name a few. But even still, simply having a Ph.D. isn't necessarily an advantage. In this case, I think the author's understanding of bleeding-edge web standards, demonstrated ability to build a prototype using them to enhance user experience, and clear exposition of the problem and his solution would be much stronger signals as to his employability than his education.

revelation 11y ago

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 11y ago
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 11y ago

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 11y ago
You're suggesting people send their html back to the server when they've finished reading it.
- mchahn 11y ago
  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.
NickNameNick 11y ago
Surely that would open you up to the worst possible kinds of XSS.

imaginenore 11y ago

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

gkop 11y ago
Good point. The behavior documented in the videos (refreshing the page) could make use of session storage as well as local storage, which might buy a bit more space. But unlike local storage, session storage is not shared across tabs/windows nor persisted over browser restarts. So session storage isn't really useful for the bigger problem.
bahmutov 11y ago
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 11y ago
  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 11y ago
    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.

alttab 11y ago

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

sotojuan 11y ago

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 11y ago
seems to flash for me, add a few todos and then hit reload

dham 11y ago

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.

sotojuan 11y ago
Code here for anyone interested: https://github.com/nateberkopec/todomvc-turbolinks https://github.com/nateberkopec/todomvc-turbolinks
ricardobeat 11y ago
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 11y ago
  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 11y ago
    > 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.

bikamonki 11y ago

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 11y ago
Exactly!

bahmutov 11y ago

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