
A pause to refresh the Web? - prostoalex
https://www.oreilly.com/ideas/a-pause-to-refresh-the-web
======
TheAceOfHearts
What does "slowing down a bit" even mean? Sorry, but this just reads like
total fluff to me. Where exactly should we slow down? There's no clear problem
statement nor proposed solution.

Web development has been improving drastically over the last few years, which
is amazing. But you don't have to use any of these newer technologies! Even if
it's evolving rapidly, it's also pretty strict when maintaining backwards
compatibility.

Another problem I have with this article is that it puts websites and web apps
in the same bag. You cannot do web apps without JS. There are tons of
applications that are impossible without JS! Progressive enhancement is not
feasible for applications. When I have document-focused content, I make sure
it works with JS disabled, but I don't think anyone should bother with that
when they're building a web app.

There's a lot of tools that are really targeting applications, but they get
jammed into regular websites.

What I do think we should do is improve our documentation and improve our
communication skills. I don't think this is limited to the web, but I'd love
it if people were more up-front about what problems their framework or library
is meant to solve. Talk about the tradeoffs that you made when building that
framework / library, and explain why you made those design decisions. This is
all important in figuring out what tools to use. And talk about its
shortcomings as well! Tell me what parts are still rough around the edges.
This can help developers decide on whether or not X framework is a good choice
for their problem.

~~~
Silhouette
_But you don 't have to use any of these newer technologies! Even if it's
evolving rapidly, it's also pretty strict when maintaining backwards
compatibility._

I wish that were true. Unfortunately, thanks to browser developers' open
hostility towards plug-ins like Flash, Java and Silverlight, it is no longer
possible to build specific parts of a web site/app that need extra
functionality using a range of tools, and instead all you get is browser-
native HTML5 and JS and so on. When they work. Which they frequently don't.
And if they do, they might not tomorrow, because browsers update every six
weeks and break non-trivial applications of HTML/CSS/JS and related
technologies all the time.

Until we get back to having a sensible degree of standardisation and stability
in the platforms and the tools we use to build on them, it will remain
impossible to be sensibly productive when building professional-quality sites
and apps. You simply can't do that when you're building on perpetual beta-
quality foundations and the goalposts are moving literally every few days in
ways that can break your entire app or tools set-up, because you will
inevitably spend a stupid amount of time on overheads.

------
cognivore
"In many ways this echoes '90s conversations grousing about why the Web didn't
have the same powers as desktop applications."

Um, the web still doesn't.

------
bobajeff
The argument that the web is slowing down seems hinged in the idea that walled
gardens will stall it's development. However Google controls about 80% of the
market and they are one of the main companies pushing progressive web apps.

~~~
untog
Yes, but Apple is an example of a walled garden that, while not actively
working against the web, is definitely holding it back. One browser release a
year with very few new API additions is a problem.

~~~
ksec
Um.... how about Apple do actually take a look a the technology, evaluate it,
before adding a bunch of similar API every year?

------
protomyth
or we could do what we do in technology and jump on the next wave...

Someone just has to invent it and people have to start using it. Entropy is
going to be pretty hard to overcome, but it has been every other time.

I look at how fun it was to develop on the NeXT the web was invented on and
realize its still harder than writing an app on the same NeXT computer.

------
EdSharkey
React highlights how crummy the DOM is for performance-sensitive apps and how
fantastic JavaScript has become. When devs' current fatigue wears off, I hope
they pick up React and see just how different it is.

Browsers need an alternate DOM api with simplified immutable data structures
and a tunable subset of CSS before I'd be comfortable with interacting with it
directly. There are a zillion beartraps in DOM and CSS.

