Ironically Apple is also the ones who kicked off the entire PWA race because of the lack of an SDK when the iPhone launched. The messaging then was "build for the web, that is better than native" and now its "native or gtfo" and web apps are not preferred. The last 5 years that I've built web versions of apps first, the client told me "look the web app is great, hard to tell its a web app honestly. Except when I want to..." and you all know the rest of the conversation from here.
Firefox, I love you, but you're bringing me down. We need a powerful, semi-native, offline capable architecture for the web. I don't care about the PWA spec, it's quite messy handling the implementation of one. But I do think it has always been the vision that the web is accessible regardless of physical connection to it.
As long as I can remember in this industry we've swung back and forth between "thin" and "thick" clients as if one way is the right way. Microservices over monoliths, etc. It's all the same symptom that naturally we don't want to grapple complexity. This announcement is yet another entry in the cannon of thin vs thick. It's a hard problem and any PM who only cares about optimizing time spent will say everything they can once they've zeroed in on the perceived waste.
I can't count how many times I've submitted a patch only to hear my supervisors complain that I made a contribution to the thing that makes the business profitable.
One of things I absolutely despise about the JS community is this obsession with build tools. JS is meant to be a runtime language and the amount of transpilers, minifiers, uglifiers, obfusicationifiers, is absolutely endemic to the messy state of change the language is undergoing.
However with this release I'm excited to start deleting a bunch of ridiculous build code to make Webpack work. Really a build tool is a tool, it should never be in the way of developing features. I haven't enjoyed using webpack until now. No sensible defaults, poor documentation, and no standard conventions. This release changes all of those complaints. A boost for productivity is a win in my book.
Their QA department has been in a downward spiral since 2014. I would love to name some people who were doing a fantastic job running the place until then, but I'll spare the embarrassment. This really isn't about some mega company not caring as much as one of their cornerstone departments being unable to function effectively.
No I don't think you need to do that to get interested in it. If you want to see it in action and spin up a playground really quickly, I suggest using Embark (https://github.com/iurimatias/embark-framework). (I contribute to this project)
I just wanted to add some positive comments here complaining the state of the web as we know it today vs. the people who are working on the solutions to the problems. There are well defined paradigms for building distributed systems. While much of the web was built in the belief these distributed systems would take root, lots of engineering went into client-server configurations. There are a ton of psychological reasons why these decisions were made. They don't have to keep being made though. We can all embrace distributed applications (some call them serverless applications) and free the web once again. Here's a lot of great projects that are trying to do just that: http://github.com/toadkicker/awesome-ethereum
In the second article the author explains what a 'JSON pure' api would function. It completely throws out the OSI model and provides no way for the application layer to react to transmission errors, which HTTP codes provide.
It's really silly that is how the culture behaves. The right tool for the job is a common moniker in other industries, yet in ours its the source of heated debate and hipsterdom.