
The “Web Application” Myth - johanbrook
https://medium.com/@codepo8/the-web-application-myth-69c6b1506515
======
gfodor
I guess I'll never really understand articles like this, or I just have poor
reading comprehension. I don't see what the point of this type of thing is, it
feels like a rant without any particular recommendations. It can be summed up
as "don't use technology without understanding it, and don't blindly follow
the crowd." But then again, how are you supposed to learn when a certain piece
of technology should be applied, other than apply it and see how it goes? I
certainly am not going to just take someone's advice and opinions at face
value, unless they can provide hard evidence of why a certain technique
results in failure. It requires a certain amount of cognitive dissonance to
point to Etsy's 2000 files as a failure while at the same time they are a
successful company. Perhaps these bits of incidental complexity we like to
obsess over aren't, in the grand scheme of things, all that important?

To me, the notion of having strong opinions on particular techniques for web
application (or web site) development strikes me as an example of a subfield
having an over-inflated sense of self. Web app development and javascript
frameworks are a _tiny, tiny niche_ of software engineering which is an even
smaller _niche_ of the entire area of the medium of computing. And it's not a
particularly interesting one, imho. I'm not sure why so much ink is spilled on
it other than it's easy to form opinions around.

~~~
sarciszewski
Maybe I can fill in the gap?

If you are a developer, you shouldn't rely on Javascript. Yes, feel free to
_use_ Javascript to make things sexier, but the use cases where a web page
should require Javascript to render properly has substantial overlap with the
"we didn't think things through" slice of the Venn diagram.

If your page is unreadable with NoScript and RequestPolicy turned up to
maximum paranoia, your webpage is broken.

If you're building a client-side application rather than just a web page, then
it's okay if turning JS off breaks your app.

~~~
gfodor
I think I gathered this, but my point is why does this matter? If I run a site
that is unreadable on NoScript and RequestPolicy turned up to maximum
paranoia, but am generating millions of dollars of revenue, is my webpage
"broken?" If only 0.01% of my users actually are affected by such a thing, and
I don't care about that, is it still "broken?" If a webpage has a missing
closing </div> tag, but is never hit by a human being, is it still broken?

I guess what I'm getting at is as I've gotten older I've grown less and less
empathetic to arguments that seem to appeal to an engineer's sense of purity,
correctness, and craftsmanship and not much else. Tie it to user pleasure,
effectiveness, business metrics, anything, but citing the idea that somehow
since the web was not designed with Javascript everywhere in mind meaning we
should use it as the exception not the rule isn't much more than appeal to
tradition argument to me. There are definitely areas of software engineering
where you can find many examples where a lack of respect for the craft, or a
lack of knowledge of history/standards results in failure, but I'm just not
buying the idea that if you build a SPA with a fancy new javascript framework
instead of making sure NoScript works you're somehow going to be paying for
that in spades down the road because it's breaking some set of rules handed
down by the high priests. There are about a million other technical decisions
that have more of an impact in a serious project. (For example, instead of
arguing about SPA vs non-SPA, or what framework, or whatever, ask yourself:
"Is anyone on the team an expert in any particular flavor of this?" If the
answer is "yes", then going with any one of those is almost certainly the best
strategic decision _regardless_ of the supposed merits or flaws of that
particular approach.)

~~~
archagon
Plus, it's just railing against the tide. I don't disable JS. None of my
friends disable JS. (In fact, most of my friends don't even know what JS
_is_.) The setting to disable JS is hidden away in some obscure pref pane in
most browsers. It's not going anywhere, it's not optional, and pretending that
a site is "broken" if it doesn't work for a handful of geeks is being
willfully obtuse.

~~~
philbo
It's worth noting that "disabling JS" is not the only way to disable JS.
Sometimes it can happen inadvertently:

* Bug accidentally makes it into production, preventing some crucial feature from working? JS just got disabled.

* User is browsing your site with an old device that doesn't support a feature you make use of? That JS has been disabled.

* CDN fails and your fallback mechanism isn't working like you thought it was? JS got disabled.

Not saying these are common occurrences, but I've seen all of them happen.

------
detaro
> “All modern websites, even server-rendered ones, need JavaScript” — No. they
> do not. They all can become better when enhanced with JS.

This. Surfing with uBlock with strict javascript settings leads to a
surprising amount of broken pages that do _nothing_ with javascript that is
mandatory. From graphical gimmicks that get stuck covering the page to
breaking buttons on search forms, there is a lot of stuff that could work just
fine, without the scripts adding any real benefit.

I get that for more complex use cases there are tradeoffs to be made (e.g.
implementing a server-side AND a java-script version of functions, adding
dynamic content to staticly hosted pages, ...), but there also are a lot of
low-hanging fruit.

~~~
Springtime
I can't count now the number of pages I've visited that return nothing but a
blank screen with scripting disabled. I've become used to it recently, but
it's often for sites without much going on. It's a little ridiculous.

~~~
clarry
The best part is when they seem to load and display just fine, until at the
very end of the document where there's some element that'll suddenly cause
everything to disappear...

~~~
mjrpes
Hah, those are fun to come across. It then becomes a test to see if you can
reload and cancel the reloading at the right moment to prevent the offending
last element from loading.

------
Animats
The incredible complexity of the machinery behind many rather plain web sites
is embarrassing. There are a lot of web pages which would look exactly the
same if implemented in HTML with no Javascript. Except that they'd load
faster.

------
z3t4
When I make web apps today, the HTTP is only used to serve the client
application. Basically, it would be equivalent of

    
    
      wget http://mydomain/myapp
      make
      run
    

But with the benefit of running in a (browser's) protected environment .. The
above would be OK in linux running jailed, but a possible catastrophe in
Windows where you basically run everything with root (although that has and
will probably change in later Windows releases).

Once the "client" has been downloaded and running, all communications are done
via Websockets. So it's no longer a HTTP-application or "REST".

What makes it so convenient is that the user can both download and run the
application in ONE click (no install, yet cached). Without worrying about
malware, so I don't need their thrust. And the client can run on basically all
devices and OS's, so no need for porting.

~~~
teddyh
“ _Installing things has gotten so fast and painless. Why not skip it
entirely, and make a phone that has every app “installed” already and just
downloads and runs them on the fly?_ ”

[https://xkcd.com/1367/](https://xkcd.com/1367/)

------
emehrkay
The react conference videos are great. The technology seems awesome. But there
was one quip that caught me off guard, the presenter said something like: "if
your application still has urls to back up every action, like it's the
90s...," I instantly thought about how and why that would be a bad thing and
how and why progressive enhancement is a great thing. I look forward to a time
where JavaScript performance is as "free" as CSS, but we are no where near it.

~~~
lstamour
The quote in context was referring to how thanks to JavaScript rendering
server-side and client-side using the same routing, where every action had a
URL (like the 90s), you could then browse the site powered by JS, without JS
or until it actually loads. It went on to talk about how cool URIs don't
change ... JavaScript performance is thus free because content is delivered in
pre-rendered HTML, then JS is loaded for further manipulation later, and if it
doesn't load in time, the site still works. The "like the 90s" comment refers
to using JS to behave more like static webpages do, which is still a novelty
for some single page apps. The funny part is we probably don't even know how
common it is -- if a website doesn't break our understanding of the web and
also renders server-side, how would most know that JavaScript is even
involved?

------
pippy
The problem with web development isn't that there is a resurgence of bad
development practices. It's that the average web developer isn't as skilled as
what they need to be.

The average U.S. worker spends 4.6 years in a given career, and yet it takes
~5 years to master a framework. The average computer science grad earns much
more than a web developer, so the skill set required for proper development is
often lacking. Add into the mix cheap offshore labour, poorly made "out of the
box" web packages aimed at medium-small business, and inexperienced "geeks"
who build poor websites on the cheap.

Given the skill set required for professional level web development is on par
with software development, it's no surprise the role isn't getting the skilled
people the career requires.

~~~
adamnemecek
> yet it takes ~5 years to master a framework

Are we talking about web frameworks? Because it sure doesn't take 5 years to
master most web frameworks.

~~~
maemilius
If you apply yourself, I agree. The problem is really that, when you're just
trying to get a job done, you often don't run into all the edge cases and
weird shit that can happen or even some of the less common error states.

It really comes down to how complex your project is and how integral the
framework is to it.

------
thekingshorses
> it would be interesting to learn what lead to over 400,000 lines of CSS in
> over 2000 files for an actually not that complex site in the first place

This is so common. Lot of time, they use CSS to change the design of the
module, which is how it should be. But when they revert the look of the
module, instead of deleting CSS, they add new rules to overwrite existing CSS.
Which leads to specificity fight and !important.

At my previous job, site was rendering on server. It was old, and we wanted to
redesign it. I wanted to keep rendering on the server. CTO and VP wanted to
build Angular site because everyone is moving to Angular and its easy to find
Angular developers. Company's 30+% of new visitors comes through SEO.

~~~
IkmoIkmo
> At my previous job, site was rendering on server. It was old, and we wanted
> to redesign it. I wanted to keep rendering on the server. CTO and VP wanted
> to build Angular site because everyone is moving to Angular and its easy to
> find Angular developers. Company's 30+% of new visitors comes through SEO.

I think I missed the point of your second paragraph, I'd be interested to know
what you meant to say. (currently working with Angular on a small hybrid app
and thought about experimenting with it on the web but SEO concerns were the
first thing that came to mind, so it feels like a relevant piece to me!)

~~~
lstamour
The implication is that without server-side rendering, SEO would drop. This
isn't actually true for Google (edit: sometimes!), since it executes
JavaScript, in part to prevent SEO gaming of its platform. But it would likely
harm other web crawlers unless care was taken to incrementally add Angular to
the existing HTML pre-rendered, or to execute the Angular.js server-side for
bots and a nice page load speedup.

~~~
mikermcneil
@lstamour Careful! We tested this theory last Fall with sailsjs.org and it
turned out to be patently false-- we went from the second result when you
google "Node.js framework" to not even being present. When I turned our
headless browser snapshot stuff on again about a month later (we use
brombone), it worked itself out. Needless to say, sucks :/ But everyone should
be aware of the reality.

~~~
lstamour
Sorry, that's true. I should have been a bit less forceful on that one. I know
personally that there's a lot which goes into Google's rankings -- for
instance: mobile optimization, SSL, and (where JS can slow things down the
most) page speed. Google wants the web to be fast, and if two websites have
identical rankings, it will rank the faster one higher. Waiting on JavaScript
delays the "time to visible content" by a significant amount.

------
chrisdotcode
(This is a reply to a nested comment, but I felt it was important enough to be
top-level):

> and pretending that a site is "broken" if it doesn't work for a handful of
> geeks is being willfully obtuse.

This is the common rallying cry of the 'use-JS-for-everything' camp. The most
important reason a user should have an internet-wide blacklist on JS as the
default is because the default should _NOT_ be to allow any website ever to
run arbitrary scripts on a user's machine.

That's like always running as root while on a development server. No, wait -
that's like having random people from the street have root on your server for
arbitrary amounts of time, and all you can do is watch. Principle of least
privilege certainly applies to the web as well.

Let's not even mention how an open and private web is hindered by orders of
magnitude from Google analytics and Facebook like buttons tracking you across
entirely different spectra of websites simply because the sites you're
visiting has them embedded.

\---

EDIT: Can the downvoters please reply with constructive criticism.

~~~
TheAceOfHearts
I think it's worth noting the difference between a website and an application.
I like it when docs, news sites, blogs, etc. work without JavaScript. I
consider it very important that my own blog work without JS.

If I'm making a game that's not turn-based, going JS-free is literally
impossible. For a lot of applications you could in theory make a JS-free
version, but it would require making a COMPLETELY separate implementation of
the application, and for a lot of people that's just not justifiable. Most
people simply don't have the time and resources to achieve this, so obviously
they'll favor the larger chunk of users.

For example, let's say I want to make an image editor. I can imagine some ways
in which I could possibly implement certain functionality without any JS, but
the experience would be ABYSMAL. Seriously, consider implementing even a
MICROSCOPIC subset of the functionality provided by Photoshop with JUST
server-side rendering.

~~~
chrisdotcode
Word. Blacklist-all-by-default should be the strategy, not haphazard
whitelist. Very similar to how you're asked if you want to share your
location/microphone/etc with a website - JavaScript should likewise be
compartmentalized based on functionality and necessary access permissions
should be required of the user on a per-site basis first.

------
TheAceOfHearts
I always take one of two extremes: either the website has to work without JS
so I need to make it so that _everything_ works when JS is disabled, or I'm
going to assume JS is enabled and I'll be going all-out.

If you're making a _website_ , I'd say you should try to make it work without
JavaScript, and in a lot of cases it can be achieved without that much effort.
Blogs, news sites, docs, etc. are typically easy.

However, if you're making an _application_ , I'd argue that it's pretty much
impossible to do it without JS. It's possible if you're willing to implement
your application multiple times (once in a JS-heavy way, and once in a JS-free
way), but that's not feasible for most people. The other possibility is
implementing it in a way that's friendlier to JS-free users, but for any non-
trivial application that'll lead to a really shitty experience for most users.
You just can't do sophisticated interactions when you're making something JS-
free.

------
MattHeard
I haven't written a single-page application, but when I published one of my
websites last year, I wanted to make sure that as much of the functionality as
possible was available for users with Javascript disabled or unavailable. My
target audience includes users of cheap phones in developing countries, and
while I have heard a lot of developers say "less than 1% of my users don't use
Javascript", I believe the numbers are a lot higher in developing countries. I
cannot remember the estimates off the top of my head, but I remember it being
a significant number. While cheap smartphones should shrink the gap in the
future, I didn't want to be contributing to a systemic bias against users in
developing countries. It's important to note, though, that my website was a
side-project with no profit-motive, so I didn't have a deadline to meet and
spent plenty of time testing the site for those edge cases.

~~~
jbergens
You should always know your audience. The problem I feel is that some
recommendations says something like "always make apps that work without
javascript". If you know that about 99% of your users have javascript that may
cost a lot for the last percentage. It is also diffrent for public service
apps from authorities that people are required to use and a new
product/service you want to sell but where there probably are or might be
competition that does things differently.

------
edwinjm
Christian Heilmann makes a lot of thinking errors here:

1) Because a technology fails in the hands of amateurs or learners, doesn't
mean the technology is bad.

2) He assumes webdeverlopers don't think about the consequences of a
JavaScript only website. In my experience, that's not the case.

3) The fact that there's a lot of talk about JavaScript frameworks does not
mean webdevelopers are less interested in the end product. It means JavaScript
and everything around it is in flux and improving every month. And the
decision which framework to pick is very important. It can mean the difference
between a stalled or thriving end product one year later.

------
jasim
I still fail to see why we should not use Javascript for everything.

> "That is the great thing about web technology. It isn’t clean or well
> designed by a long shot — but it is extensible and it can learn from many
> products built with it."

That _was_ the great thing about web technology: 'worse is better', but it is
no longer an aspirational goal. As a developer I need a well-designed web to
build on, and these modern frameworks are doing exactly that.

> If we do everything client-side we do not only need to deliver innovative,
> new interfaces. We also need to replicate the already existing functionality
> the web gives us. A web site that takes too long makes the browser show a
> message that the site is not available and the user can re-try. When the
> site loads, I see a spinner. Every time we replace this with a client-side
> call, we need to do a lot of UX work to give the user exactly the same
> functionality.

There is no "Loading" spinner anymore on a well-built JS-heavy application.
Good frameworks (React, Ember with FastBoot) use Javascript on the server to
send a fully rendered HTML to the client. That works. And they rehydrate this
HTML with JSON data and client-side logic so that any further JS interaction
is smooth and can be done using the conveniences of the framework.

But if were to follow the gist of what the article is trying to tell us, we
should instead be rendering HTML using typical server-side technologies, and
use progressive enhancement to add dynamism in the client. This is not a good
solution: we have to duplicate rendering logic on both the client and server
using two completely different stacks. It is a lot of cognitive load, needs
duplication of effort, and is a maintenance nightmare.

A better solution is to simply render everything using Javascript, and
remember that Javascript is no longer a client-side technology. Use the same
Javascript to render contents both on the server and the client and rehydrate
the rendered HTML transparently on the client.

I also disagree with the author's implied assertion that people who use
conveniences like SASS do it more because of incompetence in wielding CSS. The
kinds of abstractions CSS promotes are selectors, specificity, and cascade.
They are not the kind of abstractions one needs to build a maintainable and
reusable body of code. We programmers know what they are: variables, modules,
objects, control structures, expressions.. SASS provides some of those missing
pieces: variables, mixins, conditionals and expressions. In fact SASS pushes
CSS closer to a programming language than CSS is, and that is a good thing.

The article closes on this note:

> A lot of our work on the web goes pear-shaped in maintenance. This is not a
> technology issue, but a training one. And this is where I am worried about
> the nearer future when maintainers need to know all the abstractions used in
> our products that promise to make maintenance much easier. It is tough
> enough to find people to hire to build and maintain the things we have now.
> The more abstraction we put in, the harder this will get.

I'm as close to an abstraction-hater as the next person. But there are good
abstractions and bad ones. Mutating DOM directly using spaghetti Javascript?
That is just no abstraction. Once we understand the rendered view as a
function of state, then it makes sense to have abstractions based on that idea
(like one-way or two-way data binding).

The need for training is not a point of contention. But assume we have
competent developers working in good faith, and they still find it hard to
write well-maintainable code for the web, then it has to be something else
that is broken. Having used these newfangled frameworks for a while now, I do
think that is very much the case. Anyone should be able to put together
reasonably written web-apps without being masters at the craft, but it has so
far been hard, not because of people, but because of tools.

~~~
quadrangle
I'm not an expert, but I know that server-side JS is completely feasible
approach here. However, it may truly not be the best tool for the job. Client-
side JS being required is a fundamental problem for all sorts of reasons, such
as accessibility and more.

One issue is: plain old HTML and CSS are better tools for regular people to
deal with to lower the barriers to wider participation in the web. Having to
learn JS to make sense of a website is an extra burden.

To me, it comes down to: see all the complaints about brokenness when client-
side JS fails or is off. Building things with client-side JS as a requirement
is unacceptable. Now, ignore client-side. Can you actually make the case that
server-side JS is superior to other frameworks and languages? It shouldn't be
used just because it's the same language as the client-side enhancements. If
it's not the best option server-side, go with the better options instead. But
I don't know enough myself to make that judgment, I'm just talking about the
way to think about it.

~~~
mikermcneil
So disclaimer I'm a little biased towards Node. It brings me tremendous
philosophical zeal.

You're right about server-side JavaScript-- there are so many more useful
features in other languages, and things are more expressive (I like Lisp and
Groovy, for instance). But the beauty of server-side js is that it's our
esperanto. I'm interested in seeing a new generation of kids and senior
citizens participating creatively on the web. But in order to do that, we need
to standardize to a single programming languages across use cases,
disciplines, and preferences. And JavaScript, whatever you think of it, is the
best opportunity we've had.

~~~
gregjor
This is a fairly old argument. The single universal programming language that
anyone could pick up and use led to BASIC on the low-end and PL/1 on the high-
end. Neither is used much anymore. Neither appealed much to a wide audience of
non-programmers, though BASIC came close. And neither were anything near
universal even in their heyday.

If server-side JS is "our esperanto" that's damning with faint praise.
Esperanto is not a universal language, it doesn't fill any actual need, and it
hasn't encouraged more people to read or write.

------
quadrangle
This article should be required reading for every web developer / web
development course etc.

