
JavaScript web apps considered valuable - bpierre
http://molily.de/javascript-web-apps/
======
TimJYoung
This is what I tell potential customers that are evaluating our product that
creates single-page web applications where the JS dynamically creates all
content: if you want search engines to crawl the content, then you're not
using the right product. It's a surprisingly easy decision when viewed in
those terms. Most SAAS products that likely would be implemented as SPAs do
not care about public search engine access, and are only used by B2B customers
where you can dictate a certain minimum standard in terms of browser versions
(IE).

Everything else should be a traditional static web site with "decorative" JS,
or "progressive enhancement".

~~~
onion2k
Google can and does crawl Javascript driven web apps. Last year they even
deprecated the AJAX crawling scheme that they used to recommend on the basis
that they can now crawl web apps:
[https://googlewebmastercentral.blogspot.co.uk/2015/10/deprec...](https://googlewebmastercentral.blogspot.co.uk/2015/10/deprecating-
our-ajax-crawling-scheme.html)

~~~
TimJYoung
Yes, but in the case of SAAS apps, what exactly are they crawling (if allowed)
? In our case, it would be a bunch of edit controls, grids, buttons,
containers, etc. that don't really make a whole lot of sense in the context of
a search engine.

I think it's important to start recognizing that there's two distinct types of
web "applications" starting to emerge: the more traditional kind of
"application" that is actually more like a web site, and the newer kind of
application that is more like an actual application (desktop/mobile).

Edit: Just read the new guidelines, and they are now considering serving up
different content for the crawler as being "against the rules". So that
probably cements the idea that you shouldn't allow Google to crawl anything
that's mostly content-free and just an "app".

~~~
onion2k
"Don't let Google crawl your site if it's not appropriate" is great advice,
that's true, but it has nothing to do with whether you're serving up JS or
HTML.

~~~
TimJYoung
Yeah, I'm conflating the two, based upon my personal experiences.

But, are people really writing applications that generate all content
completely on the client side via JS, but want the end result to be more like
a traditional web site ? That seems weird, even to me. :-)

~~~
bphogan
Tons of news sites are doing exactly this.

I can't tell you how many times I follow a link from Facebook or other social
media, only to be brought to a page where a spinning gif spins for several
seconds while JS loads the article.

------
lhorie
I generally agree with the article, but the examples of javascript web apps
that were given seem weak:

> Most web apps I work with daily have highly sophisticated in-browser
> interactions that are built with JavaScript and can only be built with
> JavaScript: Flickr, YouTube, Facebook, Twitter, GMail etc

The web apps that I use the most day-to-day are Trello, Slack and Gitter.
IMHO, those are better examples of js bringing actual value to the table that
progressive enhancement simply cannot.

With that being said, the issue of overusing SPA technology when it doesn't
fit the need is definitely real.

Part of the issue comes from people wanting to pad their resumes w/ experience
in "hot" technology, or people who do have a genuine interest in improving
their skills, but are not very skilled in identifying the pros and cons of
whatever "new hotness" or "best practice" they read on their favorite news
aggregators. By extension these creates an industry for grunt work to
maintain/refactor/rewrite everchanging codebases/frameworks. Coupled with the
general tendency of people to favor new shrink-wrapped libraries over doing
good ol' painstaking research, it's difficult to reverse that trend.

~~~
workitout
>> Trello, Slack and Gitter

Never used them, are they important? What do they do? I've used all the ones
cited as bad examples.

~~~
lhorie
For me they are tools for work and they are the web apps that I use the most
every day (I work remotely). Trello is a task management system where you
organize tasks as drag-n-drop "cards" and Slack/Gitter are chat apps (Slack is
for company chat and Gitter is for my open source project community).

I do use Youtube/Facebook/Twitter etc as well, but I use them primarily for
content consumption for entertainment, so my usage patterns of those services
wouldn't be affected much if they were written without using javascript at
all. In contrast, drag-n-drop and the ability for real-time collaboration are
the killer feature of Trello (for me), and obviously there's no way web chat
would ever work smoothly without js.

------
anupshinde
I am a JS dev (after a lot of experience in statically typed languages) and
just amazed to see the comments in this thread. At one end its experts(or
near-experts) and at other end is just ignorants who probably did some
$(...).show() and call it javascript. No wonder why its hard to hire good
javascript developers. People just don't appreciate how wonderful this
language is.

~~~
Matachines
Way too many C#/Java developers who used JS in the early 2000s and hated it
still think it's the same language.

~~~
voltagex_
The MS AJAX control toolkit and UpdatePanel probably didn't help, either.

I think I can probably say that Javascript engines are an order of magnitude
faster than they were 16 (!) years ago.

If I may make a generalisation, C#/Java devs are more likely to be
"enterprise" developers and said enterprises were more likely to be the ones
on IE <11\. I know I fought damn hard to upgrade from IE8 just a couple of
years ago. My webdev skills suffered as a consequence, too.

Microsoft moved pretty fast once they realised that IE needed to compete again
- and Visual Studio evolved alongside it (mostly).

VS2015 is now a pretty good development environment for Javascript/Typescript
and even includes some Grunt build support (although I haven't had a play with
it yet).

~~~
bzbarsky
> I think I can probably say that Javascript engines are an order of magnitude
> faster than they were 16 (!) years ago.

Two orders of magnitude. I just checked, and on my laptop
[http://web.mit.edu/bzbarsky/www/mandelbrot-
clean.html](http://web.mit.edu/bzbarsky/www/mandelbrot-clean.html) (the first
JS thing I wrote where performance of the language itself seriously mattered)
runs in about 30-60ms in modern browsers. On the same hardware, it runs in
about 2200ms in Firefox 3, which is the last pre-JIT version of Firefox. Other
benchmarks I've tried show similar improvements results. And that's only going
back to 2008; the interpreter was a good bit slower another 8 years before
that.

------
falcolas
I agree that Javascript web applications have a place. The problem is that the
pendulum has swung too far, and folks are using Javascript everywhere. Static
content generation on the client side, rendering non-interactive content, on
the backend, in the build process, as a generic scripting language... the list
goes on.

We're watching programming and design concepts which played out back with
Windows 95 being hailed as "the future of programming". We're being told
"worse is better" as Javascript is being used to turn our computers against
their users by serving as a vector for malware, ads, and bots.

It's a mess, and it's going to take pushes from the far side of the pendulum's
swing to bring it back to a sane place. If the pendulum was actually stalled
too far towards "server side only", I'd agree that "server side only" articles
would be too much - but we're not there.

> We can only improve the user experience with the front-end technologies we
> have.

No, we are more than capable of degrading the user experience with the front
end technologies we have. There's a lot of proof of that on the web today.
Delayed full page ads, pop-overs for every third word, hijacked scrollbars,
malware installs...

~~~
Wintamute
JavaScript has grown up; it's got one of the best package managers anywhere,
rapidly improving syntax and semantics, a large passionate community, loads of
great tooling and a well maintained cross-platform binary in the shape of
Node. It's no less deserving than any other language to be run on a server, as
part of a build, generic scripts, whatever. Browser security issues arise
because it's hard to resolve total user security across the public web coupled
with highly interactive scriptable web pages ... its got nothing to do with
the JavaScript language per se. It's fair enough to argue against the level of
control scripts happen to have over the browser, but web page scripting could
be implemented in <insert some other language here> and the same issues would
be present. Your comment comes across as ignorant and prejudiced I'm afraid.

~~~
donatj
NPM and the community that surrounds it is a nightmare. I guess you could be
talking about Bower but either way they are far from good,let alone best.

~~~
Wintamute
I was talking about npm. And I find the JS community welcoming, friendly and
passionate and for the more serious npm modules out there highly technically
literate, but hey it's a subjective thing I suppose :/

~~~
kuschku
So, the package manager that doesn’t do proper deduplication and, thanks to
nested dependencies, runs over the file path length limit on multiple
platforms?

~~~
Silhouette
FYI, the nesting and deduplication were fixed in NPM 3. It uses a flat
structure now.

Unfortunately, in their place the version resolution algorithm is now subject
to order dependency: the same package.json file, run at the same time with the
same packages available in the NPM repository, can give different results on
different machines depending on what had already been installed.

~~~
paulddraper
Yep. Solved long file paths. All we had to give up was determinism!

------
XCSme
I am a huge fan of JavaScript myself mostly because I found it very fun to
work with and that you can do anything with it at the moment (websites, games,
native mobile apps, smart TV apps, program raspberry pies and much more).
About single page apps now: don't do a SPA if your website is not really an
interactive application. Do you have a game, photo editor, P2P video chat? If
yes, go ahead, SPA is really great for those things but for God's sake do not
create a single page app when your website actually has more pages with
different content and no interactivity. Why try to emulate how a browser works
(loading, rendering, etc...) inside the browser itself?

------
donatj
> Most web apps I work with daily have highly sophisticated in-browser
> interactions that are built with JavaScript and can only be built with
> JavaScript: Flickr, YouTube, Facebook, Twitter, GMail etc.

There is truly nothing about any of those that couldn't be done with a simple
page refresh. Especially YouTube. Generally I find most of what JavaScript
adds just irritating.

~~~
esailija
That's hilariously clueless. Do you think youtube is just a <video> tag?

~~~
pikzen
Let's list Youtube's features that could be done with no Javascript

* Displaying the video

* Controlling the video (although with the browser's default controls)

* Being logged in

* Listing videos

* Voting

* Commenting

* Suggested videos

* Subscribing

Actually, I can't see a single thing that can't be done without Javascript. It
has no complex notification system aside from annotations (and I'm not sure
anyone enjoys annotations), nothing that isn't provided by browsers. But no
javascript would require page refreshes, which makes for a worse UX. Eh, we
survived refreshes before. Maybe browsers could even agree on a standard to
refresh only part of the pages by querying the server themselves. Throw in
five lines of JS to save to localStorage the current time on the video and
restore it on reload.

~~~
esailija
So you are saying one shouldn't use JS to implement voting and comments but
instead voting and comments should interrupt the video and then one uses
JavaScript to restore the playback position. You also imply youtube should
have waited for 6 years or whatever for video playback to even be possible
without client side programming.

> Maybe browsers could even agree on a standard to refresh only part of the
> pages by querying the server themselves.

Maybe browsers could also agree on implementing all needed applications in the
browser. Then you just make <youtube> tag and you have implemented youtube.

~~~
donatj
HTTP 204. You send the request, the browser stays where it is. Super simple,
and what it was made for. Amazon used to use it quite heavily back in the day.

~~~
jff
The interesting thing about the modern web developer is that they don't know
jack or shit about HTTP.

~~~
donatj
Yes. Quite literally "kids these days". HTTP is so powerful and so under
utilized today.

------
open-source-ux
An unanswered question in this debate is: what is a web app and what is a web
site? Sometimes the boundaries are blurry and sometimes they are clear.

For example, should a blog rendered in the browser be treated as a web app? Or
rendered principally as HTML and CSS before it's sent to the browser (rather
than rendered in the browser using Javascript). Here's an example: over 300K
of Javascript to render a plain text page: [http://elm-lang.org/blog/new-
adventures-for-elm](http://elm-lang.org/blog/new-adventures-for-elm)

My impression is that some developers are beginning to treat anything rendered
in the browser as a web app - even plain web pages with no dynamic elements.

Why do developers do this? Is it because it makes their life easier using a
single tool or language for both dynamic and static content? Or is it because
they want to learn a new framework that's popular or interesting? Whatever the
reason, one has to ask if giving users a good and fast site experience comes
anywhere into the equation.

~~~
paulddraper
"Is it because it makes their life easier using a single tool or language for
both dynamic and static content?"

Mostly this. As soon as you add a bit of dynamicism, it becomes easier to do
everything in one language/workflow.

------
dschiptsov
Each time yet another hipster posts his unique snowflake insights about why we
absolutely need yet another bloatware to build websites _on this vey site_
(which is just static html pages over an FS storage in less than MB of code,
including a dialect of Lisp and related DSLs) a kitten dies somewhere.

------
__derek__
Henrik Joreteg has a related talk[1] and post[2] on the evolution of web apps
that are worth checking out.

[1]: [https://speakerdeck.com/henrikjoreteg/the-evolution-of-
the-w...](https://speakerdeck.com/henrikjoreteg/the-evolution-of-the-web-app-
fluentconf-2015)

[2]: [https://joreteg.com/blog/viability-of-js-frameworks-on-
mobil...](https://joreteg.com/blog/viability-of-js-frameworks-on-mobile)

~~~
sotojuan
Here's another good one:
[https://youtu.be/okk0BGV9oY0](https://youtu.be/okk0BGV9oY0)

------
devit
JavaScript web apps are fine, as long as they are "isomorphic", i.e. the
front-end code is also run on the server and the resulting HTML is sent to the
client, and as long as it's possible to at least navigate to and read all the
content without having JavaScript enabled.

------
wcummings
Am I the only one wondering what the fuck "progressive enhancement" is? Even
the "enhanceconf" website doesn't explain.

>We're convinced progressive enhancement remains an important aspect in
pushing the boundaries of the web while still providing a robust experience
for every user.

What?

EDIT:

>Your HTML is not more accessible or more semantic when it’s rendered on the
server.

IDIOT DETECTOR TO FULL POWER. It is by definition more accessible if it
doesn't require Javascript to render.

~~~
saurik
[https://en.wikipedia.org/wiki/Progressive_enhancement](https://en.wikipedia.org/wiki/Progressive_enhancement)

------
merb
> Most web apps I work with daily have highly sophisticated in-browser
> interactions that are built with JavaScript and can only be built with
> JavaScript: Flickr, YouTube, Facebook, Twitter, GMail etc.

Good that GMail is created with GWT. So it doesn't even use JavaScript. Most
people are so afraid of JavaScript that they create hella crazy abstractions
(Angularjs [Google], ReactJS [Facebook]) and even then Microsoft and Google
trying to avoid JavaScript more and more with Typescript or Dart, they
transpile it. JavaScript maybe is valuable in the web, but not in it's current
form. So much quirks that you either spend using a library or fixing browser
incompabilites.

A lot of people here said that transpiling will be used a lot in the upcoming
years, and I think that also. People will more and more. They want to use
Python/Scala/Java/Whatever on both sides. Also it will reduce complexity by a
lot.

Currently your typical webapp has, a server-side technology (even if you are
using node), then you have a web frontend which uses at least npm, however
mostly you end up with npm, bower, gulp/grunt, webpack and whatever.

> Client-server architectures instead of monoliths

What about small teams? They can't split their monolith since it will become
unmanageable. So if they have two apps, frontend/backend it's still a mess to
manage these projects with a small team.

> We need to stop excluding JavaScript apps from “the web as it was intended”.
> JavaScript apps are “of the web”, not just second-class citizens “on the
> web”.

In my eyes JavaScript should be used where it is needed, but not used in stuff
which never should touch it. JavaScript is still a mess.

~~~
guscost
> Also it will reduce complexity by a lot.

I have to disagree. Adding another layer of abstraction cannot reduce
complexity, although it might make certain tasks _easier_. Consider assembly
vs C as an example: C can make lots of programming tasks way easier, but the
complexity of the system is not reduced.

With C, this becomes apparent when the program segfaults. A garbage-collected
language or Rust can prevent segfaults using a subsystem to manage and/or
enforce memory ownership, again making lots of tasks easier, while adding even
more complexity.

In the case of transpile-to-JS languages, these can fix many of the
shortcomings of JS and make lots of tasks easier, but they are a more complex
system which can cause additional work if the generated code fails at run
time, and the browser debugger brings up something completely different from
your source code.

Your point that we will see more transpiled languages in the future makes
sense.

~~~
mod
I can see where it will reduce code complexity while upping stack complexity.

You're right that it's not always less complex. Trying to trace an error
through some of these systems is ridiculous. I miss the days of it just
pointing to a line number.

