* Intercept link clicks and form submissions and perform the exact same request asynchronously (AJAX)
* Wait for the server to respond with the parts of the page that need to be swapped-out (a JSON map of section IDs to plain HTML content) and, as expected, swap out those parts of the page.
This works REALLY well for, like, 80% of my use cases. With a little extra flavor functionality (such as automatic loading indicators and event listeners) I can enable like 90% of interactivity. The remaining 10% consists of things that affect only temporary state and don't require a server round-trip (e.g. a "select all" checkbox), and those I would handle with more traditional jQuery DOM manipulation.
For the most part, once I had this basic system in place, I could rely on the server to render (and re-render) all of the HTML and rarely had to write any custom Javascript. I was essentially relying on the behavior of vanilla links and forms. The site would even continue to function if you disabled Javascript, because the server would see that it wasn't AJAX and just render the whole page instead. The downside was that preserving local state (e.g. partially completed form fields) was tricky whenever I had to make a change to one of its parent containers.
Everything I learned about this approach eventually led me to appreciate what React.js is doing. I've been using it and I may not like all of its API or how heavy it feels overall, but the cycle of rendering and re-rendering different parts of the page feels very natural and is far easier to debug than most JS-heavy front-ends.
When I approach a link, I hover, see the href on the status bar, think and decide, and click. Thereafter, I expect it to take me somewhere else, while the browser pushes the url of the page I left into a stack, the history. This implemented and working in my browser already, why redo it with JS? To lower the load time? Then don't make the page multi-meg already, no?
The ugly thing is govt websites and such are adopting a similar style of web app design, relying upon wizardy and tricks and hacks, for example, I sweat blood when I use my uni's web pages because I'll hit a bug in the js for an already-there popup or a button and it'll hurt my educational career.
> why redo it with JS? To lower the load time? Then don't make the page multi-meg already, no?
I hear you, and often I let links do their full behavior, no JS magic involved.
But beyond a certain amount of interactivity, the AJAX intercept approach does add a few things beyond just load time:
* Even if your payload is very small, the HTTP round trip can make the interaction feel slow, especially if your browser has to go through the full load+render routine. Things like images and sometimes even the whole page will flicker. When all you need to do is update a very tiny portion of the page, having a thin JS layer on top of your usual link/form element can be a significant UX improvement.
* Say you have a page with a few interactive buttons/links and a form with text input. Without any AJAX, if you click a button or link (that isn't the form's submit button), it will wipe anything you had entered into the text field. Not a great experience.
The browser does this already.
> Even if your payload is very small, the HTTP round trip can make the interaction feel slow, especially if your browser has to go through the full load+render routine. Things like images and sometimes even the whole page will flicker.
Browsers are very smart these days, caching many things. And if the bloat is eliminated (unnecessarily large images [make thumbnails], custom widgets [use what's there], etc.), if you webpage is not the whole of the Emacs or FreeBSD manual, it'll load in about a second or so at worst. The progressbar will indicate that it's loading, so the user will know that the server is live and he's not standing there waiting to see a HTTP 50* or 40* or a lookup error.
> Say you have a page with a few interactive buttons/links and a form with text input. Without any AJAX, if you click a button or link (that isn't the form's submit button), it will wipe anything you had entered into the text field. Not a great experience.
Also an inexistent experience. Most browsers do retain the contents after navigation, both ways. I use xombrero and it does. Chrome too, I just tried it.
If downloads of your web pages are >1sec, check your web application, web server, proxies, asset file sizes, loading order, internet connection, status of hosting, etc. Use default widgets on your forms and don't fiddle with their default behaviour. Otherwise when everybody puts out their shiny new idea, the users become timid to click anything. But I guess if all the websites were like this thousands of front-end devs and web designers would lose their jobs, and thus we have all these websites.
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.
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?
A second is slow, and should absolutely not be the standard we're aiming for. If AJAX allows you to get closer to the ideal without messing with the typical browser workflow, why not use it?
Try browsing https://dev.to/. It feels good, no? That's the standard we should be aiming for, and it's made possible in part with exactly these ideas (see: http://instantclick.io/).
I guess the problem is nowadays the designer folk gets to say too much on the development of websites and web standards. There is no prerequisite to become one. If you didn't study CS in depth, at the uni or by yourself, you can't do embedded, OS dev, etc., but mashing together some stuff from Github you become a web designer, no qualifications needed.
Here we have a website that talks about bloat and lists nine or ten tools that have well established, better, more generic counterparts. Generating a file from another via a filter program (minifier, m4, awk, coffeescript compiler...) is what make excells at. Replacing strings is what m4, awk and sed do since 1980's. We don't expect from the designer folk to know anything about the basics of computing. And they spend their time duplicating and triplicating and quadruplicating effort spent decades ago to end up doing the same thing, only worse, and when it comes to actual work, all they do is mix and match some libraries and add bloat after bloat, instead of looking to see what needs to be done, and doing it, using the tools already available and fit.
(1) Otherwise I'd have to implement a foreach macro, which would take some 10 lines more.
Also from your other comment you would like Ajax to not be used in websites?
They also write a lot of JS and CSS that face the web. I didn't want to say that they should learn/know CS, but just some basics of computing, if they're going to write code that runs on others' machines (JS).
> Also from your other comment you would like Ajax to not be used in websites?
I would like the normal behaviour of browser widgets (links, buttons, forms) let alone. New widgets are OK with me, e.g. an interactive map, a carousel, a dropdown menu. You get to define the behaviour of these tools, but a button, a link etc. has an associated meaning with them.
JS/Hypertext was not initially meant for engineering anyting, so it's not analogous to a combination of UI toolkit & proper programming language & a compiler.
[1]: http://unpoly.com/
The problem boils down to managers/designers hating default.
As an example, take form behaviors.
Default forms work. Built-in browser verification (for supported browsers) works. You can even have it match a regex! Built into the browser! Dropdowns in browsers? Those work too! So do radio buttons and checklists!
Instead, people are tasked to reinvent the wheel and create their own hacky dropdown lists because they want things sorted into groups (what is an <optgroup>?) and they want super precision over how the list ends up getting styled.
As a consumer: I absolutely hate this. I love browser defaults because I can expect all forms to just work. If I hit the letter "G" in a dropdown list I know how it will function! All of this knowledge is tossed to the side unless the reimplementation tries to remain faithful to the browser defaults.
I know some developers are guilty of wanting to make custom things too - but by far it is a problem with clients and management. I always have to fight against anything that would change default browser behaviors because the UX on such things is terrible 99% of the time or whatever implementation via JS is going to either take a large amount of time or be buggy as hell.
Your users are going to primarily be using a single browser (per device) and expect each device to be, at least, consistent with itself. This is an area I feel devs make the largest mistake: they want browsers to conform to one another. That means they'll break default functionality to get there! I'm of the opinion the browser should change. That allows users of the browser to adapt to the new default (because every site will then be consistent for the user!)
Functionality can differ between browsers [0] and your IE users will expect the numeric input field to function like it does in IE. Not like it does in Chrome/FF/Safari. Meanwhile, your Chrome/FF/Safari people will expect it to function how it does by default in their browsers. You shouldn't override or change this functionality because it breaks user expectations. Overriding IE because it is the "odd one out" will break expectations for users using IE!
It doesn't matter so much if the experience is different for each user so much as the experience is consistent for each user within their environment.
[0] https://css-tricks.com/numeric-inputs-a-comparison-of-browse...
If all these fields had nice clean ways to style them so they looked the same cross browser (even with different defaults and behaviour), then there would be less people using these giant scripts and frameworks.
No they don't, in my opinion. They're sensitive to XSRF attacks, a breach nicely kept open by browsers so you can embed a MailChimp form on your website and it gets posted to MailChimp. 90% times I program a form in Ajax is to use JSON content type, hence suppressing the cross-site risk. The other option is to put an encrypted token in your form, but I don't like keeping things in session.
> Dropdowns work
Aaaaaaand that's why design can ruin a feature. <select> work indeed excellently for 90% situations, but it repels your customer, more than using an unprotected ?clientId= in the URL. If browser used a Select2 design by default, I bet it would be used more often.
Here is the very first thing I tried (and is how I fill out forms) to select my State from their examples.
Tab (to focus field) -> AA -> Tab
The default select field? Gives me Arizona as expected. The select2 drop down? Fails to give me anything. It doesn't expect "AA" it expects "Ar" and tab doesn't set the value, so even typing "AR->Tab" doesn't give Arizona, it expects "AR -> Return".
Minor - and very possibly worth the trade off for the search functionality. But I detest breaking defaults when possible, even if I disagree with a default personally.