I guess my overall point here was that you can build a sufficiently interactive webapp without a bloated, client-side, MVC, virtualDOM, JS monstrosity.
Given the fact that most of the bloated JS monstrosities you're talking about are also the most popular websites around (Facebook, Google, Pinterest), I think this assumption might be wrong.
Do you have any examples of popular, complex web apps that work the way you suggest is better? Why is it that Facebook etc don't make things that work the way you're talking about?
Re:CSS Purge
by aregsarkissian on Saturday May 21, 2016 @12:17PM
(#11745171)
I think he means sites that are not as complex as Facebook etc think they need to use the same framework as Facebook etc uses where they would be perfectly fine using the pjax/turbo link style approach the op suggests
I guess my overall point here was that you can build a sufficiently interactive webapp without a bloated, client-side, MVC, virtualDOM, JS monstrosity. And that there are widely varying degrees of complexity to these implementations.
So, on the one hand, you have Ember, Angular, Backbone, React, etc. On the other hand you can have what I described. A very thin, very maintainable layer on top of what the browser is already doing.
That was the point.
Anyway, one other thing:
> Most browsers do retain the contents after navigation, both ways.
That's not what I meant. What I meant is that sometimes you need a button or link to take you back to the exact same form, just update the page slightly. (Add an optional field, etc. Think if you are entering an "album" and need to add a list of "tracks"). Without any JS/AJAX, that "add track" button will require a bit of finagling to not clear out the rest of the form that you've already partially filled out (but aren't ready to submit). I don't know if my example is entirely clear, but it's about enabling a certain amount of interactivity without relying on more standard JS bloat.