15 ms·

Regressive Web Apps

107 points by thekingshorses 10y ago

alistproducer2 10y ago
I'm a JS evangelist for sure. I love the language, but I'm not a true believer. Believe it or not, I keep JS turn off on my mobile browser because I enjoy instant page loads. I remember the first time a coworker asked me "but what if they have JS turned off?" I thought "what a dinosaur. Who doesn't have JS turned on?" Obviously I had a change of heart on the subject. 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.
- supster 10y ago
  I feel like JS is an expected part of the web just like HTML and CSS. How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)?
  - krapp 10y ago
    >How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)? 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.
  - zeveb 10y ago
    > I feel like JS is an expected part of the web just like HTML and CSS. How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)? 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.
    - agmcleod 10y ago
      I agree you're getting the most accessibility by making a blog that renders on the server. But rendering front ends with javascript shouldn't be considered breaking the web. It's a tool that's available in the browser, and many use it to try and make a better experience for their overall users. I think it's a shame we have the "first load no content" problem, but developers are doing this with good intentions. Making UIs respond faster, reducing back & forth network requests, and trying to make more interactive content on the web. There are some warts we need to sort out and get better at, but I still see it as progress.
      - zeveb 10y ago
        > But rendering front ends with javascript shouldn't be considered breaking the web. If it doesn't work without JavaScript, it's breaking the web. I have absolutely no problem with progressive enhancement. I have absolutely no problem with choosing to enable JavaScript when it makes sense. I have a problem with requiring a privacy-destroying technology in order to consume content.
      - pdkl95 10y ago
        > rendering front ends with javascript shouldn't be considered breaking the web. If you want to serve an empty, broken page as a first impression, you can. I strongly recommend against it because it makes your site look half-finished, poorly designed, and generally unprofessional. > available in the browser That isn't always true. You don't know anything about the browser a priori. > make a better experience Of course. Javascript can add nice features, which is why you progressively enhance the page to add features when the underlying requirements are available. Do you skip the check for NULL when calling fopen(1)? Checking for errors is always important. On the web, this means you should gracefully handle problems like missing javascript (intentionally or otherwise) or other resources. > Making UIs respond faster Requiring two additional HTTP requests (one to load javascript, and another to load the actual page content) isn't making the page faster. After the first request your javascript will be available most of the time for partial loads in any case. > interactive content That is rarely a good idea, but it's your page so do what you want. Progressive enhancement doesn't affect this at all.
  - frontendthing 10y ago
    your feelings are not of interest here. If you want to create web apps on a professional level, you have to provide no-js fallback that works everywhere, that is the technical standard. Nobody is interested in how many hours you spend weekly to grow your beard.
  - dave2000 10y ago
    > I feel like JS is an expected part of the web 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.
    - Klathmon 10y ago
      A few months ago I wrote a web-app that lets you pick an image off your computer, and convert it to a cross-stitch pattern. I did it using javascript entirely client side, so it works offline, it's secure (as it doesn't send the images anywhere), and it is fast to load (letting you change settings and get the new cross-stitch in the blink of an eye). With your idea of doing things, i would need to pay for a server (and would probably need to then charge my users who wouldn't pay, so it's now DOA), it would be significantly slower, it would be less secure/private, and wouldn't be able to do things like auto-change the size of the resulting image depending on the screen size of the browser (important for mobile! don't want to overload the browser with massive images). That needs javascript, and for you and others to keep acting like anything that uses javascript is a toy that shouldn't exist is arrogant and wrong.
      - mixedCase 10y ago
        You should be shipping that as a browser extension. As it stands it's not good as a website, but it meets every criteria for a good extension. It's even the kind of thing that passes for a native application in Chrome OS.
  - Twirrim 10y ago
    > How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)? What do you do for accessibility? Screen readers etc?
  - chriswarbo 10y ago
    > How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)? 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.
- Freak_NL 10y ago
  > I never write JS > ECMAScript 5. Why? 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.
  - profeta 10y ago
    you are probably too young to remember the time when using <script type="javascript1.2"> was bold and bleeding edge. (probably got the syntax wrong, because, well, that what happens to memory when you are not too young)
  - spriggan3 10y ago
    > That's a bold statement. Why EcmaScript 5 and not JavaScript 1.4 for that matter? 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.
    - lucasmullens 10y ago
      I think for most people the time you save using ES6 features is more than the time it takes to set up a build system, at least for larger projects.
      - alistproducer2 10y ago
- coldtea 10y ago
  >I never write JS > ECMAScript 5. Why? 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.
  - wwweston 10y ago
    > Because you started too early during the web's rise, and are now too old for that... 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.
    - coldtea 10y ago
      The problem is not with the individual programmer. One can make wonders with Commodore assembly too. Of course they can do stuff in plain JS. But they'd be reimplementing the wheel a lot. If you want to take advantage of the JS ecosystem as it stands in 2016, you need to use its tools. E.g. just consider using React with JSX -- you already need a transpiler for that.
  - alistproducer2 10y ago
    Yeah not really. I've probably written more complex JS code in the last 2 years than you'll ever write in your life so save the "too old" stuff for someone else. When your writing a recursive decent compiler from scratch, you don't really feel like debugging whatever errors some transpiler injects into your code. You'd rather it just work the first time and be sure it works everywhere. Check my github before you start mouthing off..... https://github.com/ShamariFeaster/Templar https://github.com/ShamariFeaster/Templar
carsongross 10y ago
Eventually the pendulum will swing back. The web app model beat out native apps (then called client-server apps) for very good reasons (no install, REST-fulness, simplicity, transparent linkability) but we've become blind to them through long exposure. As surely as Water will wet us, as surely as Fire will burn, the gods of the HTTP Headers, with terror and slaughter return.
- Freak_NL 10y ago
  Amen I guess? 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.
jakub_g 10y ago
I always say that URLs are the best invention since electricity and cars. Just a few bytes of text but convey so much information, and are universally supported by virtually all software. This is huge. Don't take it away from the people.
- CognitiveLens 10y ago
  URLs are not going away - like you point out, they are a reasonably good way for software to pass around a few bytes describing a resource location. Their usefulness for humans, particularly within a single site/web app, is less clear - e.g. if we ignore the domain name (which would be constant across a web app), this comment thread is described by 'item?id=11770774' - it doesn't mean anything, and so arguably is not worth displaying anywhere within the HN 'app'.
  - matt_kantor 10y ago
    HN has subpar URLs (in terms of UX), but they're still very useful. I can copy the bytes "https://news.ycombinator.com/item?id=11770774" https://news.ycombinator.com/item?id=11770774" and use them to get back to this comment thread later from any device with a web browser. I can give these bytes to a friend to refer them to this thread. I can share these bytes publicly and have a reasonable expectation that they'll allow anyone to retrieve the content on this page (not forever, but the Internet Archive and other caches have your back if this URL breaks in the future).
    - open-source-ux 10y ago
      Making the HN URLs more human readable would also make them much longer. However, the longer URLs could provide a form of site structure if the URLs are 'editable' e.g. https://news.ycombinator.com/2016/05/25/regressive-web-apps Then, if you edit the URL, you can get all stories for today: https://news.ycombinator.com/2016/05/25/ All stories for the month (which would require pagination): https://news.ycombinator.com/2016/05/ And all stories for 2016: https://news.ycombinator.com/2016/ And finally, back to the home page https://news.ycombinator.com/ Note: all these pages don't have to be explictly linked or displayed on Hacker News, they might appear only when someone edits the URL in their browser. Edit: Just to add...here's a lengthy, but very detailed post by an ex-BBC employee about using URLs to model the complex data for BBC programmes Designing a URL structure for BBC programmes http://smethur.st/posts/176135860 http://smethur.st/posts/176135860
potch 10y ago
"Progressive Web Apps" is a Google brand. It's made of some good best practices and great technologies, but they reserve the right to re-define it and change the rewards around it however they choose. Install buttons are the carrot, and search rankings are the stick. Will non PWA-compliant but otherwise fast, well-made mobile web sites rank as highly as PWAs?
- lucasmullens 10y ago
  Google isn't trying to make every website a PWA. Why would they punish all non-PWAs?
  - kinlan 10y ago
    The current way that we see the banner is that it is the equivalent of an App install banner for web sites that meet the rough idea of what a Progressive Web App is and would be something that you would want to install or act like an installed app on the system. 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.
- kinlan 10y ago
  Just a minor nit, yes we have been working under the Progressive Web Apps headline for a while (I work on the devrel team) but it is a shared term that Opera and Mozilla are using. 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.
emodendroket 10y ago
You can't please everyone, I guess. Who but the largest organizations has the resources to make a fully-responsive SPA that also has non-JS fallbacks for everything?
iLoch 10y ago
I'm so tired of people using "it doesn't work without JavaScript!" as an argument. To me it sounds as relevant as saying "it doesn't work without HDMI!" 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.
- askldfhjkasfhd 10y ago
  The problem, as people see it, is there is a whole space of websites that use features they don't need. Think of all the 1pageapp content sites. 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!"
  - iLoch 10y ago
    The difference now is that most people are using browsers that will automatically update in order to work with new features.
- alistproducer2 10y ago
  I disable JSbecause, on a lot of sites, I'm only there to read words on a page and those words come up instantly without JS and in as long as 30 seconds with it. 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.
CognitiveLens 10y ago
I wanted to like this article, but it's not helpful to argue against assertions by making evidence-free counter-assertions. > 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.
kinlan 10y ago
I think Jeremy's post resonates with a lot of our team (Chrome, DevRel etc), we want all experiences to be responsive, accessible, content visible without JS being required and most of all solid design that takes advantage of good URLs. 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:UI%3EBrowser%3EAppShortcuts 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 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 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 https://bugs.chromium.org/p/chromium/issues/detail?id=601337 - Mandating Offline to get banner.
cwisecarver 10y ago
This all boils down to compatibility. You can make your webpage or webapp work on a majority of devices by rendering most of it on the server and delivering it as html with javascript handling the bits that can't be handled by html/css. 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]

107 points by thekingshorses 10y ago

I'm a JS evangelist for sure. I love the language, but I'm not a true believer. Believe it or not, I keep JS turn off on my mobile browser because I enjoy instant page loads. I remember the first time a coworker asked me "but what if they have JS turned off?" I thought "what a dinosaur. Who doesn't have JS turned on?" Obviously I had a change of heart on the subject. 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.

supster 10y ago
I feel like JS is an expected part of the web just like HTML and CSS. How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)?
- krapp 10y ago
  >How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)? 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.
- zeveb 10y ago
  > I feel like JS is an expected part of the web just like HTML and CSS. How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)? 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.
  - agmcleod 10y ago
    I agree you're getting the most accessibility by making a blog that renders on the server. But rendering front ends with javascript shouldn't be considered breaking the web. It's a tool that's available in the browser, and many use it to try and make a better experience for their overall users. I think it's a shame we have the "first load no content" problem, but developers are doing this with good intentions. Making UIs respond faster, reducing back & forth network requests, and trying to make more interactive content on the web. There are some warts we need to sort out and get better at, but I still see it as progress.
    - zeveb 10y ago
      > But rendering front ends with javascript shouldn't be considered breaking the web. If it doesn't work without JavaScript, it's breaking the web. I have absolutely no problem with progressive enhancement. I have absolutely no problem with choosing to enable JavaScript when it makes sense. I have a problem with requiring a privacy-destroying technology in order to consume content.
    - pdkl95 10y ago
      > rendering front ends with javascript shouldn't be considered breaking the web. If you want to serve an empty, broken page as a first impression, you can. I strongly recommend against it because it makes your site look half-finished, poorly designed, and generally unprofessional. > available in the browser That isn't always true. You don't know anything about the browser a priori. > make a better experience Of course. Javascript can add nice features, which is why you progressively enhance the page to add features when the underlying requirements are available. Do you skip the check for NULL when calling fopen(1)? Checking for errors is always important. On the web, this means you should gracefully handle problems like missing javascript (intentionally or otherwise) or other resources. > Making UIs respond faster Requiring two additional HTTP requests (one to load javascript, and another to load the actual page content) isn't making the page faster. After the first request your javascript will be available most of the time for partial loads in any case. > interactive content That is rarely a good idea, but it's your page so do what you want. Progressive enhancement doesn't affect this at all.
- frontendthing 10y ago
  your feelings are not of interest here. If you want to create web apps on a professional level, you have to provide no-js fallback that works everywhere, that is the technical standard. Nobody is interested in how many hours you spend weekly to grow your beard.
- dave2000 10y ago
  > I feel like JS is an expected part of the web 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.
  - Klathmon 10y ago
    A few months ago I wrote a web-app that lets you pick an image off your computer, and convert it to a cross-stitch pattern. I did it using javascript entirely client side, so it works offline, it's secure (as it doesn't send the images anywhere), and it is fast to load (letting you change settings and get the new cross-stitch in the blink of an eye). With your idea of doing things, i would need to pay for a server (and would probably need to then charge my users who wouldn't pay, so it's now DOA), it would be significantly slower, it would be less secure/private, and wouldn't be able to do things like auto-change the size of the resulting image depending on the screen size of the browser (important for mobile! don't want to overload the browser with massive images). That needs javascript, and for you and others to keep acting like anything that uses javascript is a toy that shouldn't exist is arrogant and wrong.
    - mixedCase 10y ago
      You should be shipping that as a browser extension. As it stands it's not good as a website, but it meets every criteria for a good extension. It's even the kind of thing that passes for a native application in Chrome OS.
- Twirrim 10y ago
  > How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)? What do you do for accessibility? Screen readers etc?
- chriswarbo 10y ago
  > How can you build engaging web applications if you are not even allowed to rely on standards like JS (e.g. if the user turns off JS)? 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.
Freak_NL 10y ago
> I never write JS > ECMAScript 5. Why? 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.
- profeta 10y ago
  you are probably too young to remember the time when using <script type="javascript1.2"> was bold and bleeding edge. (probably got the syntax wrong, because, well, that what happens to memory when you are not too young)
- spriggan3 10y ago
  > That's a bold statement. Why EcmaScript 5 and not JavaScript 1.4 for that matter? 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.
  - lucasmullens 10y ago
    I think for most people the time you save using ES6 features is more than the time it takes to set up a build system, at least for larger projects.
    - alistproducer2 10y ago
coldtea 10y ago
>I never write JS > ECMAScript 5. Why? 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.
- wwweston 10y ago
  > Because you started too early during the web's rise, and are now too old for that... 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.
  - coldtea 10y ago
    The problem is not with the individual programmer. One can make wonders with Commodore assembly too. Of course they can do stuff in plain JS. But they'd be reimplementing the wheel a lot. If you want to take advantage of the JS ecosystem as it stands in 2016, you need to use its tools. E.g. just consider using React with JSX -- you already need a transpiler for that.
- alistproducer2 10y ago
  Yeah not really. I've probably written more complex JS code in the last 2 years than you'll ever write in your life so save the "too old" stuff for someone else. When your writing a recursive decent compiler from scratch, you don't really feel like debugging whatever errors some transpiler injects into your code. You'd rather it just work the first time and be sure it works everywhere. Check my github before you start mouthing off..... https://github.com/ShamariFeaster/Templar https://github.com/ShamariFeaster/Templar

carsongross 10y ago

Eventually the pendulum will swing back. The web app model beat out native apps (then called client-server apps) for very good reasons (no install, REST-fulness, simplicity, transparent linkability) but we've become blind to them through long exposure. As surely as Water will wet us, as surely as Fire will burn, the gods of the HTTP Headers, with terror and slaughter return.

Freak_NL 10y ago
Amen I guess? 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.

jakub_g 10y ago

I always say that URLs are the best invention since electricity and cars. Just a few bytes of text but convey so much information, and are universally supported by virtually all software. This is huge. Don't take it away from the people.

CognitiveLens 10y ago
URLs are not going away - like you point out, they are a reasonably good way for software to pass around a few bytes describing a resource location. Their usefulness for humans, particularly within a single site/web app, is less clear - e.g. if we ignore the domain name (which would be constant across a web app), this comment thread is described by 'item?id=11770774' - it doesn't mean anything, and so arguably is not worth displaying anywhere within the HN 'app'.
- matt_kantor 10y ago
  HN has subpar URLs (in terms of UX), but they're still very useful. I can copy the bytes "https://news.ycombinator.com/item?id=11770774" https://news.ycombinator.com/item?id=11770774" and use them to get back to this comment thread later from any device with a web browser. I can give these bytes to a friend to refer them to this thread. I can share these bytes publicly and have a reasonable expectation that they'll allow anyone to retrieve the content on this page (not forever, but the Internet Archive and other caches have your back if this URL breaks in the future).
  - open-source-ux 10y ago
    Making the HN URLs more human readable would also make them much longer. However, the longer URLs could provide a form of site structure if the URLs are 'editable' e.g. https://news.ycombinator.com/2016/05/25/regressive-web-apps Then, if you edit the URL, you can get all stories for today: https://news.ycombinator.com/2016/05/25/ All stories for the month (which would require pagination): https://news.ycombinator.com/2016/05/ And all stories for 2016: https://news.ycombinator.com/2016/ And finally, back to the home page https://news.ycombinator.com/ Note: all these pages don't have to be explictly linked or displayed on Hacker News, they might appear only when someone edits the URL in their browser. Edit: Just to add...here's a lengthy, but very detailed post by an ex-BBC employee about using URLs to model the complex data for BBC programmes Designing a URL structure for BBC programmes http://smethur.st/posts/176135860 http://smethur.st/posts/176135860

potch 10y ago

"Progressive Web Apps" is a Google brand. It's made of some good best practices and great technologies, but they reserve the right to re-define it and change the rewards around it however they choose. Install buttons are the carrot, and search rankings are the stick. Will non PWA-compliant but otherwise fast, well-made mobile web sites rank as highly as PWAs?

lucasmullens 10y ago
Google isn't trying to make every website a PWA. Why would they punish all non-PWAs?
- kinlan 10y ago
  The current way that we see the banner is that it is the equivalent of an App install banner for web sites that meet the rough idea of what a Progressive Web App is and would be something that you would want to install or act like an installed app on the system. 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.
kinlan 10y ago
Just a minor nit, yes we have been working under the Progressive Web Apps headline for a while (I work on the devrel team) but it is a shared term that Opera and Mozilla are using. 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.

emodendroket 10y ago

You can't please everyone, I guess. Who but the largest organizations has the resources to make a fully-responsive SPA that also has non-JS fallbacks for everything?

iLoch 10y ago

I'm so tired of people using "it doesn't work without JavaScript!" as an argument. To me it sounds as relevant as saying "it doesn't work without HDMI!" 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.

askldfhjkasfhd 10y ago
The problem, as people see it, is there is a whole space of websites that use features they don't need. Think of all the 1pageapp content sites. 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!"
- iLoch 10y ago
  The difference now is that most people are using browsers that will automatically update in order to work with new features.
alistproducer2 10y ago
I disable JSbecause, on a lot of sites, I'm only there to read words on a page and those words come up instantly without JS and in as long as 30 seconds with it. 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.

CognitiveLens 10y ago

I wanted to like this article, but it's not helpful to argue against assertions by making evidence-free counter-assertions. > 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.

kinlan 10y ago

I think Jeremy's post resonates with a lot of our team (Chrome, DevRel etc), we want all experiences to be responsive, accessible, content visible without JS being required and most of all solid design that takes advantage of good URLs. 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:UI%3EBrowser%3EAppShortcuts 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 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 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 https://bugs.chromium.org/p/chromium/issues/detail?id=601337 - Mandating Offline to get banner.

cwisecarver 10y ago

This all boils down to compatibility. You can make your webpage or webapp work on a majority of devices by rendering most of it on the server and delivering it as html with javascript handling the bits that can't be handled by html/css. 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]