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
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.
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?
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.
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
> 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.
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.
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.
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.
Our product, Elevate Web Builder, creates fat-client web applications, and they are much, much simpler to implement than a hybrid approach because you're only coding to one environment at a time (browser, server). They are also much lighter on bandwidth requirements because most data transfers are simple JSON and not content. You can see this here with a demo that loads the IP address ranges for various countries into a grid:
(our server is in Chicago - SingleHop is fantastic)
Yes, you do make a valid point that things like optimistic database updates can be problematic, if not planned for. However, I would counter that the end result is much more durable and scalable than the alternative. If you build your application to handle distributed, optimistic transactions to a back-end JSON-based API (our dataset API does about 98% of the work for you), you're well on your way to having a distributed application that can be run anywhere and maintains a nice separation of concerns where the front-end or back-end can be swapped out as different needs arise. That, to me, seems to be a much better position to be in than one that requires a mix of both client-side and server-side content generation, which intimately ties the front-end to the back-end (brittle).
> 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.
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)
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.
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.
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.
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.
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).
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.
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à!
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.
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), or in the library repo https://github.com/bahmutov/bottle-service
The demo itself runs from 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