
Generation JavaScript - logician_insa
http://manuel.bernhardt.io/2014/12/30/generation-javascript/
======
drderidder
What is happening with the web stack now is a sort of renaissance with an
unprecedented pace of activity. It's easy to feel overwhelmed, which is why I
started a local meetup group that has now grown to 800+ members, all wondering
the same thing: where do we start and what is worth investing our time in?
Through conversations and presentations we learn what has worked well for
others. Gradually, I expect the "storm, norm, perform" cycle to work its way
out in the JavaScript community as consensus starts to build around which
tools and frameworks are best. That is already happening to some extent. I
don't think bemoaning the state of rapid innovation in the web stack is
terribly useful; rather we need experienced developers (unbiased ones,
preferably) to curate their collection of JS tools and resources and publish
it for the benefit of others. One of the talks I've been wanting to give for a
while is simply a "3000 ft survey of the JS landscape" or similar - mapping
out the territory in terms of client-side MVC, server side JS, build tools,
static code analyzers and tracers, libraries, etc. (If anybody knows of
existing efforts to curate such a list, I'd love to know about them)...

~~~
napoleond
Exactly. "Oh no! Too many people are publishing their code! Developers have
too many excellent options (along with many awful ones)!"

It's true that our community could use a renewed focus around best practices,
and it's true that the stack itself is way more complicated than it needs to
be. In that sense, I don't disagree with the point of this article at all, but
it's important to remember that when things grow organically they will tend to
get messy, and the alternative (somehow structured growth, governing bodies,
etc) is far worse.

~~~
coldtea
> _Exactly. "Oh no! Too many people are publishing their code! Developers have
> too many excellent options (along with many awful ones)!"_

I fail to see the "many excellent options". Awful ones are, on the other hand,
abundant.

And even those that are decent have the other issues the article mentions:
they are short-lived, with developers soon moving to the next shiny thing etc.

------
markbnj
I don't think this is about javascript, any more than Kamp's article was about
C, or any other specific language. It's about the culture of speed, and the
whole notion that getting something working as fast as possible is the primary
virtue to be encouraged. I see this viewpoint engrained in lots of the younger
developers I work with today, but I don't think it's their fault, and I don't
think it is something whose DNA we can trace back to the dot-com bubble. It's
been going on longer than that.

Some of you may be old enough to remember the days when managers attempted to
measure our output with KLOC/day metrics. That goes back at least to the early
90's and maybe the late 80's. I believe the reasons for this are more
fundamental than these articles hint at.

The problem arises, imo, when you have management in a position of relying
totally on people whose work they don't understand at all. They are educated
to manage risk, and yet they are paying us large amounts of money to
essentially function as a black box, out of which comes something that works
and makes them heroes, or doesn't and loses them their jobs, and they have few
ways of measuring which way the battle is going.

The response is to try to manage ever more closely, treating the process as
one of production: X number of people sitting at their computers working hard
will produce Y amount of software. Those are the kinds of processes they are
trained to deal with in the management schools. They aren't trained to manage
inherently risky processes of creation, rather than production. The word
"craftsmanship" as used in the linked article is exactly right, but
"craftsmen" don't fit into the modern world of value production and they never
have.

~~~
diydsp
You're right, but most replies to you have overlooked the customer:

Customers, _paying_ customers, are accepting Javascript apps. Java was never
good enough for that to happen except internal to large organizations where
aesthetics and user experience didn't matter.

There may be a zillion crappy, similar overlapping Javascript libraries - and
to my background it seems like a massive waste of time - but the fact remains
that people, everyday people like my mom, sister, uncle and aunt are all
spending real money for services accessed through Javascript. It is good
enough.

Should I tell them: "You know that website you like so much, e.g. reddit- it
would be so much better if it was a native app on your PC written in C++, so,
like, don't use it. Demand and wait for someone to re-write it in a proper
language with libraries that have a proper pedigree. Then you can run it on a
300 MHz computer instead of 3 GHz."

That'll never work! The javascript/PHP/whatever else stack that implements
reddit is absolutely adequate for them to browse cat pictures and interact
with their magic tricks communities.

Now, diehards like me cringe because of the waste of CPU, but guess what - CPU
power is no longer a scarcity. There are only philosophical and environmental
reasons to wring our arms about using less CPU power. And possibly these
concerns are non-sensical. Are we wasting the world's resources making fast
CPUs so people can use inefficient sw libraries? Who knows. But either way,
the point remains:

Javascript's customers and users, and the services they demand and pay real
money for all support Javascript and nothing other than a fanatic religion
will convince them to change their ways.

It makes me mental, but I've even been learning Javascript over the last few
years. It's about the same speed (and variable scope) as the BASIC I used on
the Apple 2 in 1984, but so what, I'm paying the rent with it.

~~~
TheOtherHobbes
Customers are accepting _web_ apps. They don't care if the apps are written in
Flash, js, BrainFuck, Haskell, or morse code converted into asm.js via a
transcompiler written in APL.

But development is not a democracy, and the fact that n thousand projects use
a certain stack doesn't mean the stack is fit for purpose.

Take the security horror that is Wordpress. It's popular because it's easy to
use, but from a professional point of view it's an infosec plague and server
killer.

The quibbles about js have nothing to do with its popularity. They're more
about the overall lack of professionalism in software development.

The underlying issue is scope. We don't have a cathedral, or a bazaar. What we
have is exactly one (1) planetary network, made of a loose affiliation of
barely cooperating nodes and applications.

The original Internet infrastructure worked because the RFC process meant that
the core features were designed and refined by peers. Hobby coding in the
bazaar removes all elements of peer review.

But the alternative isn't a UNIX-style cathedral, it's a revised set of
standards leading - eventually, I guess - to a planet-scale operating system
and shared library framework that takes away all the cruft by making it
unnecessary.

None of the current stacks are the right way to make that happen.

So the issue isn't js - it's more that web stacks have become de facto
operating systems for industrial computing projects without any of the rigour,
peer review, or oversight of a well-designed industrial gold standard OS.

And it seems that no one - or at least no one that Tim O'Reilly's authors talk
to - is even thinking about how to create an OS of that quality.

------
danbruc
JavaScript is an awful language, no matter how much some people stress that
you can build working things if you are just careful enough and all that. But
that is only the beginning, the entire stack is more less broken. HTML and CSS
got repurposed from document markup languages to GUI markup languages. We
allowed this awful language to escape the browser and infiltrate our servers
in form of Node.js. Microsoft also came up with the clever idea to develop
desktop applications and apps with JavaScript, HTML and CSS.

And even the largest selling point of the entire stack - develop once, run
everywhere - is far less true then many like to admit. In the past a
substantial part of development time has been spent on getting the thing to
run consistently across browsers but I fear we are far from the end of the
road. Now we have more or less consistent behavior across browser for all the
basic things but you still regularly run into unusable web application because
you happen to have an unexpected screen aspect ratio, an unsupported video
codec or missing WebGL support.

Unfortunately I have no good suggestion how to escape from that situation
(quickly) but it seems pretty obvious to me that we have a lot of problems to
solve.

~~~
andrewstuart2
As engineers, we should recognize very clearly that JavaScript is just another
tool that has trade-offs as everything does. We build applications optimized
for their use case. Does the bridge over the meandering creek need to be made
a suspension bridge of concrete and steel? Of course not!

Time is the true currency of this universe, so we optimize for efficiency as
best as we can without knowing the future.

~~~
astrobe_
> Does the bridge over the meandering creek need to be made a suspension
> bridge of concrete and steel

The problem being discussed here is more along the line of building the Golden
Gate with wood and plaster.

------
bhouston
The proliferation of JavaScript libraries is sort of like what happened when
Amazon.com came online and you now could choose from +1M books instead of the
10K that were available at your local non-big-box bookstore.

No longer are you dealing with a scarcity situation, where the bookstore was
your filter, but an overload situation where you could access everything as
easily as a click. Amazon dealt with this by allowing for ratings (one to five
stars), reviews and ratings of reviews. It also tracked what books people
bought in the end. I think this can be applied to NPM and other non-JavaScript
package managers.

We have much the data in Github and NPM to do this, with the exception of
proper ratings (stars are not that informative, as they are only positive) and
proper written reviews.

I'll be honest, there is a real space to move in this direction towards
collaborative filtering of packages based on both implicit and explicit
signals.

~~~
htor
I don't see how rating libraries and frameworks would work. You use a library,
depending on if it solves your problem or not. Some libraries solves your
problem but might not solve others. And that's fine. That's why there are
multiple libraries in the first place. For instance, saying some library is
less useful than another on Github because it enforces a functional style of
programming, is not very useful for others that might like the functional
style. Remember, these things are not books, but tools.

~~~
bhouston
Remember that not all books are novels, many are informative books people read
to solve their issues or learn specific things -- many non-fiction books are
essentially tools.

------
jfaucett
I disagree with almost every word in this essay. So lets get started.

"Imagine you are a newcomer to Javascript development these days. Which
librairies should you pick to get started?"

Who cares. What's stopping anyone from just writing a JS file and adding a
script tag to their html, that's how most of us learned it.

"There is, however, a price to pay to the approach of coding through instant
gratification."

No there's not. It just depends on what type of coder you are. I like to think
a problem through BEFORE coding and then hack, when I come to another problem
I pause, think, solve the problem, (all away from the computer) then want to
code super fast again. Anything that makes the "turn my idea/algorithm" into
running code faster is good, when writing C/C++ anyone will tell you they hate
compiling, why? because its slows down the "idea-to-code" part. To the authors
credit he seems to prefer this approach as well, it just doesn't follow that
you have to hack super fast all the time and never think just because you
don't have to wait for code to compile.

"The hardest thing in Javascript development today is maybe less the
development itself than knowing which libraries to pick."

That's a problem? Seriously, I think many languages would love to be able to
"complain" about this.

"It is Torvald’s “Release early and often” without the community smashing the
ego of anyone publishing sub-par code."

Here's the way I think about it. If you can't find what you want, build it
yourself, maintain it, and use it. Everyone does this in any other language
and it works fine, its also working for JS too. see here:
[https://github.com/sorrycc/awesome-
javascript](https://github.com/sorrycc/awesome-javascript)

The only thing I would agree with is that yes, it is ridiculously easy to
publish something to npm so there is a lot of garbage. The days of submitting
your email patch are winding to a close and I for one am happy about it.

~~~
logicalmind
I think your comment and perspective hit the heart of the matter. You view
your work in isolation. And if you're not working in isolation, you are
assuming that your co-workers are in the 99th percentile of coders. If you're
making some small webapp or mobile app, then that mentality is fine.

But think about it from a different perspective. Let's imagine you are hired
by a company to come in and build a large, web-based, responsive, buzzword,
buzzword application for them. It's big enough that it is going to take months
to develop and require numerous developers. The strategy of "just writing a JS
file and adding a script tag to their html, that's how most of us learned it."
is not gonna fly. And if you are spending your time doing "If you can't find
what you want, build it yourself, maintain it, and use it" then how are you
getting your actual application done? You don't want your devs spending a
month of time to build (and then support) some templating library or some such
when your real task is to write some kind of CRM application. So how do you go
about picking technologies, training teams, building upon existing libraries,
etc. in order to build your actual product?

------
skrebbel
It's just a cycle. Every community goes from overdesigned to overhacked and
back, like a pendulum. 10 years ago we were all building large fancy over-
architected apps with frameworks like Spring and JSP and Makumba, now we're
hacking stuff together on Node with 2-day-old NPM packages.

In a parallel universe, the Ruby people did it the same, but the other way
around, started with hacking stuff together with as much automagic stuff as
possible, and now they're writing blog posts about Dependency Injection.

Admittedly, it's not a perfect sine, but give it another year or 3 and the
JavaScript people will have settled on one of the four package managers, and
the most-used frameworks will be well-maintained and strike a healthy balance
between hackiness and enterpriseyness. Sure, any popular language will have
incompetent people and they won't suddenly delete their GitHub accounts, but
in my opinion, we're not _that_ far away from there. Modern JavaScript tools
like React or Webpack really have that craftsmanship you write about. In a
way, you could argue that Angular v1 had _too much_ of it.

It appears to me that this cycle happens in each language ecosystem, but with
a different phase and starting in a different direction. I tend to prefer
programming languages that used to be quite hacky and _just_ started to
discover that, well, yeah, oh, there's something good to say about all that
architecture stuff those old people kept rambling about. IMO, JavaScript is
there right now and moving in the right direction. Elixir is taking off in the
same direction (fueled by hundreds of disgruntled ex-Rubyists), Java is
currently descending back towards more hackiness (fueled by gazillions of
Android programmers who fead a tutorial).

I'm still not sure where to put the PHP guys here but hey, at least they have
a working package manager these days (and not four).

------
ryandvm
JavaScript is like working on an old Jeep.

It's not very clean; it's not very efficient; you're dealing with weird
nonsensical issues all the time; there's a good chance you will cut off your
fingers or mash your knuckles.

But... it's incredibly common, there are a ton of writeups on whatever you're
trying to do, and the barrier to entry for getting something done is so damn
low that for better or worse, it's not going anywhere soon.

The only thing that's going to rescue us from JavaScript is when every browser
ships with a common language-agnostic runtime (a la CLR, JVM). The JavaScript-
as-a-Transpiler-Target movement has the right idea and a little bit of
momentum, but I think the potential obsolescence, the hassle involved in setup
and debugging, and the perceived inefficiency scare most developers away.

Imagine if you could code your web app in whatever language you wanted because
they all compiled down to the same VM bytecode...

~~~
eterm
A CLR doesn't solve much I think, if you look at .Net there's a single de-
facto language (C#) and VB.NET died out just because people will gravitate
toward the language which has all the help, stackoverflow answers, etc.

Sure, it makes using other languages _possible_ , but typically that'll just
be seen as weird.

~~~
raziel2p
You can't really compare the two situations (.NET and a hypothetical browser
bytecode/VM). The reason C# ended up the main .NET language is that it's a
brilliantly designed language - far more than you can say about Javascript.

~~~
ufo
I don't think its just that. Its impossible to design a "trully general"
intermediate programming language so what ended up happening is that the CLR
was a perfect fit for C# and a not-so-perfect fit for everything else. At
least thats what I've been told by my programming languages professor.

------
morganherlocker
This reads a bit like early internet critics complaining about how there are
too many voices online. "Why isn't the Times enough for everyone? Why do these
bloggers need to be telling everyone what they think? Some of them don't even
check their facts!"

> It is Torvald’s “Release early and often” without the community smashing the
> ego of anyone publishing sub-par code.

The relative lack of Torvalds-esque public shaming is exactly what I love
about the Javascript community. There is an acknowledgment that we can all do
things our own way, and that it's OK. We don't need a dictator shouting down
people "doing it wrong".

~~~
HCIdivision17
And it's such a different set of goals. You're unlikely to break something
fundamental with Javascript, which is _fantastic_. It's a safer thing to play
with than a kernel. Put sub-par code in the Linux kernel, and _your computer
doesn 't boot_. Mess up your JS and your webpage renders off-center. The
severity of failure is so different that it'd be silly to get bent out of
shape over it.

Of course, you can do insane things in JS, but that's part of the fun. Even at
its worst, it'll crash a program or browser tab that can just be reloaded.
Annoying and inconvenient, but the computer's still chugging and no harm's
done.

~~~
danbruc
The worst case is not an off-center web page, the worst case is exposing user
information or making your backend attackable in other ways. Just because you
use JavaScript and it runs on a client machine far away you are not magically
protected from screwing up.

~~~
HCIdivision17
Sure. Yes, security is hard. You got me there. Javascript does not decrease
your attack surface, and is not, in fact, magic.

That's not a free-pass negation of my point that crashing a browser tab is
_substantially_ less severe than a kernel panic, and thus likewise greater
engineering due diligence is needed for its code. There's nothing magical
about it.

------
blixt
The solution the article is proposing isn't realistic. You can't reach
anything resembling "craftmanship" without a lot of failed projects preceding
it. Craftmanship or quality is not a binary state, it evolves organically. A
lot of projects are shit, and then there's a few golden nuggets that
outcompete the shit. This applies to life in general and also local fields,
like programming.

JavaScript has turned out to be one of the most versatile programming
environments for this "evolution" to happen. Yes there's a thousand ways of
doing things, and maybe only 10 of them are good, and maybe those are
difficult to find. But the solution isn't to shut down the shit so that there
are only 10 things created instead of 1000. That's just stunting growth, and
instead of 10 great things you might just end up with 1 because there was no
creative competition (or at least inspiration) in the environment.

So to hell with this thinking, you can't expect to be able to control and lock
down a vibrant creative environment and expect the same amount of golden
nuggets to come out of it.

I've been writing JavaScript code for 15 years now and the things people are
making with it are greater than ever, and many of those things have been
reborn out of great ideas implemented poorly. With some kind of "craftmanship"
standard, those poor implementations would never have come to exist, and there
would be less great ideas in the world.

For the sake of being a bit more constructive in my own rant, I think our
efforts should be put into guiding people and helping them find the golden
nuggets. And this is happening. There's a lot of tutorials out there. Granted,
even the tutorials suffer from the same shit:golden ratio, but finding the
golden nuggets is what communities are for.

~~~
coldtea
>* The solution the article is proposing isn't realistic. You can't reach
anything resembling "craftmanship" without a lot of failed projects preceding
it.*

And yet older generations of programming seem to have managed it.

> _Craftmanship or quality is not a binary state, it evolves organically_

I don't thing code grows into craftmanship, much less organically -- either
you have craftmanship as an attitude from the beginning of writing something
or not.

~~~
blixt
I believe the only reason you think that previous generations managed it is
because previous generations of programming were tremendously less open in
terms of visibility. I would even go as far as to say that if you could
collect and objectively grade all code in the world 10 years ago and today,
the collective code today might actually be of higher quality, simply because
code is shared much more today. This leads to more knowledge, which leads to
higher quality. In the past, that code was simply left behind on someone's
hard drive.

Code itself doesn't grow into craftmanship, because craftmanship is what a
person does. A person gets better with experience (both from doing and from
observing) and inspiration. Greater visibility and sharing of code means
better experience (through observation) and better inspiration (from people
sharing their great ideas).

If you think I'm wrong, the alternative solution isn't difficult: you can
avoid shared code repositories altogether and instead write more code from
scratch. If you still want code sharing, you can start your own online
repository where only thoroughly vetted code is allowed in. The important
value to me is that people are not encouraged to censor themselves, but that
we push ourselves harder to increase quality, by sharing both our knowledge
and our work even more. If navigation is an issue, we need to build better
tools.

Multiple choices, competition, and organic growth is healthy for the system –
enforcing artificial limits believing it'll increase quality is not.

------
xasos
>We are now in another period with great opportunity for people in the IT
industry, and we want to have as many people as possible join the party!
Everyone should code. And we have made it so easy! Create a GitHub account,
watch some of the many, many tutorials out there, and get going! Yay!

>The sad truth is that something essential gets lost in all of this everyone-
can-do-it-yay-lets-all-code euphory. I’m not exactly sure how to call it, so
I’m going to pick something that is close enough to describe what I mean. I’m
talking about craftsmanship.

Just because many newer developer's code is public on GitHub, it doesn't
necessarily mean code quality is going down. Back five years ago, when many
developer's code was stored on their machine, there was no way of knowing if
their code was any good.

Now, developers are encouraged to show off what they have, because Git shows
how you've progressed as a developer. It also allows for developers to help
each other and make each other's code better. I know collaborating on GitHub
has helped my code quality go up.

~~~
drderidder
Exactly. Is there value in learning to code? Of course. Does learning to code
mean you will be able to write quality software? Unfortunately no. Especially
if you learned to code in a sort of crash course on web application
development. To be honest I've forgotten 90% of what I learned in engineering
school, but I feel the triple-variable calculus, statistics, circuit design
and assembly language driver hacking somehow prepared me for solving rather
tough and unfamiliar problems in the real world.

It's like music lessons - very beneficial in all kinds of tangential ways
although very few students will become concert pianists.

~~~
dasil003
Or to put it another way: you can't become a good programmer without first
being a bad programmer.

------
colinramsay
I don't see what the problem is here. Angular isn't going away - I daresay the
1.x will be maintained. EmberJS looks rock solid. Backbone hasn't suddenly
become useless just because React is around.

A proliferation of projects is an indication of an exciting and experimental
community. If you run off half-cocked and take on an unproven and unmaintained
library and build an application on sand then the fault lies with you, not the
ecosystem.

~~~
emodendroket
> If you run off half-cocked and take on an unproven and unmaintained library
> and build an application on sand then the fault lies with you, not the
> ecosystem.

The entire contention is that it's difficult to tell which ones are going to
become unmaintained because of the amount of churn.

~~~
colinramsay
For which the writer makes an entirely unconvincing argument.

------
richmarr
> we need to do something

Do something about what?

Lots of discarded projects on Github? Too many people working with Javascript?
Fast iteration? Lowering barriers to entry?

Those all sound like good (or at least neutral) things to me. I've clearly
missed the point of this post.

~~~
logicalmind
In my simplified view, I think we need to do something about the fact that you
cannot build an application today that will not be obsolete in 6 months (at
best). And by obsolete, we're not talking about obsolete like a COBOL
application. We're talking about relying entirely on frameworks/libraries that
may literally no longer exist. Think about an angular 1.x application 5 years
from now.

If you're building an application that will take a non-trivial amount of time
to build and will have a lifetime of years, what technologies would you pick?
How do you train your team members? What is your strategy for maintaining it
into the future?

If someone built a webapp 10 years ago, it would be php, rails, asp.net, java,
etc. And you can find someone who would (possibly reluctantly) get in there
and do something with it. But what about the app built using 20 npm libs. What
do they do in 10 years?

~~~
twerquie
> What do they do in 10 years?

Where is this mystical app that gets sudden developer attention after 10 years
of maintenance-free use? I've never come across a 10 year old application that
hasn't been actively maintained that didn't need at least parts rewritten.

------
pierotofy
The article boils down to: "I don't like Javascript".

Although it's not a great language by design, I think there's a reason why it
has reached wide adoption. And don't tell me it's because there are no
alternatives.

~~~
ZenoArrow
"And don't tell me it's because there are no alternatives." Then I don't know
what to tell you. Why do you dismiss this as a reason?

~~~
drderidder
There were a few alternatives on the client side. Not many, but they do exist:
Java was supposed to be the alternative for building web based applications,
but Applets didn't gain wide adoption. Flash did better but eventually became
unnecessary as the web stack itself got good enough to build things like
Google Docs, Processing.JS and such. Then there are the "transpilers" like GWT
and the various *script dialects that compile to HTML/JS/CSS. On the server
side there are tons of alternatives, of course. Even things like Virtx.io that
has bindings to a number of languages including JS.

Those are some of the alternatives - at the end of the day most people seem to
prefer going back to straight HTML/CSS/JS to build things. They're not perfect
but they're pretty easy to learn, they separate the concerns of content,
presentation and logic, and they work everywhere (sometimes with a little help
from jquery or modernizr).

~~~
ZenoArrow
From a user standpoint, anything that relies on plugins to work is suboptimal,
so that rules out Java applets and Flash.

Transpilers are reasonably popular, but they're band-aids over the real
issues, and are susceptible to inherit the problems that the shaky foundation
lies out, and the mechanisms for library interoperability are not always
stable. These problems also persist in the ever evolving landscape of JS
frameworks, which are symptoms of the limitations of JS.

The other side of it is about what works in the commercial landscape. Building
around an uncommon tech stack is a risk when it comes to hiring. The
widespread nature of JS is part of what keeps it popular, but that's not
necessarily based on merit.

------
serve_yay
This says something important that I've been thinking for a while, though I
couldn't conjure the words as well myself.

> _The sad truth is that something essential gets lost in all of this
> everyone-can-do-it-yay-lets-all-code euphory._

This attitude has been wearing on me as well. Although we shouldn't self-
aggrandize, it's hard to do this work well, and so many don't do it well. And
I realize that yay-everyone-can-do-it is a correction to the insularity and
shitty forms of exclusivity that developed in some areas of software
development, but it's sadly not the whole truth.

And you can't really say this without being a "hater" and so forth,
_especially_ in the Javascript community. They're very self-congratulatory
about their community's ethic of acceptance, which is of course a wonderful
thing. But there is no space to offer a viewpoint counter to this or to say
"yeah but...". I suppose this will change in time.

------
fidotron
> and fueling and attitude wherein the well-being of the developers of a tool,
> not the one of the users, is most important.

This x 100000

This is why I hate package managers in a nutshell. The reason is that it
reduces the friction for developers of packages to issue updates to a critical
level where they turn round and blame package consumers for not using the
latest versions while the consumers spend their lives battling with the ever
changing bugs and APIs of the packages.

This isn't just an open source problem, as I first ran into it in a company
that made many of the mistakes a decade ago that the open source community is
just making today. Lots of really nice sounding ideas that increase the
productivity of a few individuals working on inner level packages at the
expense of the whole organisation.

~~~
dasil003
I think this is a very specious connection. I've been using Rails since 2005
and so I got a good dose of vendor/plugins versus bare gem installation versus
Bundler (ie. steadily moving up the continuum of package management), and my
observation is that library quality and maintenance is utterly orthogonal to
package management capabilities. The package manager itself has only helped my
life as a developer, the tricky part is picking trustworthy dependencies.

------
flohofwoe
It's not like things have been better in the 90's, when everything was about
Visual Basic, COM, OLE, CORBA and 're-using' application components. I'm not a
big fan of JS, but the whole JS+browser+node.js infrastructure is a million
times better then this whole VB+COM bullshit. Even the Darwinian framework
situation in the Javascript world is much better then getting a incredibly
complicated, over-engineered, designed-by-committee system like COM rammed
down your throat. Don't like a particular JS framework? Pick a different one.

~~~
danbruc
But why should we judge the web stack by comparing it to the worst examples of
the past? We should really compare it with the best options available today.

~~~
flohofwoe
Sure, but the good thing today is that the 'best option' isn't dictated from
an elite that 'knows better', and 'best' isn't a question of money anymore,
but strictly quality (with 'quality' not meaning particularly well designed,
but solving a specific problem well). A side effect of this 'freedom of
choice' is that 99,9% of available options don't solve a problem for me, and
it's harder to choose the right option, but I'm completely fine with this.
People just need to stop treating programming languages and framework as
silver bullets.

------
blktiger
The writer commented on how some of his best code was written away from the
computer and how all of this fast reloading causes poor code to be written.
I'm not sure if he would disagree with me, but I think a lot of it depends on
the kind of person you are and the kind of problem you are solving. Some
problems can't really be solved well iteratively (voice-recognition and DSP
for example), while others can. Similarly some people work better iteratively
while others do not.

I think it's similar to writing an essay in some ways. Some people sit down
and think for a while, then write the essay in one sitting. They then make
some minor grammar corrections and otherwise polish the essay before
submitting it. Others (like me), sit down and write whatever comes to mind.
Then they rewrite everything, and then they rewrite everything again, etc.
Finally they have an essay that they are happy with, make some small polishing
changes and submit it.

In the end, both approaches work fine for writing an essay, just like both
approaches work fine for writing code. The key, when talking about speed and
iterative development, is that the code isn't finished when you have something
that appears to work. You have to go back through and rewrite things,
refactor, add additional tests and clean the code up.

------
je42
Where is the issue ? When in inspect a library;

\- I can see the number of downloads on the npm website and so on.

\- I can see the issues and pull requests on github

\- I can do a git clone + npm test to see if the tests still run or even
better see the travis batch that is in the readme.

I prefer a vibrant community and lots of libraries over a slow and "solid"
library development community.

In the end - I need to write code any way to fix any of the libraries
issues... With lots of libraries, at least I have the chance that somebody
already forked the library and fixed my problem.

Otherwise, I ll fork the lib - fix the issue and use the fork myself and send
a pull request to the original lib. Once the pull request is accepted - i can
just point my dependencies again at the original lib.

Perfect isn't it ? I fix the problem for myself and the community gets a fix
back to the original lib almost for free.

So yes, there is garbage out there, but I feel I have a lot of tools to
"smell" it and stay away of these before investing too much time.

------
k__
I think this is better than the "Generation PHP" we had before.

Both languages aren't sexy at all.

But JS is more versatile. Runtimes are available (and preinstalled) on many
servers AND clients. And it's OO and FP seems to be more flexible to me. I get
a more smalltalk-feeling from using JS than I got from PHP back in the days.

------
Fannon
I can see the problems of the current situation, too. I guess everyone
involved does. But what's a viable alternative?

I have seen a few project that were completely build on its own, without
dependencies on external libraries. Not only that those projects turn out to
be even less modular (because it's not enforced by a package manager / module
system), but the chances that code gets unmaintained are also rather high,
since developer time is often rare.

An interesting point is releasing the software. No problem with putting it on
GitHub, but if projects are commited to official registries like NPM or Bower,
the author should really put some commitment into it. Currently it gets ever
more complicated to find good quality libraries, becoming a needle in haystack
problem. So a "release ethic" wouldn't be too bad.

------
mgr86
Here is my dilemma as I consider if I should double down on JavaScript and
adopt it on the severside. Is there an alternative for the web? and publishing
as a whole?

We are a small shop. Two people and hope to grow. We publish a web database.
Our market is academics, libraries, and scholars. Our Data must be kept in
XML. It just makes the most senese.

But we are spread over a half dozen different languages. Halfway proficient at
all of them, but as we move around to a new project and set one language aside
to pick up the other we regress. What we had known must be relearned, the way
we were thinking must be retrained.

If we created our web services, our internal API's, our production system all
largely in the same language we should, I think, we come more proficient and
quicker in this language. At the end of the day we need a well functioning,
_modern_ web application. So I have no alternative but to be very current in
javascript it feels.

Might as well set aside our old Java 5 app. Might as well not create a new
python project as fun as it is for me when I am the only one that can
understand the python. Might as well stop pouring all my efforts into a silo.
Why note double down on javascript.

A key source of inspiration for this line of thinking is from a conference
presentation I saw given from some at O'riely. They were experimenting with
their upstream source of their products being HTML5. The HTMLBook[1] project
seems to logical enough. Their output is almost exclusively HTML. Be it on the
web, the ereader (epub/mobi) or with the PDF. They were using Attenahouse to
convert HTML to PDF using CSS.

Why mess around with several different languages. Keep it simple, and produces
nice things quickly. If they aren't as nice as you hope refactor. With not
having to retrain parts of your brain for javascript as you were working on a
Python project exclusively for the last month and a half we should be that
much quicker.

[1][https://github.com/oreillymedia/HTMLBook](https://github.com/oreillymedia/HTMLBook)

------
logn
I don't think this problem involves programmers at all except in their initial
decision to use JavaScript. And those decisions would need to be examined on a
case-by-case basis, not as a generational critique.

Companies need to team up to put resources behind projects they like and
organize their efforts in a sustainable way. One effort that's proven
effective has been Apache: [http://www.apache.org/foundation/how-it-
works.html](http://www.apache.org/foundation/how-it-works.html)

Their foundation ensures projects have a good mix of contributors and aren't
driven by the whim of a sole corporation or a few hobbyists who would never be
replaced when they leave a project.

------
robertwalsh0
"Oh but if we can only stop the dirty unwashed masses from sullying our
pristine discipline..."

Said any group that has implemented certifications to make entry into their
discipline more difficult to newcomers. "Craftsmanship certification" is
something I wouldn't be shocked to see becoming a business in the next 10
years.

------
mavdi
Speed of innovation seems to be bothering the author... really not the right
industry for him to be in.

------
voidr
I had the chance to debug a NodeJS application that was based on a framework
which had a lot of low quality dependencies which had a lot of low quality
dependencies of their own... Long story short it was anything but fun. I think
the NodeJS ecosystem needs a quality bar.

------
Kiro
Well, I was just about to publish my first library to npm but just changed my
mind. I have enough performance anxiety as it is and when I know people think
I'm destroying the scene with my "sub-par code" I definitely won't publish.

~~~
HCIdivision17
Publish it anyway!

There's a worst case of no-one noticing, which will hopefully be a great
relief for the anxiety (and yet you can say you published your code), and a
next worst case that it's never used and is simply inspiration for a better
library! Of course best case is people use your code, modify, expand, and
build upon it. You'll be credited in their libraries as part of their
inspiration, and the state of the art moves forward.

There are many that want deeper curation on quality; it's hard to deal with
all the noise out there. But it's critical to remember that we can always
layer curation _on top_ of the bazaar at no additional cost. As the scene
settles into its grooves, the better curators will stand out.

------
mackraken
I don't really follow the current thread this article seems to. It just sounds
like the cool CS kids lamenting how the web used to be cool. The masses have
discovered it and are contributing to it now. Wasn't that kinda the goal?

------
benaston
Wow, this thread is a tough read for someone who ranks JavaScript as the best
high-level language in common-use today.

Haters gonna hate!

------
woah
Solution: Think for yourself

------
jokoon
andy berhardt (not related) gives the best arguments against javascript. the
fact that there's no integer is really crazy to me.

------
xeLL
Jeff Atwood stated in 2007 that any application that can be written in
JavaScript will eventually be written in JavaScrip. Thats what we have today.

~~~
emodendroket
That doesn't really address the point of this blog post at all.

