I know at least one user who is asking this same question. He does not believe it is needed.
Is it possible that "what users want" and what developers want may be two different things? Could developers have wants that are unique to developers?
Purely anecdotal but I do not know any fellow users who "want javascript". I know many who do not want a number of common annoyances though. And I know these hassles are in many cases enabled via javascript.
The tactic leveraged against users is to tell them they need javascript for some thing to work. Then users want it. But I think really they just want the thing to work. They have no particular affection for javascript, let alone any knowledge of why they need it.
One thing I have observed over the years the web has existed early 1990's to today is that users can adapt to anything. Whether it was learning keyboard shortcuts on the console and using text-only programs like Pine, or running www searches that took minutes to finish, or communicating with 140 characters or less, or working with tiny touchscreens and horribly slow web pages and mobile apps. Many more examples if I gave it some more thought. From what I have seen, users accept what they are given and find a way to make it work.
Don't throw the baby out with the bathwater. It is the responsibility of devs to use technology well. You don't want all of this JS, but you do want some of it.
Too many people are making their assumptions about what is possible and what JS is capable of based upon views of web development that are 5-10 years out of date or based on bad software. Bad software is endemic to the industry, it's not representative of any single tech stack.
5 years ago was 2013, there were some pretty great things going on in the web in 2013. Don't lose sight of lessons learned by previous work either. A new shiny framework doesn't automatically make it better practice.
While we are reinventing the wheel in client side JS we should make sure to remember that it has probably been done before, software has been around for decades, the web as well, and to think the best of it has only just happened in the last five years is a bit misguided.
Suddenly, the site becomes solid, lightweight, and supports everyone. That's what I think people used to call "progressive enhancement".
If it's forms. Client calls server with base hash + changes made by client and server replies with. Base hash + new diff to apply. The new diff includes validation changes.
It's trees and diffs all the way down.
Bundle React with Chrome? Or how about a browser package manager that could cache and reuse all these common js libraries used on so many sites?
Still, validating a form client-side doesn't require a JavaScript framework; it would only require the server to send small snippets of JS for each field with the form.
"Then you would have to maintain two code pathways in two different languages in two different locations if you need to update the validation rules."
Not necessarily. You can use the same exact code, in the same location written in the same language.
My main point is just that the implication that JS is required otherwise the UX will be unbearable is false. It's also really easy to mess up the UX with JS and I see it constantly. I would take a fast form post over a cumbersome JS powered experience any day.
You can render server-side, then switch it to an ajax post in javascript. On submit, post the form back in ajax (a simple `.serialize()`) and if there's a validation error in the form, return the HTML form back in the response with the validation errors and replace it in the DOM.
Virtually instant feedback, no page reload, no 30 second initial SPA load.
In ASP.Net MVC, for example, this is as trivial as changing the `Layout` property of the page in the controller, the full layout for GETs, no layout in POSTs.
Technically you don't even have to support progressive enhancement, but it's so trivial in most frameworks you may as well.
I believe Rails has a built in turbo feature which essentially does this and more.
Example ts code, though usually put more in to disable double clicks and add a loading spinner:
onSubmit = (e: JQueryEventObject) => {
e.preventDefault();
let $form = $(e.currentTarget);
$.ajax({
type: $form.attr("method"),
url: $form.attr("action"),
data: $form.serialize()
})
.done(() => {
//do something
})
.fail((e) => {
if (e.status == 400) {
$(".js-form-wrapper").html(e.responseText);
this.wireUpControls();
} else {
//handle error
}
})
}
$("#your-form").submit(this.onSubmit);Well, it used to be that submitting a form and rendering errors on the server took the same ~100ms that evaluating a javascript framework validation does now, and so it was... not a problem.
If you mean "leaving aside the most trivial html stuff" to include things like html5 inputs, that's the most significant part of what Javascript provides in form validation.
If you exaggerate the numbers, you can't make any useful comparisons.
We can now keep the user's state and inform them of errors in a way that is more difficult with server-ride rendering.
Of course the form gets returned from server validation will all user input prefilled? At least with Django that's the default behaviour.
There seems to be a sizable portion of this, and far from limited to the web world.
That said, some of it may also come from the managerial level. This thanks to cargo culting akin to the offshoring fever a decade or two back.
meaning that management is pushing for something to be done in a certain way because they read about some big name corp doing the same, and wanting the company to appear "aggressive" to investors...
(Not to mention user frustration. Mainstream webdev doesn't give a damn about that either.)
Framing it as end users "do/don't want javascript" isn't helpful for analyzing the advantages/disadvantages of javascript. Obviously, end users don't think of it that way.
We could also say that we don't know any users who "want polycarbonate on their face". That's true, but they do want clear 20/20 vision and we just happen to use polycarbonate as the material that combines the attributes of light weight and inexpensive manufacturing compared to glass.
Nobody wants to "ingest fungus poop" either. Except they do because that's what beer is.
Users also don't want a "30 minute barrage of explosions 5 feet from their body", but they do indirectly want that because they would rather drive a car to the store instead of walk. (Some might extract the wrong idea from that example and insist that we shouldn't be dependent on fossil fuels anyway. Well, people also don't want "volatile chemicals" either which is what lithium batteries are. They also don't want a steel tube shoved up their butt which is what bicycles are.)
(To get back closer to the tech world, end users also didn't ask for "HTML" or "want CSS" or "HTTP" either. They don't think in those terms.)
You're right that they don't want "javascript" per se. What they want is a "fluid experience" in the UI. We happen to use javascript to provide that fluidity.
>I know many who do not want a number of common annoyances though. And I know these hassles are in many cases enabled via javascript.
True. But it ignores the benefits to users that javascript enables. Things like airplanes also bring hassles such as noise but that ignores the fact that people wouldn't want to give up flying because planes also enable convenience.
Therefore, people do want javascript -- indirectly. They want autocomplete in amazon and netflix search fields. They want smooth map repositioning in Google Maps without page reloads. They want up/down voting buttons and expand/collapse outlines to work in stackoverflow, reddit, HN without jarring page reloads. Many pages in wikipedia also work better with javascript.
Yes, the abuses and misuses of javascript that hijacks scrolling or javascript that breaks apart a single page article across 20 screens with tracking and ads are annoyances we don't want. However, it shouldn't keep us from having a balanced discussion that includes how javascript improves the web experience for the average user. The uncompromising insistence on avoiding of client-side javascript in favor of server-side page regeneration&reload is hostile to the user. Many web users do not browse from desktops with fast fiber optic connections. They browse from mobile phones with ~500+ round-trip latency.[1]
Like most of you, I'm a "power user" so I should be a prime example of an uber geek who "doesn't need javascript". And yet, I use regex101.com every week that relies on javascript. It would be a total hassle if I had to press "submit" everytime I changed a character to experiment with regexes.
As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away.
As a user I’m willing to pay a few more seconds upfront for snappy and seamless interactions as I use the app.
I think the mistake that is more often committed (and where I myself as a user have less patience) is treating everything that can be accessed via URL as an “app”. If the user is coming to just download bytes, don’t build an app. An app is only justified when a user is coming to manipulate data.
I'm quite sure this is a sign of poor development, regardless of the form being validated on the server or the client. There is no reason for the server not to send back a fully pre-populated form.
Some web forms get around this by just sending back the lengths of the individual fields so they can be masked when the form is repopulated, but that's less common and is something that doesn't occur to lots of developers (store the length, but don't send the whole string). Instead, it's easier to follow the mantra of "never store the passwords in plaintext, never send them over the wire in plaintext". Which is why most web forms clear out the sensitive fields when repopulated via the server.
TL;DR it is much, much less secure to do this.
What are you talking about? Who said anything about plaintext? And no one said anything about sessions either.
If you're submitting to the server in plaintext, then returning in plaintext is no less secure, but you're stupid for not submitting over https which is free.
If you're submitting to the server over https then it's definitely no less secure to return the data.
I don't see the security hole in this situation, you do realise that regardless of the obfuscation you see in your password input fields, which by the way only protects from over-the-shoulder peeking, you are willingly sending data to the server and it will end up there unencrypted anyway. Otherwise there wouldn't be possible to do any operation at all.
Can you give me an example where POST-ing a form would be secure but responding with the data adds another attack vector? They're both protected by the same "layer" of security, isn't it? How is one more vulnerable than the other?
The password itself never leaves the client, and never hits the network.
Store last 4 digits of cc and mastercard vs visa to provide the "is this the correct card?" form
I'm really curious about how you see this working, I can't understand how you can forever obfuscate your CC info. I assume at some point the server needs your plain data.
To the payment processor, they'll always have the cc/cvv info, or rather, the hash of it, to verify with. If they don't have it, then I imagine the user doesn't have a valid cc. (How can you have a VISA cc that visa doesn't know about? If its a valid cc, eventually we have to hit someone who knows it...)
For creation of the CC, its entirely done offline atm isn't it? And since its basically just a shared secret, you could do the whole diffie helman physically.. but anyways
So then on your side, as some kind of store, it should be the same as passwords. The payment processor tells you the hash function to use, and you use it client side, and the processor verifies.
Alternatively, you send the user to the someone else (ie redirect to paypal), who does the same thing.
It doesn't seem at all necessary to me that your cc/cvv actually leaves your machine in plaintext. Of course, they may be sending plaintext for some reason, but I don't see an obvious reason why they should
But for more nuanced software, responsive and rich ui is very important to user uptake.
Examples: Gmail, Facebook, Maps, Slack, SoundCloud, every autocomplete search box everywhere.
If you accept that parts of the page should be interactive then you need to consider the benefit of an isomorphic approach to eliminate code duplication. Usually it's not just a single interactive component.
The problem is JS frameworks make development easier but have high real world costs that are often ignored.
Now take 10 developers to reuse that autocomplete in the same project in 10 different places. I bet those carefully crafted lines become 100 little monsters, one without eye other with 3 legs.
Not that they have to be stupid, it is just they think differently.
But it takes actual thinking - and care - to do that. Something that seems to be in short supply with the current web trends.
Imagine a world without AJAX. This is obviously an opinion, but it would be super annoying if every button I clicked sent a raw POST to the server and refreshed the page.
Do news sites need to be rendered client-side with React + Redux + React Router + all the Babel polyfill garbage? No, I don’t think they do.
But some sites are definitely better in my mind for being SPAs.
The problem is that people pick technology that they like or are familiar with instead of working backwards from the ideal user experience. What we should be doing is picking the minimal set of technology that achieves the UX goals of a project. Instead, you have people loading 200kB of dependencies to render pages with a level of interactivity that could be achieved with 30 lines of vanilla JS. Oh, and then Google, FB, Twitter, and Optimizely tracking scripts.
This is my favorite HN quote of the month.
They even still offer that interface - check it out. It works remarkably well (and quickly) to this day.
The tangible benefits when done right (there's lots of crappy code in every language and system) are greatly reduced user-perceived latency (the system reacts immediately, indicating that something is currently being updated, etc).
I haven't got any information to support it, but I suspect it was mostly cargo culting from big vendors with big platforms that has made JS Single Page App style sites seem ubiquitous, because everyone in the spotlight is talking about the cool stuff they are doing with it. But in reality they still make up a minority of the web.
This perhaps roots in the behaviour of browsers ten and more years past. Back in the day, you'd often get a "flash of white" during page loads. Today, not any more. A full-reload and a "seven million lines of JS client-side renderer" application are virtually indistinguishable. Chances are that the "full-reload" app is faster.
Over time 2) has been increasigly shoe-horned into limitations of 1) and its all a giant cluster fuck now. Leave HTML to linked documents and give us an efficient runtime that we can plug into to deliver desktop class apps written in whatever language we want that works with a standardized runtime and UI language shipped built-in with every browser.
Why the hell cant we build web UIs With a standardized UI markup (not HTML), wire it with whatever lanaguage our company uses, and compile it down to WebAssembly and ship it to clients browsers? Instead we have to write these monstrosities in shitty JavaScript with virtual doms, and hacks everywhere. Madness!
We can, but probably not now, because WebAssembly isn't quite ready yet. It still lacks garbage collection and efficient DOM access, and the specs aren't even finalized. There are already experimental targets for a few languages like Rust[0] and Lua[1], and WASM targets C/C++ out of the box.
Eventually, you'll probably be able to import arbitrary languages and environments with a few HTML tags, similar to Javascript today, or whatever the Webassembly version of a package/dependency/VM manager turns out to be, then compile and run any application ever made in the browser.
If only there was a way to collectively punish this type of behavior.
people want (in desktop replacement spa's where they spend hours and hours): app-appropriate usages of keyboard nav; background tasks with status windows, working back buttons that don't stop the music stream; links that work like links & app-clickables that work like buttons; refresh buttons that refresh (via a page reload) their current full state, but working.
"Can we add discussions to this page?" "Great! Now, can they be live-updating?" "Great! Now, can we have a nice little notification counter?" "Great! Now can it be collaboratively edited?"
Eventually, the front end becomes a monstrosity.
When starting out, if you just plan for a complex front end, and choose a well-structured framework, your life as a developer will be much less painful. Yes. It's overkill for a blog. But who among us is really building a simple blog? We're building applications that happen to run in the browser.
[0] https://hackernoon.com/why-does-this-site-require-javascript...
The answer to this question is always no.
The TL;DR is, the classic web development model still works amazingly well today and you can get real-time aspects by sprinkling in Javascript where needed.
Appier sites, like video, music, games, maps, etc are gonna need a lot more client-side logic to be pleasant to use.
But the thing to consider is - a lot of things can be pre-rendered and cached. Your server can render it once and serve to many clients. With client-side rendering, each client is rendering the same thing for themselves, possibly slower than on your server because JS is not exactly the sharpest tool in the shed. So you've saved yourself $N in compute but externalized $N * number of users * relative JS inefficiency. This is not a nice thing to do.
Even so, you can have that experience with server-side rendering and simpler client-side updating.
I know we switched because front end experts told us that users found the full refreshes annoying. They said that users really wanted native desktop like seamless change pages. Never did I see proof of these claimed. Is the modern JS based design our cubicle moment? Did we get suckered in by experts making productivity claims with nothing to back them up?