What is so bad about JS that you just can't use the web with it enabled? Grow up.
The web is a platform that is evolving far beyond its original intent. In a few years its going to be a binary delivery platform. And that's great news. The idea that the web needs to stay the way it was designed in the 90s is what's really regressive.
Here's what matters about the web:
- Linking
- Standards for Web APIs
- Content delivery protocols
Everything else - as far as I'm concerned - is a transient feature which will eventually be superseded.
The mentality that nothing should change about the web is incomprehensible to me. I just don't get it.
Edit: Inevitably, someone will tell me that the web is faster without JS, and another might claim accessibility as a problem.
- A faster web is made possible by faster devices on faster networks. Current constraints are far less relevant when we're discussing future technology. For now, yes page size is a problem but I absolutely wouldn't want that to shape future technology. ISPs have the power to improve their services as required.
- Accessibility is a standards problem, not a content type problem. Accessibility software should be expected to adapt to new technology like anything else. As long as we provide the tools for these platforms to succeed, the type of content that is being served (whether it's plain text, JS, or binary) shouldn't affect anything.
From the perspective of a web developer or publisher, they of course want as much power as possible. But this is really a tradeoff, directly taking away power from end users - the accessibility you handwaved away, as well as things like adblocking, user-styling, caching, and every other unenumerable concern of endpoints.
I'm not saying that a delivery system for opaque executable blobs isn't the inevitable fate of the web, just that this shouldn't be viewed as progress but rather decay.
You are speaking of things that can and should be addressed with APIs provided by the browser.
Why do you think Google created AMP (which is just a fancy way of telling devs to stop using JS for text sites)?
Look, there are plenty of site for which JS makes a huge difference - proper web applications. For every one of those site there are 9 that load half a MB of cruft so they can animate their stupid banner.
It's not that nothing should change, it's that change should make things better. I firmly believe pages made better by javascript are such a small minority as to be an rare exception, but overall the web is so much better with that 'feature' disabled.
I don't understand your reasoning; I don't have any HDMI equipment (except my RaspberryPis, which are headless servers anyway), so I certainly would avoid anything that's HDMI-only.
Just because you, at the moment, only use the Web for a few pre-approved purposes (e.g. viewing rendered pages) via the handful of user agents which support Javascript, on operating systems supported by those user agents, on hardware supported by those operating systems, which is powerful enough to run it all, that doesn't mean everyone else is. Some are less fortunate, as they have older, or less-powerful equipment. Some are more fortunate, as they are using the Web in more imaginative and novel ways than you are.
Web pages can be rendered any which way you please, it's no skin off a developer's back if you don't have JS enabled for their JS project.
- Hideous wastefulness of resources, causing constant unnecessary repaints, enormous RAM usage, etc
- “Experiencejacking”: things like scroll hijacking, back button hijacking, etc
- All the privacy invasions that JS enables
These wouldn’t be issues if sites suffering from them were the minority, but they’re not. Most sites have mountains of poorly optimized JavaScript that gives zero thought to performance or resource consumption. Once it works, it’s shipped.
The fact is that front end web dev culture as a whole places very little value in things like performance, battery life, resources, and ultimately, respect of the end user’s desires, and that’s a huge problem. As long as the whizz-bang shiny flashy checkboxes are checked, it’s all good.
To borrow your comparison, people who are bothered by what I describe above see it like a website saying, "Hey, we won't work on your device unless it's HDMI because of the design choices we made!"
I never write JS > ECMAScript 5. Why? Because I want my apps to work in as many places as possible and I don't feel like arrow functions are worth breaking backwards compatibility. I know there are those who will disagree. I'm all for pushing the web forward, but I feel like, in the process, some of us have lost sight of what the web is ultimately about.
That's a bold statement. Why EcmaScript 5 and not JavaScript 1.4 for that matter?
Programming languages change and evolve. EcmaScript 6 introduces a lot of features, including some that greatly improve the readability, maintainability, and cleanliness of the code. Sure, right now you may need to hold back on some features if supporting legacy Internet Explorer versions is your goal and you don't use a preprocessor such as BabelJs, but at some point the only browsers that don't support ES6 will be browsers that are unsupported by their vendors and inherently unsafe; so why stick with ES5 in particular? Or are you simply waiting for the moment all current browsers support ES6?
I get not wanting to use bleeding edge features supported only in the latest developer edition of Chrome or Firefox, but at some point ES6 is supported in 100% of the browsers people can safely use, and a few years after that ES7, and so on.
Because most devices will run most of ES5, very few devices will run any ES6.
Now there are transpilers sure, but I remember a time Javascript was about simplicity and not relying on a complex grunt pipeline + Babel. Now JS tooling is more complicated than Java's only with JSON in place of XML. The irony.
I too find that the easiest to implement features are (not terribly surprisingly!) the least interesting; they are not worth the terrible friction that I'd see in my current organization. I have a hard enough time trying to get folks to write good test coverage and understand the gotchas of writing async code everywhere. So for me, there's way bigger fish to fry than (exaggerating a bit here) saving a few characters with arrow functions.
But that's still not to say I won't ever use it.
The web is not about 'engaging web applications'; the web is about webs of interlinked documents. Every time you require JavaScript to display a simple document; every time you load images with JavaScript instead of <img>; every time you replace an <a href=> link with a JavaScript event handler; every time you fail to even link to a page; every time you use JavaScript-loaded fonts to display symbols: you break the web.
'Web application' is a misnomer: it should be 'browser application.' Despite my loathing for documents (e.g. blogs, articles &c.) which require code execution in order to be read, I don't mind browser apps where they make sense. Google Maps makes sense: it doesn't bother me that it doesn't work in eww, or links, or with NoScript.
Blogger doesn't make sense: there's absolutely no legitimate reason for it to show an empty page with JavaScript turned off: Blogger is breaking the web. imgurl's failure to show all images, and Cracked's failure to show any images, without JavaScript makes no sense: they are breaking the web.
People who break the web should be deeply ashamed.
You feel wrong. I enable it when I have to, only.
> How can you build engaging web applications
Not my problem. I want quick loading sites with as few malware vectors as possible.
You should be building web applications which facilitate the transfer of information. You don't need javascript and all the other crap people are using these days for that. I mean, if you're all about pure eye candy and doing..I dunno, mandelbrots or something in the browser, then yeah, you're going to need javascript. But it's not going to work on mobile. Hardly anything like that works on mobile, which is fine by me; I do most of my browsing there.
To be honest, I think there's a market for a firefox addon which removes links to sites which don't work on mobile/require you to have javascript enabled to save me the effort of clicking back when i arrive at am empty page or when the screen is dimmed and all I can see is the corner of some dialog I have no interest in zooming out to look at.
I think it skews the conversation to talk about JS being "turned off", rather than unavailable, as it assumes that every user agent (browsers, screen readers, crawlers, CLI commands, etc.), even those cobbled together 5 minutes ago to do one quick job, is capable of running JS, has a DOM, is up to date, implements various APIs, that those APIs even make sense (what's the screen resolution of wget running in an SSH session?); and that the user has manually told it not to.
You can, but you an't force the user to interact with your 'web application' in the way you prefer. But you could never rely on the user's browser settings being optimal for the experience you wanted to provide anyway.
If you want absolute control over what the user sees and doesn't see, then build a native app. The price you pay for the ubiquity and convenience of web applications is putting control over the interface in the hands of browser vendors and end users.
What do you do for accessibility? Screen readers etc?
Because you started too early during the web's rise, and are now too old for that...
>Because I want my apps to work in as many places as possible and I don't feel like arrow functions are worth breaking backwards compatibility.
They are not, since everybody uses them with Babel.
ES6 has some nice features -- all other things being equal I'd chose to write it over ES5. Or even ES3, since it fits with that sloppy ageist accusation you tossed off.
As soon as you say "Babel" (or another transpiler), though, all other things are not equal. I've already chosen to work with ES6 anyway in some circumstances, but honestly, when it comes down to it, the benefits are marginal enough over ES5 that there's a reasonable case that anyone already effective with ES5 doesn't need to transition.
And I might even go so far as to speculate that a programmer who is unable to be effective with ES5 might simply be the kind of programmer who can't really be effective whether they'd be working with Python, Ruby, Go, C#, whatever... but that would probably be tenuous bullshit on par with assuming anybody who doesn't want to add a transpiler to their toolchain in order to do essentially the same things they can do without it is Just Too Old.
Now, that's not as transparent to grok or as high resolution as something like the date and title path schema that's become popular, but it's still something that some users will recognize and possibly even know how to get some utility out of -- if nothing else, by copying the URL and pasting it somewhere for sharing or use or storage.
And that's the worst case scenario for URL utility. If we get into a recognizable scheme like the date-title path, there's a lot more apparent information and it can often be transparent how changing the URL can be an interface.
We've had an interface that allows users who don't grok URLs to ignore them OR learn by observation and experimentation how they work -- and allows users who are already there to easily note and access them for two decades.
This trend towards leaving them out doesn't allow that progression or utility.
Search has no understanding of Progressive Web Apps to my knowledge. Performance, Mobileness (on mobile search) and TLS are all ranking factors of some sort.
The thought at the time of the change wrt to the fullscreen or standalone is that to get that app like treatment in the OS you would expect it to launch as an app would on the system (sans-url bar).
Note: we are also thinking of ways to get the URL bar back to the user when it is launched standalone or in fullscreen. It's a complex UX problem but we want to get the best of both worlds.
As surely as Water will wet us, as surely as Fire will burn,
the gods of the HTTP Headers, with terror and slaughter return.
I expect that for a lot of apps-that-really-should-be-websites their owners will realize that having to (pay to) maintain both their Android and IOS apps, and the 'normal' website is a costly affair, and that maintaining one responsive website is a lot more efficient.
> The end result may feel very “app-like” if you’re using an approved browser, but throwing the users of other web browsers under the bus is the very antithesis of what makes the web great.
1. The Polymer demo app is a _demo_ app - it's a tech preview, not a recommendation to drop support for any other way of delivering web content. 2. Who decided "what makes the web great"? One of the things that makes the web great is that people can build powerful app-like experiences using standardized tools. Some browsers don't (yet) support those standards, and some users opt-out of allowing these standard tools to run (Javascript), but that's not the fault of the web, is it? Is the argument that the lowest common denominator must be served before spending any time and effort on making something more advanced? Count me 'regressive', then.
> The inability to pinch-zoom in native apps is a bug
I disagree with this assertion, although I acknowledge that it does have accessibility costs. It's at best naive and at worst disingenuous to claim that disabling pinch-zoom on the web is "slavishly copy[ing] whatever native is doing" - rather, some web apps are choosing to make similar tradeoffs as native apps.
> To declare that _all_ users of _all_ websites will be confused by seeing a URL is so presumptuous and arrogant that it beggars belief.
This is laughably hyperbolic. The linked Chrome issue simply disables an automatic prompt on websites that are configured in a very specific way - it isn't making a universal statement about URLs or whether or not they confuse users. To declare that the Chrome issue does otherwise is so presumptuous and arrogant that it beggars belief.
The final complaint that Lighthouse (a Google application) has a different standard for "best practices" than the author doesn't actually help his argument. Lighthouse isn't _the_ reference point, it's _a_ reference point, and one thing that web developers learn very early in their careers is that when it comes to the web, there is no one right way of doing anything.
The App Shell model has worked well for a first set of experiences that have shipped and I don't think that it is inherently mobile only, many sites work well on desktop, instead I think I think a lot of it is a matter of resourcing and staffing. After working with a number of developers who are building Progressive Web Apps, one thing that I have noticed is that many of the teams building sites are still split between a "mobile web team" and a "desktop web team" and that is one of the reasons why I think we are seeing some of the sites being accessible on mobile first.
The place we want to get to is one experience that works well for all users in all browsers.
Specifically wrt to Banner prompting our thoughts around this have always been consistent, when an site meets the criteria of something that could be experienced as an app the user would see a prompt to "install" it (after meeting some engagement criteria). The thought was that prompting is a powerful feature and one we don't want to see abused and thus the criteria is quite strict and our expectation is that the site when launched should launch like an app would on the system. The user can still add to homescreen, we just reserved the prompt.
Some interesting bugs for people to follow wrt to Propmting.
* https://bugs.chromium.org/p/chromium/issues/list?q=component... - prompting and add to homescreen bugs
* https://bugs.chromium.org/p/chromium/issues/detail?id=604390 - Minimal UI mode for access to URL
* https://bugs.chromium.org/p/chromium/issues/detail?id=601624 - Discussion on criteria for prompting
* https://bugs.chromium.org/p/chromium/issues/detail?id=601337 - Mandating Offline to get banner.
Or you can make your blog, which is essentially text on a webpage, that is rendered entirely by javascript. You can have your css download as javascript and be processed and rendered by the browser ... but why? Because they're new toys?
I think our infatuation with javascript has led us to the "when you have a hammer everything looks like a nail" situation.
Javascript is great but most developers I interact with aren't writing javascript. They're writing jQuery or Ember or Angular. They don't understand javascript as a language, they understand the flavor of javascript their library of choice gives them. They don't think about the fact that sorting a table in a browser will be a problem until it hits production, with 10,000 rows, and users without the top-of-the-line hardware are screaming.
It reminds me of the Windows vs Mac debate, which is really just a debate over control. Windows didn't control the hardware it was installed on; MS couldn't be sure everything would work so there were layers upon layers of compatibility solutions. Apple controls (most) of it's hardware so it has a smaller playing field and it knows what the next commit to it's repo will do to the majority of it's users' experiences.
Javascript is the same way. As web developers, you (should) know what your servers can do. You can plan for capacity. Offloading everything to the users' browsers is just evil. Think about the kid with his $200 hand-me-down chromebook who really wants to learn about programming or the guy in Africa trying to visit your site over GPRS on his mobile phone. They shouldn't need the newest version of chrome with ES6 to view a blog entry.
There are times where a SAP is the right choice for the user. We just have to realize everything isn't a nail.
[edit: english]
