Let's Make a Single Page Web(tallpixels.com)
tallpixels.com
Let's Make a Single Page Web
http://tallpixels.com/lets-make-single-page-web/
2 comments
My simple software worldview is as follow.
1) HTML/CSS for templating 2) JS for state management. 3) HTTP for data persistence/distribution.
I don't think technology stack will change radically, rather, new frameworks will be created and old frameworks updated to fit this paradigm. We are beginning to see that in the current wave of client side frameworks - Ember, Angular, Batman, etc.
It seemed to me that Turbolinks while improving page response, does not address data-binding/modeling and offline/low bandwidth support which seemed to be the path taken by the clientside frameworks towards making JS as a state manager.
1) HTML/CSS for templating 2) JS for state management. 3) HTTP for data persistence/distribution.
I don't think technology stack will change radically, rather, new frameworks will be created and old frameworks updated to fit this paradigm. We are beginning to see that in the current wave of client side frameworks - Ember, Angular, Batman, etc.
It seemed to me that Turbolinks while improving page response, does not address data-binding/modeling and offline/low bandwidth support which seemed to be the path taken by the clientside frameworks towards making JS as a state manager.
Do you see this new stack of technologies as a gradual evolution of our current stack, or do you feel the technologies are inherently broken and need to be replaced completely?
"Re-rendering navigation is not acceptable"
Why? Does the tiny electronic miracle on your lap or desk that is more powerful than the sum of all computers that existed in the world in 1970 have something important to do or something?
Why? Does the tiny electronic miracle on your lap or desk that is more powerful than the sum of all computers that existed in the world in 1970 have something important to do or something?
Our web technology is such that we don't need to settle for a sub-par user experience that is a relic of the days where we had to serve static HTML documents one by one.
No, but the user looking at it has something better to do than watch the browser window flash white and then pop in again as the page loads and renders.
These two things are not mutually exclusive.
The important things to do in this case are figuring out which part of the website is header, nav etc and not refreshing them while navigating.
It is not about performance savings, it's about the user experience. Functionality like this can be baked into websites today (basecamp-next et al), but surely it will get easier (I am thinking semantic element which already tell the browser what is a <nav>).
It is not about performance savings, it's about the user experience. Functionality like this can be baked into websites today (basecamp-next et al), but surely it will get easier (I am thinking semantic element which already tell the browser what is a <nav>).
That's an interesting idea having the browser handle the nav persistence. I assumed it would be done with JS but I supposed when it becomes common enough having it baked into the browser would be a better idea.
If the difference in experience between web and desktop apps is going to keep decreasing, eventually, I think the stack of technologies will be completely changed.