* 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.

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/

http://userbag.co.uk/demo/pjax/

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.

Use data, not rules.

Edit: I'm not saying it's right. I'm saying I understand.

There's nothing at all wrong with thinking your file is getting a little out of hand even when there are examples of wanton recklessness all around you. That's as true even when there's nothing more you can do to make it smaller. I wish there were more people who had a sort of knee-jerk Hayes Smartmodem kind of reaction to everything they do that doesn't involve things like video and such. There's nothing quite like a page that's loaded and ready to rock about the same time the "I've clicked something" haptic feedback makes it to my brain.

There are very few things that I would style for a text-based website:

1) The h1, h2, p, strong, and a elements. Font-family, font-size, color, a:hover, and line height attributes only.

2) Create a container (eg: max-width 44em, margin: 0-auto, width: 100%) to wrap everything in.

From there the "heaviest" parts of the blog would be navigation and how accessible you want a complete archive list to be or if Previous/Next links would be suffice.

E:

800px -> 44em, see response below.

That keeps things easy to read for users that want to override the font sizes. 40-60 is a good range.

For those who don't yet know why this is a big deal, I made a Codepen to illustrate why: http://codepen.io/anon/pen/eZwxam

Change the font size from 18px to 12px and then to 24px to simulate users with varying default font sizes set in their browser. Note how the containers change. While it will vary from person to person, a fixed 800px width of a container with 12px font size is far too wide for my taste and far too narrow for 24px. While I find 44em is better for both.

Note: I do not suggest ever changing the font size of body but it makes the example easy to use.

Choose expert.

Instead of large stylesheets with tons of highly-specific selectors, and quite a few broken and unused rules, web components will be able to use small stylesheets with simple selectors that only apply to their local scope, and developers will be able to reason about and maintain styles that are limited to a single web component.

If you only send the styles necessary for the page they're looking at then you lose all the benefits of caching. That's a far bigger problem than sending a bunch of unused code.

Thanks for the feedback and it has been insane. 3 big sites have accepted the challenge to purge their css. Css is just a small part of the bigger picture. Lots more topics to discuss, but i just focus on CSS.

I've dealt with a large site working with 4 developers. I have failed a adapting a big site to be lean on their CSS, hence looking at different ways of doing your styling.

I thought I was just making a website here: you know HTML, CSS, and a dash of Javascript.

...Guess not.

[1] http://csswizardry.com/2012/05/keep-your-css-selectors-short... [2] https://benfrain.com/css-performance-revisited-selectors-blo... [3] http://getbem.com/

It's basically replicating the html nesting.

As to your questions, well, I'd like you to consider my words in the context of the distinction between discussion, debate, and dispute.

I believe I already adequately addressed what the "problem with that" was, but I'll reiterate it more clearly.

Smudge was telling a story about a solution that he applied to a problem he was facing at one time, what the benefits and drawbacks of it were, and how it eventually led him to have respect for the value of React. He was sharing history. It was interesting. It would be interesting to discuss it if one had questions about the technical aspects of the thing he had done in the past, which he had shared with the audience in this forum, or rejected a similar solution at that time for reason one cared to describe.

Smudge was not introducing or participating in a debate. He did not state a proposal. He did not invite a counter-proposal. He did not advocate anything. There is no debating that he did this thing. There is no debating that he did it for the reasons that he described. There is no debating that he came to the conclusions as a consequence of this experience that he shared with us. The statements that you have made seem to show a pattern of inattention to what is actually being said. You are not debating with anyone. Smudge did not intend to invite a debate, and he should not have had any reason to think differently. Instead, your behaviour is obnoxious, self-involved, and anti-social, because it would tend to discourage people who did not want to engage in debates with you from sharing history with the audience of the forum.

What you were pursuing changed from debate to dispute. Firstly, rather than rebut points that had been made in the context in which they arose, you pursued disagreement beyond the bounds of the actual context of the matter under discussion. To give an example, whether or not "browsers are very smart these days" is not material to a discussion of how one developer implemented ajax updates with graceful degradation once upon a time when browsers were not very smart. You were not debating with Smudge, most basically because Smudge did not want or try to have a debate with you. You were not debating with Smudge because your statements were of little value in the context of what the topic of a debate would have been --- which would be something akin to 'decisions web developers made when faced with web developer problems [once upon a time]' --- and, by themselves, suggested that you were actually unfamiliar with this topic. Your words suggested a desire to turn a discussion into a dispute about a topic that Smudge was not discussing, and which was so tangentially related to the actual topic at hand that I would have found your need to dump your opinions upon this person as argumentation offensive even had you not stretched them to the ridiculous conclusion that front-end web development was a rent-seeking activity.

To add the final part to what I had said before: behaving like this will discourage people from sharing their opinions and experiences. Just because someone said something, it does not mean that they or anyone else cares that you have opinions about a related topic or that that person is inviting you to criticize them. Wait until the lines of an actual debate have actually formed before you attempt to engage in a debate with someone, and never, never crash someone's thread in order to insist that they must debate you regarding a topic you yourself have brought to the table.

Extending the reply to your last statements: firstly, no, Smudge did not propose a way to do something. You misread what he wrote. My apologies for the bewilderment that my response must cause you if you genuinely, rather than wilfully, misread what he wrote. However, he did not invite a debate, and your behaviour was not appropriate. If you thought that it was, it would serve you well to learn why it was not. Secondly, you did not 'refute' what he said. Your statements bore no relation to a refutation. "Everyone should use the latest web browser" is no more a solution to a problem than "Everyone should eat cake". Telling a person that they should use the 'default widgets' rather than write a very thin javascript library because you don't like too much javascript is confusing. What 'default widgets'? What do you mean by that... jQuery widgets? HTML does not come with 'default widgets'. Yes a lot of websites are clogged with useless shit, and yes you have a perfect right to not like this. But you can't 'refute' the decisions that a web developer makes "from the other side of the wire", and this is true of anything else or any other similar situation. You can't 'refute' a judicial decision on the basis of your own interpretation of written law. You have to learn about actual law first. You have to come to his side of the wire first. You could certainly refute mis-statement of fact, if you knew it to be incorrect, but you cannot refute a decision without understanding the context in which it was made.