6 ms·

Compare how over engineered this "instant web application" is with this todo written in turbolinks http://todomvc-turbolinks.herokuapp.com/ http://todomvc-turbo

by 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.
    - dham 11y ago
      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 11y ago
        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 11y ago
        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.
kevindeasis 11y ago
So all this concept is new to me. I've skimmed over it. So, everyone is saying turbolink is just like pjax: https://github.com/defunkt/jquery-pjax https://github.com/defunkt/jquery-pjax There is also something interesting I've seen before in Java & Scala. It will run your code and render it automatically in the browser. If the other parts of the code is not finished it will later send it to be rendered to the web page. It happens in a single url path and it is not a single page application. Does anyone know what this is called? Edit: I figured it out, by using playframework you do this by send a chunked response by streaming it. https://www.youtube.com/watch?v=l7IYY08Bb_4 https://www.youtube.com/watch?v=l7IYY08Bb_4 So you can stream chunks in node as well: http://stackoverflow.com/questions/11906198/node-js-write-http-response-to-stream http://stackoverflow.com/questions/11906198/node-js-write-ht... Strongloop: https://strongloop.com/strongblog/streaming-chunked-html-node-js-data/ https://strongloop.com/strongblog/streaming-chunked-html-nod...
bahmutov 11y ago
ok, server-side rendering, why don't you run the entire server inside the ServiceWorker then for speed? https://github.com/bahmutov/express-service https://github.com/bahmutov/express-service
munro 11y ago
This is for when there isn't a web server. I assume the impetus for this experiment is for Chrome apps, judging by the mention of Chrome Desktop. > The larger question I want to answer is this: > Can we recreate the same "instant" page loading experience in our web application without the server-side rendering If one were using a web server, virtualdom is easy to render on the backend. Also it would be simpler than having to patch sluggish UX with pjax.

by dham 11y ago

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

kevindeasis 11y ago

So all this concept is new to me. I've skimmed over it. So, everyone is saying turbolink is just like pjax: https://github.com/defunkt/jquery-pjax https://github.com/defunkt/jquery-pjax There is also something interesting I've seen before in Java & Scala. It will run your code and render it automatically in the browser. If the other parts of the code is not finished it will later send it to be rendered to the web page. It happens in a single url path and it is not a single page application. Does anyone know what this is called? Edit: I figured it out, by using playframework you do this by send a chunked response by streaming it. https://www.youtube.com/watch?v=l7IYY08Bb_4 https://www.youtube.com/watch?v=l7IYY08Bb_4 So you can stream chunks in node as well: http://stackoverflow.com/questions/11906198/node-js-write-http-response-to-stream http://stackoverflow.com/questions/11906198/node-js-write-ht... Strongloop: https://strongloop.com/strongblog/streaming-chunked-html-node-js-data/ https://strongloop.com/strongblog/streaming-chunked-html-nod...

bahmutov 11y ago

ok, server-side rendering, why don't you run the entire server inside the ServiceWorker then for speed? https://github.com/bahmutov/express-service https://github.com/bahmutov/express-service

munro 11y ago

This is for when there isn't a web server. I assume the impetus for this experiment is for Chrome apps, judging by the mention of Chrome Desktop. > The larger question I want to answer is this: > Can we recreate the same "instant" page loading experience in our web application without the server-side rendering If one were using a web server, virtualdom is easy to render on the backend. Also it would be simpler than having to patch sluggish UX with pjax.