
The Deep Roots of JavaScript Fatigue - rapjs
https://segment.com/blog/the-deep-roots-of-js-fatigue/
======
samcodes
I have learned so much from comments on Hacker News. Every time one of these
articles gets posted I hope that I will get to see some thoughtful commentary
on why the ecosystem looks like this: is it the enormous influx of new talent?
Is it the consensus to finally drop IE support, and that we're getting a
decade of progress in two years? What business demands are driving this
technology? Is this a race to make the browser experience on-par with native?
How do all these things interact, and what about all the other factors that
I'm not smart enough to see, but usually someone on HN points out for me?

But no, I never get to read that, just complaints about how the whole
community is dumb. Really? That seems unlikely. I don't believe this is
pointless tech churn, akin to fashion. It really feels to me, at least, that
there is a direction that the tooling is heading. I'm not sure what it is, but
I feel like if that's where these conversations were focused (instead of just
rejecting the current state of things) we could figure it out.

Yeah, it's frustrating as shit, we needed to all be pissed about it for a bit,
but let's have a productive conversation.

~~~
cognivore
"...but let's have a productive conversation."

Okay, I'll bite.

With a web browser, a DOM, and Javascript, where do you see this all heading
that's full of truth and beauty?

Where does the churn end if it's not pointless?

Cause you've got a web browser that was designed to view pages of linked
information that has now been pressed into service as a ad-hoc run-time for
building applications, a DOM that is so poorly implemented that most everyone
tries to abstract it away at some point, and a language that is universally
regarded as one of the worst ever.

Is that what you build on for the future? Cause then I do see it being
pointless tech churn because your fundamental building blocks are too
seriously flawed.

If the future is programs that people can download and run on their computer
on demand you'll need a good run-time, language agnostic, compiles to binary,
sandboxed, with a well defined UI system not based on document display.
There's no web-browser, DOM, or Javascript in sight.

If you had such a thing this thread of conversations wouldn't even be
happening. I sincerely hope that someone smarter than me comes up with that
(yes, Java was a close but no cigar) and we gravitate away from the morass we
have now.

~~~
mapgrep
I'm not sure putting down JavaScript, web browsers, and the DOM, and saying
the ideal future is completely free of apps built on this platform, is
technically being "productive" in a conversation ABOUT those things, but
setting that aside:

The web app platform represents one of the largest, if not literally THE
largest, explosions of programming and application development ever seen in
the history of humankind. It also represents one of the most open and portable
computing environments ever developed. It incubated a revolutionary and
indispensable app for indexing, searching, and retrieving an unprecedented
staggering corpus of human knowledge (Google.com); apps that have enabled
hundreds of millions of people to effortlessly publish their writing, videos,
pictures, etc globally and instantly (Twitter, YouTube, WordPress, Blogger,
etc etc); apps that make it trivial to find most of the people you have ever
known and to collapse time and space to communicate with them (Facebook,
Gmail, etc etc); apps that enable you to select virtually any product
imaginable and have it delivered, usually within 24 hours if needed (Amazon,
Ebay, etc etc); not to mention probably _millions_ of other more obscure apps
to handle amazingly specific mundanities of office life, travel,
entertainment, citizenship, finance, etc etc etc.

To look at all this and land on the conclusion that JavaScript and the web
stack are fucked up‚— "a language that is universally regarded as one of the
worst ever" — period, full stop, EOM, throw them out — seems aggressively
contemptuous and beside the point.

It's sort of like looking at a raging party filled with some of the most
interesting people you've known and some of the most interesting people _you
've ever heard of_ and complaining about the type of speakers being used to
play the music.

I can't speak for the OP but I think that's roughly what they were getting at.

(Also, side note, Tim Berners Lee may perhaps have conceived the web as a
place for documents, but he also seems to have since then embraced it as an
application platform, not that his opinion or original vision should in any
way confine what the web becomes. [http://venturebeat.com/2013/03/09/tim-
berners-lee-sxsw/](http://venturebeat.com/2013/03/09/tim-berners-lee-sxsw/) )

~~~
zeveb
> I'm not sure putting down JavaScript, web browsers, and the DOM, and saying
> the ideal future is completely free of apps built on this platform, is
> technically being "productive" in a conversation ABOUT those things

Would everyone is discussing the high quality of the Emperor's new clothes, is
it productive to point out that he is, in fact, naked as a jaybird?

At some point we have to face up to the simple truth that JavaScript, the DOM,
XML and HTML-as-she-is-written are _bad_. The people who assembled them over
time aren't evil, or even generally incompetent: there are historical reasons
for almost all of the cruft. But that doesn't mean that it's not horribly,
horribly crufty, that is is objectively _bad_ and in poor taste.

> The web app platform represents one of the largest, if not literally THE
> largest, explosions of programming and application development ever seen in
> the history of humankind.

That's the logical fallacy known as _argumentum ad populum_ , i.e. arguing
that because something is popular is is correct.

> To look at all this and land on the conclusion that JavaScript and the web
> stack are fucked up‚— "a language that is universally regarded as one of the
> worst ever" — period, full stop, EOM, throw them out — seems aggressively
> contemptuous and beside the point.

It _is_ aggressively contemptuous because the current web stack deserves
contempt. That _is_ the point.

> It's sort of like looking at a raging party filled with some of the most
> interesting people you've known and some of the most interesting people
> you've ever heard of and complaining about the type of speakers being used
> to play the music.

No, it's more like complaining that each of the interesting people is wearing
a blindfold, earmuffs & a gag, with a hobble to prevent him from getting
within arm's reach of anyone else and can communicate only by reaching out
with a stick or probe and tapping out Morse code messages on other's arms.
Sure, all those impressive people are doing a _bang-up_ job of overcoming the
absurd limitations of the insane party, but that doesn't make the party one
bit less insane.

~~~
xd
Wanna back up that beautiful rhetoric with some actual objective reasoning as
to why; HTMl, Javascript, the DOM are "bad" and some ideas on the way forward?

~~~
taurath
It is "objectively" "bad" because if you bring javascript up in certain social
circles involving programmers everyone huffs and puffs. I've heard people time
after time who've never stepped foot out of a Java IDE complain about how hard
it was for them to write something "simple" and "basic" in javascript. Not to
claim that there is any real veracity in the wisdom of the crowd, but there
are hundreds of thousands of programmers writing working, functional, useful
apps in javascript every damn day. People can say that fact is DESPITE the
language features but these people ignore that if you want to actually reach
customers you have to use the most popular runtime of all time - the browser.

Being unable to have a conversation about the ecosystem because the language
isn't to your liking or preferences speaks to me of a closed-off mindset,
which as everyone knows is a great trait for programmers to have /s.

------
NDizzle
The only horse to bet on at the moment is jQuery. I know, I know. I'm old and
I don't do exciting things. I work mainly on a niche product in a boring
field.

But you know what? My site works with IE8+. I can deploy code without much
thought as to what is going to break. My deploy script takes 15 seconds. I
don't have to rewrite anything every 3-6 months. I can update something that
hasn't been touched in 2 years and it works exactly as expected.

I'll welcome all you bleeding edge javascript hippies back with open arms. But
you have to use the side door. [https://s-media-cache-
ak0.pinimg.com/736x/f0/10/a3/f010a3aad...](https://s-media-cache-
ak0.pinimg.com/736x/f0/10/a3/f010a3aad1006eab897f0acbcbb84c9a.jpg)

~~~
dham
Imperative jQuery isn't that bad at all. I agree with you. Once I actually sat
down and really learned Javascript 4 or 5 years ago my jQuery got a lot
better. I don't think developers understand how to write maintainable jQuery.
I see a lot of code where people unbind events before they bind and not using
the .on methods.

It will still crumble in super complex interfaces though. Which in my
experience don't pop up that often, and when they do it's only on one or two
pages.

~~~
sklivvz1971
The new tabbed interface of Stack Overflow (in alpha) is all pure jQuery and
it's fairly complex. I don't think it "crumbles" at all.

[http://meta.stackoverflow.com/questions/308875/new-
navigatio...](http://meta.stackoverflow.com/questions/308875/new-navigation-
release-candidate)

Disclaimer: I was one of the developers.

~~~
dham
That's awesome. We need more developers like you writing blog posts and going
on Podcasts to kind of balance out this "chasing new shiny things all the time
developers". When a tech becomes big there's a million blog posts about why
it's awesome(extjs, backbone, knockout, angular, react). I've seen it all. Not
enough constructive views on the other side.

------
PhilWright
We are simply going through a Cambrian explosion in the JavaScript ecosystem.

Today there is huge demand for the ability to develop desktop standard
applications inside the browser. At some point in the last few years we hit a
tipping point where the potential to do this was unleashed. I am not sure
exactly what the technology was that tipped us over, maybe a combination of
several. Was it fast JavaScript performance, AJAX, client side frameworks or
NodeJS? Whatever the cause the dam has broken.

In a few years the winners will emerge. But it is impossible to know if the
current leaders are going to win or if another champion will appear tomorrow.

I intend to enjoy the ride and look forward to the improved productivity and
capability of web apps that results from the chaos.

~~~
prewett
JavaScript is the only UI environment that has gone through 10 years of solid
churn. Pick any other UI environment besides HTML/CSS/Javscript and it is
pretty stable. So why is the web so churny? It makes me think there is
something rotten underneath.

~~~
manyxcxi
It also may be the people that are drawn to it. There are backend/frontend dev
stereotypes for a reason. In my experience, the frontend dev teams have tended
to be earlier in their careers and more likely to come from a 'non-
traditional' background into tech. You're not seeing code boot camps popping
up for Java and .NET developers like you are HTML/JS and Rails.

It's not a knock, the younger people usually bring the enthusiasm and fresh
ideas to the table- but that enthusiasm and zest hasn't been sobered with a
decade of real world experience and a more analytical/engineering background
and schooling.

~~~
samcodes
This is a really interesting point. I think another factor is that if you have
a huge amount of users, you need robust server code. But front end code only
has one user at a time. And it's much more tied to design, so it gets "stale"
faster, so there are just very different pressures on it that make it less
amenable to a traditional engineering approach. In that it might be worth
trading some robustness for speed of updates.

~~~
manyxcxi
You bring up a good point that I missed in my first comment. The design. God
damned designers! I kid- I worked at an agency for years and the hardest part
was always getting the build to match the design when they were still laying
out the design pixel perfect in Photoshop and Illustrator as if we were doing
print work or doing fixed width pages.

I've seen some designs that were, frankly, beautiful but it took no more than
5 seconds to highlight the 30 areas that were going to cause massive budget
overruns trying to make look exactly right, have decent performance, and work
in eleventybillion browsers.

I've certainly appreciated what interesting designers can bring to the table,
but we're still a ways away from a lot of traditional designers having a good
handle of what their design really means when we're building it. Kind of like
the contractor who bitches about the architect for designing an angle that is
impossible to hammer into. Sometimes there is a disconnect.

------
samth
So much of this history is wrong.

1\. ECMAScript is called that because Sun (now Oracle) owns the JavaScript
trademark, not because anyone wanted to be diplomatic.

2\. JavaScript language evolution was not primarily driven by the Firefox
team. Mozilla didn't start until 1998, by which time pre-ES5 standards were
mostly done. There was an effort called JS2, led by Waldemar Horwat (then of
Netscape) which didn't result in a standard. Other SpiderMonkey JS extensions
were mostly not adopted, or adopted in ES6 in heavily revised form.

3\. The creation of the spec was driven in significant part by Microsoft,
whose internal spec documents formed the initial basis for ES1.

4\. The "harmony" name came entirely after the end of ES4.

5\. None of the design of classes, modules, or other major ES6 features comes
from ES4. Smaller features such as `let` were present in ES4, along with very
different class systems, namespace systems, and other features.

6\. Neither JScript versions nor Spidermonkey's JavaScript versions ever had a
significant impact on JS on the web.

7\. Unlike ES4, ES6 is backwards compatible. ES6->ES5 compilers are not needed
to make it backwards compatible.

------
officialchicken
I thought the article started strong and skipped around serious issues so it
could focus on a pretty nice history of JS, but the conclusion was horrible.

> Babel has worked it’s way into the standard Javascript toolchain, and now
> most builders include it as a first-class plugin

Which version of Babel, 5? or 6? Because there's a lot of incompatibility
issues right there and I think it is just as symptomatic of the typical JS
fatigue issues which aren't really discussed.

I'm not as optimistic as the author about the future. The fatigue is real -
and the value proposition of having to throw code away every year isn't that
great. The JS build toolchain and steps are just plain old insane; and neither
durable nor resilient. 4-6 month old code bases become antiquated vs a few
years ago when you could expect 4-6 years max.

BTW, I'm pretty sure C had the same kind of explosion 30+ years ago... Obj-C
started off as a set of macros in the late 80's/early 90's. But it wouldn't be
proper JS engineering if a wheel wasn't reinvented along the way.

~~~
cubano
No, I lived the C-explosion of 30 years ago and it was absolutely nothing like
what I see these days.

It utterly nuts how we are expected a learn a full-stack like
Mongo/Angular/Backbone and then 6 months later is like NO we need
AWS/React/Redux now!

It's my oldman opinion that IT has become too much like fashion and not enough
like engineering, but that's what oldmen think so who cares.

~~~
wonnage
You can either shut yourself off from it and cement yourself into "oldman"
oblivion, or actually try to understand why these tools exist.

~~~
manyxcxi
> You can either shut yourself off from it and cement yourself into "oldman"
> oblivion, or actually try to understand why these tools exist.

For other languages/ecosystems I would agree. However, in the JS world there
is a lot of stuff that exists simply to exist. There are typically multiple
libraries to do the same thing (in general) but with someone else's
opinionated take on it.

Sometimes I feel like the developer of framework B was having a hard time
grokking framework A and just decided to roll their own, like framework A,
except for the parts they didn't like or understand. Then someone came along
and realized that framework B had gaping security issues and was horrifically
slow- so they created framework C which is the more secure and performant
opiniated take on framework B that was an opinionated take on framework A. But
then after four long months the devs behind C no longer maintain it because
they've moved on to WebAssembly so a team spins off a fork of C in
Coffeescript.

In a lot of other communities they would've just evolved framework A, or C
would've pushed some patches back to B. Or D would've taken over for C and
there would've been a handoff.

It's effing ridiculous that if I go back to a 5 month old project I will spend
all damn day getting a build from source to work.

It's not just the libraries and packages. It's the toolchain, the build
pipeline (heaven forbid you look like a grandpa and still use Grunt!), the
transpilers. I love that people are creating cool shit all the time, but it
really seems like if the code didn't come from their team, they're going to
iterate the idea and put out a competing package instead of contributing back
to the original. And then we wind up with two unmaintained projects 6 months
later...

It really feels like there aren't many people (at least making headlines) that
have had to maintain an actual live production system for more than a year or
two. It'll be interesting to see what these people are doing 5 years down the
road...

------
irahul
The JS development landscape is in a state of flux, and it's overwhelming for
someone not familiar with it.

I was just working on getting a react-redux TODO template ready and number of
things I had to read up on was enormous. [https://github.com/rahulkmr/react-
redux-todo](https://github.com/rahulkmr/react-redux-todo)

I had to read up on react, then on redux, then on es2015/babel, then on
browsrify, then on gulp, then on eslint, then on sourcemaps, then on flow,
then on react-router...It was a lot of effort, but I am liking it so far. The
important thing is we can build applications in ES2015 which is a better
language than the browser's js implementation and still get to debug it on the
browser(sourcemap and specific devtools). My impressions of react-redux so far
is it makes implementing a TODO list harder, but it will be better suited for
applications with lot of state.

True there are conflicting choices and advice, but I think all this will
stabilize in a year or two and despite the naysayers, the future seems bright.
And it's not a take-it-or-leave-it deal - if you are happy with Backbone, keep
using it. You can choose to just integrate gulp,babel and browserify for
es2015 goodness. You might not like react but like how redux does state
management - just integrate that in your existing application.

Most of the tools are orthogonal to your framework choice. Use tern for
completion and analysis, use eslint for linting, use browerify/webpack to pack
your assets...

~~~
madeofpalk
Why have you added redux for such a small and simple project? What are you
getting from react-router-redux - why do you feel the need to sync the the
browser's URL into the data store?

You didn't 'have' to do any of these, especially for a project of this size. I
can now understand why people might feel fatigued when they needlessly create
overly complex solutions.

~~~
irahul
> You didn't 'have' to do any of these, especially for a project of this size

Where did I mention I had to do any of these for a project of this size(or any
size), and since when TODO list is a project?

The purpose of the template is to prepare a template(duh) and understand how
and where each library fits in.

------
marssaxman
This is interesting but good lord, I want nothing to do with any of this. How
are you supposed to get anything done if you have to spend so much time just
ramping up on whatever the new hotness happens to be?

~~~
madeofpalk
I don't really understand this. The height of confusion was at the beginning
of the article when the author's friend regretted using RequireJS

> We talked again last night, and he said that he’d chosen RequireJS. By now,
> his company had built a massive codebase around it –- “I guess we bet on the
> wrong horse there.”

What makes RequireJS the wrong horse? Is it not doing what it was originally
doing? Do you need more from it? How do you build 'a massive codebase' around
a module spec? I'm guessing here the person thinks Webpack is the right horse
- Webpack supports the AMD spec RequireJS uses if they felt the need to switch
(which I can't see why you would), which would minimise whatever changes
needed if you had the urge to 'churn'.

I think people need to stop getting so anxious about doing what all the 'cool
kids' are doing.

~~~
zeemonkee3
I've recently been looking at job boards, and "React" turns up a lot. As does
Angular, but not as much as a year or two ago.

So it's not so much about whether a given tech works for your project or not
(being honest, server-side rendering + dash of jQuery is probably more than
adequate for a lot of sites going full-on React+Redux right now) but fear of
your skills becoming obsolete. Given the shit-show hiring is right now with
its resume filtering and whiteboard hazing (witness every other week on HN)
that's not an unfounded fear. So in order to have something on our resume that
we used React in our last job, we use React for our current project...and so
contribute to the problem.

~~~
madeofpalk
If you see a lot of jobs requiring React, or are fear becoming obsolete, then
just learn React. It's very very simple - the API is like 5 functions, and the
documentation takes like 20 minutes to read from start-to-end.

Don't learn anything else - just learn plain vanilla-React. The site has a
onepager.html 'blueprint' to work from.

If people are getting anxious about this, its more than likely self-inflicted
from trying to learn 30 things at once that you don't need.

~~~
zeemonkee3
It's not just React, there's a huge ecosystem developing around it that is
undergoing constant churn - see react-router or babel for example. And then
with Redux you have a whole subsystem around that - redux-form and sagas and
react-redux-router (or is it react-router-redux?). Then we have the
GraphQL/Relay train leaving the station. Oh, and I've not even touched testing
tools yet, or webpack (a whole other ecosystem on its own). Or CSS modules
or...

But let's say I _did_ learn all that (in fact, I did recently for a personal
side project). It doesn't matter a bit for applying for a job. Why? Because I
don't have real work experience using these things. So in order to have that,
I have to somehow leverage React into my current job so it can go into my
resume.

~~~
nfriedly
> It doesn't matter a bit for applying for a job.

Sure it does! When I interview people, I tend to give a fair amount of weight
in their side projects, because it's something they were actually interested
in.

~~~
zeemonkee3
Maybe _you_ do - and if so, kudos.

But that's not standard industry practice. Nobody looks at your Github -
except maybe at the final stages of the process. In the meantime you have to
get through a lot of filters.

~~~
nfriedly
Well, maybe my viewpoint isn't the most common. But I can at least say that it
does matter to some companies / interviewers.

My resume has a link to my github and I specifically call out 3 or 4 projects.
If you want your side projects to count in an interview, that's probably a
good place to start - if nothing else, you can at least use them for buzzword
bingo to get past HR ;)

~~~
zeemonkee3
I do the same, but it's never made much of a difference, at least until later
in the game.

------
cognivore
What isn't being said, and is painfully obvious to me, is that almost
everything the article talks about wouldn't be happening if a. Browsers had a
decent UI capability, and b. Javascript wasn't a piece.

And to what end? What website have I gone to that just knocked my socks off
because they used framework X or library Y. None. And one year from now
they'll toss it out for whatever else catches their short attention spans.

So much wasted effort.

------
vmware505
I still dont understand this fatigue rant around JavaScript. Because I started
to work with Ember.js 4 years ago, and it is the solution for everything. The
framework evolved nicely and works perfectly. It was not a bet, it was serious
choice which based on a real perspective and concept.

Ember is matured and production ready for years now. You can focus on your
product. So, as an Emberjs dev never felt that problem than other js
developers. Dont experiment, start using the best tool out on the market... no
more crying only happiness. ;)

~~~
seanwilson
> I still dont understand this fatigue rant around JavaScript. Because I
> started to work with Ember.js 4 years ago, and it is the solution for
> everything. The framework evolved nicely and works perfectly. It was not a
> bet, it was serious choice which based on a real perspective and concept.

Yup, it doesn't make sense to keep chasing the perfect solution. Developers
wouldn't be suffering from fatigue if they focused on "done is better than
perfect".

~~~
BWStearns
Sure, if you're always in a position to pick your stack then just sticking
with your proven tech works. If you're working for other people with existing
code you might need to learn a whole new JS stack every time you switch
employers. Since you're already engaged in a Sisyphean cycle of learning new
ways to JS why not be on the lookout for perfect for when you do get to pick
your own?

------
copperx
I was taking a shower, and this question popped into my head: What is harder
to master nowadays? C++/STL/Boost or the Javascript ecosystem?

I don't know the answer.

~~~
nly
As a C++ developer completely ignorant of everything going on in webdev,
except that 'something.js is always the new hotness', neither do I.

I've basically ignored the boom in the web ecosystem for 10 years and have
even less interest in getting in to it than 10 years ago.

~~~
cgh
Hear, hear. I wrote gui applications fifteen+ years ago in MFC and the ATL.
Front-end programming was boring then and it's boring now. I can't believe
people are wasting so much time re-figuring this stuff out.

~~~
pcwalton
> Front-end programming was boring then and it's boring now.

Not if you care about performance (to name one tricky aspect). It's all too
easy to write a slow app.

~~~
gcb0
no it's not. it's very hard to write a slow application if you know the
minimum about how the browser/vm handles your data.

very few cases excluded (e.g. scrolling issues on Android of old) it's nothing
but a case of bad developers not having a clue. their code will be slow
regardless of the framework because they use the wrong data structure, or
render on the wrong step. simple as that.

then changing framework means dropping several features until they are ported,
which means less code, which means faster code... until all features are back
in. then, rinse, apply framework du jour, repeat.

------
golergka
Every time I think of Javascript language concept, I think about Lisp, and
every time I think of "javascript fatigue" I think of Lisp Curse.

I think that the core feature of JS and Lisp is the fact that there's no
concept of "compile time". Declaring classes, methods, even entire language
concepts like promises happens entirely in runtime, and the language is soft
to touch that every programmer with a healthy dose of curiosity and love for
his craft is trying to build his own OOP system on it at some time.

This softness allows for incredible freedom for a programmer, and incredible
speed of development of the language. But freedom is dangerous, both when you
work with code written by others (often idiots, either only in the eyes of
maintainer or completely objectively) and when you just support your own
codebase that you wrote several years prior. Would anyone expect anything else
from language with such capabilities?

~~~
lispm
> Lisp is the fact that there's no concept of "compile time".

The first Lisp compiler was finished in 1960.

Naturally Lisp has the idea of 'compile-time'.

> Declaring classes, methods, even entire language concepts like promises
> happens entirely in runtime

Let's see. I have a file with these contents:

    
    
        (defclass foo () (a b c))
    
        (defmethod bar ((a foo) (b foo))
          (+ (slot-value a 'a)
             (slot-value b 'b)))
    

Now let's use a Lisp compiler (!), here SBCL:

    
    
        $ sbcl
        This is SBCL , an implementation of ANSI Common Lisp.
        More information about SBCL is available at <http://www.sbcl.org/>.
    
        SBCL is free software, provided as is, with absolutely no warranty.
        It is mostly in the public domain; some portions are provided under
        BSD-style licenses.  See the CREDITS and COPYING files in the
        distribution for more information.
    

compiling the file:

    
    
        * (compile-file "compile-test.lisp")
    
        ; compiling file "compile-test.lisp" (written 16 MAR 2016 07:34:51 PM):
        ; compiling (DEFCLASS FOO ...)
        ; compiling (DEFMETHOD BAR ...)
    
        ; compile-test.fasl written
        ; compilation finished in 0:00:00.020
        #P"compile-test.fasl"
        NIL
        NIL
    

Wow, the sbcl Lisp compiler just compiled the file and generated the code for
a class and a method using that class.

Let's see if sbcl knows about the class:

    
    
        * (find-class 'foo)
    
        debugger invoked on a SIMPLE-ERROR:
          There is no class named COMMON-LISP-USER::FOO.
    
        Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
    
        restarts (invokable by number or by possibly-abbreviated name):
          0: [ABORT] Exit debugger, returning to top level.
    
        (SB-PCL::FIND-CLASS-FROM-CELL FOO NIL T)
        0] 0
    

Oh, it doesn't know about the class. We are no longer in 'compile time'. The
class was only known during 'compile time', a concept you said Lisp does not
have. sbcl seems to have it. Funky.

But we can load the generated machine code:

    
    
        * (load "compile-test")
        STYLE-WARNING: Implicitly creating new generic function COMMON-LISP-USER::BAR.
    
        T
        * (find-class 'foo)
    
        #<STANDARD-CLASS FOO>
        * 
    

Now it knows about the class.

> Would anyone expect anything else from language with such capabilities?

Lisp has a lot of code bases which are large and maintained for 2 or more
decades. Common Lisp has especially been designed to support compilation in
various forms and to support the development of complex/large systems. One
gets a lot of support from compilers like sbcl for doing so.

------
tkinom
I love to see someone summarize the most successful websites and the JS
stack/build tools they are based on.

stackoverflow : jquery + anything else? map.google.com : ? facebook : ? React
(?)

~~~
maze-le
see: [http://stackshare.io](http://stackshare.io).

------
julie1
well javascript is evolving at a fast pace.

Wheat still grow on a seasonal base. Tourism is still yearly based. A car will
last you years. telco CPE are lasting for years. Bank terminals are for years.
Robots in factories last decades. Peacemakers are intended to last ages. Users
do not really like to have their interface changed without any reasons to do
simple tasks.

Browser ecosystem is just running amok in terms of speed diversity and
complexity.

At the end, when we code it is for a business value. And for businesses web
technologies are mostly expenses that grows faster and increase faster than
economical growth. At one point this is condemning software business value in
times of recession when people need to cut on costs to survive.

JS fast pace == a lot of manpower to keep application just up to date. It is a
continuous growing bleed in the budget.

It is not the fatigue of the coder or sysadmins one should fear. But the
fatigue of the business customers bored to pay for diminishing returns.
Individual customers may still follow. But losing business customers will
happen first.

Plus like it or not, updating browsers is not always as easy as you think it
is. We all know of these legacy application that requires to keep a certain
browser, and of new application requiring different one and the complexity of
handling all these browsers. I used to have 6 browsers to code and test.

This is killing the business of coding and there is no "magic library" that
will change the seasonality of the activity and the need for companies to keep
their costs in control.

Industry out of IT requires for boring stable LTS technologies. The opposite
of the offer of modern IT.

When offer does not meet demands ... company fail.

If ever USA or Europa, India, China announce a recession in 2016 or 2017 there
will be blood in the IT.

It is all about costs and prices and making benefits at the end.

~~~
woah
When was the last time an existing application stopped working because of new
JS features?

~~~
z3t4
The problem now a days is phones. Their browsers work very different from
desktop browsers.

~~~
julie1
And set top box that may have another version of JS.

Or the "javascript" used in Qt ... or any new appliance/software that wants to
provide a common accessible language for their "events" and choose a JS that
is patched to support stuff like hardware functions.

I have been using these kinds of FrankeinJS in the past.

------
jondubois
Companies will never stop wanting better tools to build apps. The software
industry is highly competitive - If tools didn't keep improving, established
players (big companies) would have the upper hand. New tools allow
increasingly small startups to compete against big companies - Being able to
start fresh with the most cutting edge tools is a huge competitive advantage
for startups.

I don't think progress will stop at React. Soon enough, we will have drag-and-
drop web app builders - They will allow us to build web apps where all data
will be live-bound in realtime. Adding new pages/functionality will be
trivial.

Software developers won't stop until the tools become so convenient that they
take over our jobs completely - We will be replaced with app designers and
entrepreneurs.

~~~
tomc1985
Still waiting for that reality on the desktop side of things....

------
sdnguyen90
Curious questions for those who complain about Javascript fatigue:

What reasons are you're dropping your old libraries/frameworks in favor of the
new ones?

If an unstable API is a big problem for your use case, why not just stick with
the old library or just not update the dependencies?

~~~
manyxcxi
A big problem I have run into on projects that have gathered dust for a few
months has been when version wasn't pinned, or the package wasn't using
semver, or some other drift in the package.json that causes a slightly or
completely newer version to come down, which causes, a whole host of
dependencies to update and then boom- hopefully you have unit tests to catch
the breaking changes.

Also, when you check the project out and it was relying on global npm packages
to build and the system you're working on has been updated in the last few
months and now all of a sudden your grunt file doesn't run or your CSS
minimizer complains about your Ruby version. God forbid you build multiple JS
projects in one CI server!

------
sosuke
Since the huge influx of new JavaScript developers happened we've entered a
Wild West of development. Almost any combination of code is a great choice
right now. It will settle down but open source stacks last only as long as
their supporters. If you want to avoid all of the churn in JavaScript stacks
then just write straight JavaScript, ES5 or if you want to just support
bleeding edge browsers ES6. Then rely on a traditional backend framework with
full page reloads. It won't be bleeding edge but it won't fail anytime soon
either.

~~~
reitanqild
Or jQuery. That also has proved itself to be reliable.

~~~
davydka
Let the jQuery revival begin.

~~~
techdragon
I've been enjoying the post jQuery 2.0 revival for a while now.

------
aedron
> Coffeescript was the first major player, created by Jeremy Ashkenas in 2009.
> ... Google’s Inbox was built with GWT (Google Web Toolkit)

GWT came way before CoffeeScript, in 2006.

------
dclowd9901
I hate to sound curmudgeonly, but the reason the state of JS is always in flux
is because app developers suddenly decide they want to do front end
development, and they come in and say, "WTF, everything here is weird and
broken. I'm going to fix it. Make it more like
python/ruby/.NET/C++/LISP/Haskell/Objective-C".

So then some high brand developer heads up a project, it gets a lot of
attention because a big name company adopts it, and then we're off to the
races.

Before you know it, our simple little dynamic prototypal SCRIPTING language
has Classes and typing and build systems and cascading transpilers.

I'm not saying we should go back to the bad ol' days of writing kitchen sink
code for MVCs a billion times, but why do we need Typescript, Flow, Babel,
Dart, Coffeescript, and Clojurescript? Why?

------
Shicholas
This is why I use ember. It may not be the fastest or the greatest, but its
more than good enough (what I can build, stability, longevity etc.) and it's
opinionated to the point where I really don't have to think about all of these
pain points.

------
amelius
What I get most tired of is that all the tools nowadays seem to think they are
at the center of their ecosystem, instead of doing things in the old "UNIX"
style, where tools had clear I/O specs, and just worked well together.

------
bryanrasmussen
'Most of the tools we use today didn’t even really exist a year ago: React,
JSX, Flux, Redux, ES6, Babel, etc.'

ES6 is a new version of the language under discussion, Babel is a tool to
allow you to compile code written in the new version into the old version. The
other 4 examples are all closely related to each other, if you use JSX and
FLUX you use React, if you use Redux you probably use React.

In other words while I believe fatigue exists and is probably warranted, these
were bad examples of what would cause the fatigue.

~~~
bryanrasmussen
that said if anyone can explain to me the benefits of webpack in comparison to
my gulp.js build pipeline with real examples then it would be nice.

------
UweSchmidt
In my opinion the current abstractions that are used in web apps are not good
enough. Frameworks may be "elegant" in a certain sense but never get intuitive
enough for the average developer, and eventually the framework's author will
lose interest as well.

I predict eventually we'll come full circle and get something like ASP.NET
forms with Javascript controls that spans both frontend and backend.

~~~
Flow
And to get performance good enough we need support from the browser vendors. I
think Web Components and related tech might be it. It also offers isolation
for both CSS and frameworks. With it you could mix-and-match existing user
components easier than now. Many of todays framworks are "this is how the
whole app should work", impossible or at least hard and fragile to mix and
nest two frameworks with that attitude.

What do you think?

~~~
UweSchmidt
We also need support from the IDE vendors. Can I drag in the component from
the left hand toolbox in my GUI? Do I get at least some stubs for the
corresponding server side code? And common stuff like
authentification/authorization should really be rock-solid and built-in too.

------
LukeB_UK
You don't need to try and keep up with every new library/framework/tool. Use
what you want and pick new things up when you feel you want or need to.

Javascript fatigue is self inflicted.

~~~
lisivka
We need stable platform for JS, like Fedora/Debian/etc. does for C. I.e. make
snapshot of bunch of popular libraries with their dependencies, name that
snapshot, e.g. «Jasmin-1», then accept security and bug fixes only in forms of
patches to original source, like every distribution does. Call it "stable" and
stick to it for at least 6 months. Then spin another release, "Jasmin-2".

------
br3w5
"No other language does anything remotely resembling that kind of thing". Have
you ever worked on a Java EE project?

~~~
dham
I did JSF for 4 years, along with the rest of the Java EE stack. Glassfish web
server. There was never churn like this . I was pretty enthusiastic about
front end dev for years. I'm pretty burnt on it now though.

~~~
br3w5
I didn't mean the churn (Java EE could do with more churn) I meant in terms of
setting up a project and the number of dependencies.

------
edtechdev
The language itself is what is simultaneously causing this craziness and
holding back real change. Half of the stuff out there is working around
JavaScript's limitations. If a bytecode had been approved 15 years ago instead
of blocked by JavaScript's own creator, we would be much better off today.
WebAssembly is finally, finally a step in the right direction, but it's not a
bytecode, either.

------
mixedCase
Site seems to be down for me.

~~~
foobarbecue
Perhaps the server experienced javascript fatigue and quit.

~~~
i_feel_great
They are swapping JS frameworks.

------
afrancisboeuf
really interesting article!

