
Modern JavaScript for Ancient Web Developers - rmason
https://trackchanges.postlight.com/modern-javascript-for-ancient-web-developers-58e7cae050f9#.2tpky4xfc
======
tedunangst
> If you don’t have a human expert at hand, at the very least, check the date
> on that Medium article or tutorial or the last commit in that GitHub
> repository. If it’s more than a year old, it’s almost certainly not the way
> to go.

The logical conclusion then is to wait a year and ignore everything this
article says. Saves a lot of time. :)

~~~
gbuk2013
I'm still using Make for all my minification / bundling / test running needs.
Now and again I think to learn some trendy tech then never get round to it.
Next time I remember it's already something different. :)

~~~
noir_lord
Same with me except I'm using bash and the CLI to all the modern tools.

In 6 months I'll still remember how bash works and I get super simple
debugging since I can just echo out the command it was about to run and start
poking.

I'm still not sure why the JS community seems determined to slowly bootstrap
an OS in javascript.

~~~
dasil003
> _I 'm still not sure why the JS community seems determined to slowly
> bootstrap an OS in javascript._

Portability.

~~~
stymaar
In my previous job, we had some bash scripts for a lot of things. It worked
pretty well among Linux and Mac users in the team, but one day we had a new
developer who was a windows user … We rewritten all those scripts in
JavaScript using Grunt.

Maybe nowaday it's different thanks to Windows subsystem for Linux.

~~~
bigato
Wouldn't it be better for one developer to learn and adapt to the rest of the
team? I don't get why all the rest had to adapt to this single person who
didn't know shell.

~~~
Klathmon
There's a benefit to having multiple platforms on your development team if you
are developing something for multiple platforms.

It's too often I see projects with "supports Linux, OSX, and Windows" only to
find that none of the maintainers actually own a Mac and therefore it is
filled with bugs and often requires the user to "find their own dependencies".

If we are talking days of time and not weeks, the benefits of making (and
keeping) your whole system cross platform could pay off big time in the future
when you or someone on your team wants to switch, or you just want to easily
test on other platforms.

~~~
stymaar
Exactly: Having a developer working on windows was a blessing since it allowed
_someone_ in the team to test on EI11 before we shipped to the product team,
and it really improved our reactivity on this plateform. It wasn't our main
target since our product was using webRtc(i.e. Firefox and Chrome), but it was
supposed to fail gracefully on IE.

~~~
nawitus
At least these days you can download VirtualBox images for free to test on
IE11. But yeah, it's a luxury if there's a Windows developer that you can have
fixing all the IE11 bugs ;).

~~~
jimmaswell
I was under the impression that IE was standards compliant enough by version
11 that this shouldn't be necessary, but I guess not.

~~~
path411
Well, it's pretty complaint to standards now. The problem is that it's just
2-3 year old standards.

------
acemarke
I can highly recommend Sacha Greif's article "A Study Plan to Cure Javascript
Fatigue" ( [https://medium.freecodecamp.com/a-study-plan-to-cure-
javascr...](https://medium.freecodecamp.com/a-study-plan-to-cure-javascript-
fatigue-8ad3a54f2eb1) ) as a great place to start. It gives an excellent
series of steps for tackling modern Javascript concepts one piece at a time:
Javascript, React, ES6, and state management.

For anyone interested in learning React, here's my standard advice:

You should start out by reading through the official React docs and tutorial
at [https://facebook.github.io/react/](https://facebook.github.io/react/), and
use the official Create-React-App tool (
[https://github.com/facebookincubator/create-react-
app](https://github.com/facebookincubator/create-react-app) ) for setting up
projects. It creates a project with a solid build setup, with no configuration
needed on your part.

Past that, I keep a big list of links to high-quality tutorials and articles
on React, Redux, and related topics, at [https://github.com/markerikson/react-
redux-links](https://github.com/markerikson/react-redux-links) . Specifically
intended to be a great starting point for anyone trying to learn the
ecosystem, as well as a solid source of good info on more advanced topics.

~~~
mullsork
Highly oppose the recommendation of create-react-app for first-comers. You're
much better of learning one thing at a time. Like you said: Javascript ->
React -> ES6 -> State management.

create-react-app throws a ridiculous amount of crap in your face that you
might end up not liking anyhow. If anything should overwhelm you then that
project is it.

We have two working students at our company that were told to start their
projects with CRA and they were clueless after two months. Learn one thing at
a time.

~~~
acemarke
Erm... no. I'll paste a comment I wrote on Reddit yesterday (
[https://www.reddit.com/r/reactjs/comments/60vurv/is_using_cr...](https://www.reddit.com/r/reactjs/comments/60vurv/is_using_create_react_app_bad_practice/)
):

> There's a few different thoughts here.

> First, you can generally divide learners into two categories. There's a
> smaller group of people who feel the need to understand every abstraction
> and bit of tooling that they're using before they feel comfortable using all
> of those to build something. The larger group just wants to learn the actual
> tool or library at hand.

> The reason create-react-app exists in the first place is because "set up
> Webpack and Babel" was basically being viewed as a prerequisite for even the
> simplest React tutorial (even though you can use React without any build
> tooling whatsoever). That presented a large barrier for learning. By
> providing a one-command project creation tool with sensible (and even
> opinionated) defaults, CRA lowers the barrier for learning React, and allows
> experimentation while still having all the "nice" aspects like JSX, class
> properties syntax, and even hot reloading.

> So, no, it's definitely not a bad practice to use CRA!!! It's a fantastic
> tool to help you start learning and/or get right into building an
> application without hassle.

> If you want to learn more about the various aspects of configuring Webpack
> and other build tooling, there's several resources. If you look at the
> actual config files included in the react-scripts dependency (which contains
> the actual CRA configuration and build setup), you can see the heavily-
> commented list of options that CRA provides. Also, my React/Redux links list
> has a large section of Webpack tutorials, including some that start from the
> simplest possible Webpack config and add more options from there.

To emphasize this: what CRA gives you is just a preconfigured project that
builds properly out of the box. It doesn't force a state management lib on
you. It doesn't force a router. It DEFINITELY does NOT "throw a bunch of
stuff" at you. Maybe you have CRA confused with some other tool?

~~~
scrollaway
"Set up webpack and babel" shouldn't just be a step, it should be something
you learn: You need to understand why you need Webpack, why you need babel,
what problems they solve, the reason they're now part of your toolchain.

It doesn't take _long_ to understand that, and that's not to say C-R-A isn't
useful, but I personally find it to be a gap if I have these massive tools as
part of my pipeline and don't understand why and how they're separate from the
rest of my libraries.

~~~
jowiar
Should it be something you learn? Sure. Should it be the first thing you learn
in the stack, or something that blocks you from shipping? Shrug. Some people
feel the need to depth-first-search their stack as part of the learning
process. But at some point you have to say "This is as deep in the stack as
I'm going to care about today" \-- otherwise you end up sitting down to make a
web app and studying particle physics.

I think 2 years ago, you absolutely needed to go that deep, mostly because
when you sat down to work in the React ecosystem, you were almost certainly
going to end up debugging something in a webpack config. I don't think that's
the case today. It's a nice-to-have, and certainly will bring value
eventually, but at this point I'm hoping to pull my non-C-R-A apps onto C-R-A
so that managing the tooling isn't my job.

Plenty of devs ship plenty of business value in Rails without understanding
the full stack, and that's fine. It's worth taking a deep dive when needed, or
when specific concerns make themselves known, but saying "you need to learn
everything now!" is a huge barrier to entry -- getting those out of the way is
a good thing.

~~~
scrollaway
Yeah I get you. I understand the use case of "We just need to ship something
for a client now", I've been there plenty myself and C-R-A solves a real
problem (as well as it being useful for experienced devs etc).

But as far as _learning_ goes, I really think it's critical to learn what the
components you are using do. Otherwise, you have react, and a black box you
don't understand next to it.

~~~
mambodog
That's fine. When you want to learn what's in the black box you can dig into
it. The key is unblocking people on their path to their initial goal (eg.
learn React) so they don't give up after getting stuck on a prerequisite
(learn to configure webpack, learn to configure babel).

------
Waterluvian
The trick to being successful with JavaScript is to relax and allow yourself
to slightly sink into your office chair as a gelatinous blob of developer.

When you feel yourself getting all rigid and tense in the muscles, say,
because you read an article about how you're doing it wrong or that your
favourite libraries are dead-ends, just take a deep breath and patiently allow
yourself to return to your gelatinous form.

Now I know what you're thinking, "that's good and all, but I'll just slowly
become an obsolete blob of goo in an over-priced, surprisingly uncomfortable,
but good looking office chair. I like money, but at my company they don't pay
the non-performing goo-balls." Which is an understandable concern, but before
we address it, notice how your butt no-longer feels half sore, half numb when
in goo form, and how nice that kind of is. Ever wonder what that third lever
under your chair does? Now's a perfect time to find out!

As long as you accept that you're always going to be doing it wrong, that
there's always a newer library, and that your code will never scale infinitely
on the first try, you'll find that you can succeed and remain gelatinous. Pick
a stack then put on the blinders until its time to refactor/rebuild for the
next order of magnitude of scaling, or the next project.

~~~
Joeri
In my experience using last year's darling framework instead of this year's is
an excellent way to go. The codebase is stable and full-featured, the plugin
ecosystem is rich, the documentation is extensive, and stackoverflow is
already filled with accepted answers.

It's a myth that new languages and frameworks offer better productivity.
Mostly it's just the flavor that's different, not the calories. Sometimes you
get a genuine improvement, like react, but the vast majority of frameworks are
completely optional when it comes to getting stuff done. I'm always reminded
of this when I observe the Delphi team at work. Still lapping any web
developer when it comes to shipping features.

~~~
Pxtl
Delphi lapping the web has less to do with delphi and more to do with the web.
Web development _sucks_ and all the frameworks and javascript engines and css
preprocessors are just plaster and paint over that fundamentally broken
structure.

~~~
daliwali
Disagree -- the web platform itself is pretty solid. Websites made decades ago
are still accessible. The tooling that exists today will probably last much
shorter.

~~~
shakna
Right. Apart from Flash, Java applets, and the old MS alternative. Those
websites aren't accessible in practice, the technologies they're based on are
dead or dying.

~~~
daliwali
Those weren't accessible to begin with, not even back then :)

------
mwpmaybe
Great post—and the title got a laugh out of this self-described "ancient" web
developer—but interestingly, there's not much (any?) info in there about
learning JavaScript/ECMAScript _the language_. It and the articles it links
are mainly focused on the ecosystem and tooling.

I held JS at arm's length for way too long, trying to use it without actually
learning it. I finally grew tired of being illiterate and read "You Don't Know
JavaScript" by Kyle Simpson[0] and it was eye-opening. The preface[1] really
spoke to me and I suspect it will speak to many others like me. I only wish
I'd read it two years ago.

0\. [https://github.com/getify/You-Dont-Know-
JS](https://github.com/getify/You-Dont-Know-JS)

1\. [https://github.com/getify/You-Dont-Know-
JS/blob/master/prefa...](https://github.com/getify/You-Dont-Know-
JS/blob/master/preface.md)

~~~
flukus
Just copy and paste random bits from stack overflow until it works. This is
how 99% of javascript is coded.

~~~
throwayedidqo
This is unfortunately true because the language is so fucking crazy. Twice
this week:

How do I check for undefined in ES5 compatible way?

How do I check if I need a polyfill for cookie API?

The accepted answers for both were rediculous hacks because apparently there's
no good and easy way to do it

------
nathan_long
> Things haven’t settled down long enough for curriculums and guides to gel
> and mature, and for best practices to become authoritative for more than a
> few months... When you’re working with an ancient language like PHP, you
> Google a question or problem, and almost 100% of the time you will find a
> 5-year-old Stack Overflow answer that solves it... Not so much with modern
> JavaScript

OK, so everything's changing all the time, everything you Google will be out
of date, but it's worth it because... why, exactly?

Node doesn't block on IO. OK, cool. But the Erlang VM doesn't block on IO,
either, AND it's not single threaded, so you can actually do parallel
computation if you need to.

JS has a lot of raw speed these days. OK, cool. But raw speed is generally
less important than good algorithms and parallelism, and if we really need raw
speed in other languages, we can generally call out to C or something.

Rust has a unique value proposition: safety and speed. Erlang/Elixir have one:
supervision and easy parallelism. Ruby has one: well-worn tools for web
development.

I don't understand the value proposition for Javascript on the server, other
than "hey, you already know Javascript, right?", to which the answer is "LOL I
thought I did but apparently everything I know is wrong all the time".

I think I'm going to sit out the Javascript frenzy until it's all very stable
and Googling gets me answers that aren't So Last Week. And maybe we'll be
writing Rust for browsers via WebAssembly by then, anyway.

~~~
nostrademons
The value proposition is "You can use the same code on both the server and
client" (in addition to "You already know Javascript"). That's a really big
advantage in some cases. Think of collaborative editing (where you need to
apply operational transforms on all clients + the server), or form validation,
or game replay, or anything where you want to give real-time feedback to the
user while also validating those operations on the server.

If all you're doing is throwing HTML templates on top of CRUD results, then
yeah, Node.js doesn't get you much. But there are other problem domains where
you're basically forced into it. My first startup (WYSIWYG casual game
creation) would've been _much_ easier if Node had existed when I was working
on it; I spent a ridiculous amount of time writing polyglot
Javascript/Actionscript runtime libraries and server-side compilers that would
spit back a blob of Javascript in an AJAX request.

~~~
imron
> That's a really big advantage in some cases

That will mostly disappear with WebAssembly, and then we can finally start
using sane languages for front-end web development.

------
smdz
One of the worst problems I see for the new JS developers is the tooling-
overload. Being an experienced developer, I know why that tooling is required
- but new devs are just overwhelmed with the information out there (and
understandably so). And most of the todo-list projects tend to over-simplify
the tooling. It takes time to learn the tooling and understand its importance

In a typical React app (+TypeScript), I have atleast 40 dependencies in
package.json (frontend-only). I know exactly what each dependency is required
for. And each time I have a new app, I create that package.json one line at a
time - just to make sure I don't add unnecessary dependencies.

But for a JS newbie, knowing what dependency is what and why - is pretty
overwhelming, tedious and uncomfortable. This is assuming they already spent
time learning JS and the frameworks in the first place. Its easier to give up
that important learning when you have to deliver "just a landing page in
Angular" and answer to managers. After few iterations, the result is a
disaster that is difficult to maintain, buggy and much more difficult to add
features. Ultimately that adds to the development/maintenance cost.

I know why the JS tooling is complex, but sometimes I wish JS projects were as
simple (and controlled) as creating C# windows apps using VS - where the
tooling is mostly hidden

~~~
mrweasel
>Being an experienced developer, I know why that tooling is required

In terms of JavaScript I still don't understand why all that "tooling" is
required. Every time I try to understand how the JavaScript tools fit together
I end up just finding a .js file I can stick in the top of the HTML.

The "install with npm" on a website isn't helpful at all, because I'm not
doing Node, I'm just building a website and doesn't want Node.

What would help is a big poster, showing how stuff fits together. Grunt,
Bower, Node, NPM, it's just a big pile of confusing.

~~~
91bananas
Don't think of Node as a web server, that's what I'm guessing your
understanding of it is. Think of it as a copy of JS that is available on your
machine.

NPM is a package manager for you guessed it, Node. You use it to install
dependencies, whatever those might be for your situation.

I will ignore Bower.

Grunt is a task runner, say you have a task like minifying javascript files.
Grunt runs this task for you. Or CSS preprocessing, any task, it'll run it.
There are other things in this space too. Grunt, gulp, webpack, browserify,
etc.

The pieces aren't that hard to understand, you just have to read what they do.

Sure you can stick a JS file in an HTML file and you're good, but when you
start building more complex apps where you need common code in parts, specific
code in others, this becomes ridiculous to do by hand, that's why we have
build tools.

~~~
alkonaut
I might be daft but I honestly don't even understand what "build" is in the
context of a language that isn't compiled. Is it copying files to an output
location together with dependencies and possibly including some
transformations (minify etc)?

~~~
nawitus
"Is it copying files to an output location together with dependencies and
possibly including some transformations (minify etc)?".

That, and also other things, like compiling ES7+ JavaScript code to ES5 to run
in most browsers, or compiling a typed JavaScript file to non-typed (e.g.
TypeScript to JavaScript). You can also compile files to .css and .html from
different languages like pug and scss. There's a large amount of various
transformations that can be applied to web files.

~~~
alkonaut
Ah. There is tons of stuff that really _is_ compiled and the compiled _output_
is css, html, and ES, and the compiled inputs are TS, scss et.al. I get it.

~~~
91bananas
Transpiling is I think the _in_ word.

------
mybrid
As an Ancient Developer I see the problem with Javascript as not being the
language, but the ecosystem.

1\. Async programming. Async programming is hands down the aspect of
programming that college students do the worst on. As a TA at Berkeley I can
say it was one of the hardest aspects of programming for students to do well
in and yet Javascript starts with an total async model.

2\. No testing. Some of this has to do with Javascript starting life as web
browser only. Some of this has to do with writing test code for async
programming. How does one write async test code? Very, very carefully.

3\. Not invented here. Javascript is not a young language. It has been around
more than 10 years and yet Javascript has the same chaotic ecosystem as a
first year language. That's a permanent mind set, or ecosystem.

The natural conclusion of this kind of ecosystem is to eventually suggest
developers just run in kernel mode and bypass user space altogether.
Asynchronous code such as database pooling is hard to get correct. This why an
app server has financial value: pay for the hard stuff. And, get this, the
hard stuff can be abstracted away.. Same with distributed clustering. Because
these kinds of difficult async services can be black box abstracted then we
have a kernel, an OS and user space. Javascript challenges that notion, and
all the experience and the history of why we have kernels to begin with.
Javascript is asking developers to in effect become kernel developers, without
doing testing , and with in ever changing 'not invented here' chaotic code
base.

Does not bode well. Has nothing to do with language though.

~~~
z3t4
While "async" programming is very hard to learn, it comes naturally in
JavaScript. For example button.onclick = buttonClickedFunction And learning
"async" programming is a well worth investment. I've spent 10 years as a
coach/trainer and one strategy I used was to start with the hard stuff, if
they master for example the "snatch" (olympic lifting) all other gym exercises
will be easy. And it's the same thing with JavaScript. If you master
"async"/events then everything else will be easy.

~~~
mmargerum
Until you find out "this" isn't really this in the handler. Scoping and who
"this" is are the biggest pitfalls in JS

------
ben_pr
I see that JavaScript has it's place in the browser but the whole back-end
thing scares me. The ugly code (callbacks, etc), npm injecting only God knows
what into your back-end servers, tons of work-arounds for trying to make JS
not so ugly, are over the top.

The JS everywhere is so much like the "only tool you have is a hammer, so
every problem looks like a nail" thing, it's amazing.

Creating a simple, secure, extensible middle-tier is a solved problem and is
not in need of JS trying to solve it in a much more obtuse way. I've created
many myself in everything from Delphi, PHP, C#, Groovy, to Java and I would
never pick JS for that layer.

And a final thought, PHP used to get tons of bad press for being messy, etc,
etc. But this JS stuff takes that mess to a whole new level. Perhaps PHP devs
moved to node/js so they could make a mess and everyone would still think they
are the cool kids?

~~~
sergiotapia
Javascript on the backend is HORRIBLE. From a dev UX perspective it's a
terrible cluster __ __of random errors, and strange workarounds.

One time a project I was working on wouldn't run with some random ass error
from some random ass node module. Try try try, not working. Spent 2 hours
trying to find an answer online. For the hell of it I tried again and this
time it ran with NO code changes.

That's the day Javascript as a backend language died for me. It's a house of
cards stuck together with chinese knockoff glue.

~~~
bdcravens
Everytime I try to get excited about Javascript on the server and built
anything of substance, every damned module's example code is nothing but a
bunch of console.logs. There's must be some magical framework I'm missing
where that's a way to build apps. (Console Dot Logs on Fails?)

------
bitwize
An internet writes a cheerful, helpful guide for dealing with the fact that
like a sort of digital ice-nine, JavaScript turns everything it touches into a
sluggish, half-finished, poorly-integrated pile of shit much like itself. Most
of Hackernews assures itself that this is the natural order of things. One
Hackernews traces "new" and "exciting" JavaScript features as far back as
SICP, the Torah of the Scheme cult; his voice, along with those of the other
dissenters, is quickly drowned out.

~~~
TeMPOraL
> _sort of digital ice-nine_

This perfectly captures how I feel about the proliferation of JavaScript.
Thanks!

The way I see it, people try to push JavaScript _everywhere_ , no matter how
the domain is ill-suited for web technologies. We have even JS frameworks for
microcontrollers and embedded development, for goodness' sake! What I fear is
that this steals the mindshare of younger generation, and we'll be flooded
with half-assed JS non-solutions to everything, while saner approaches fall
off the hype train and wither away.

------
zeteo
> The sheer number of tools and plugins and packages and dependencies and
> editor setup and build configurations required to do it “the right way” is
> enough to stall you before you even get started.

At some point you have to ask yourself how much of this is good engineering
(does it help the end user?) and how much it's just having fun and impressing
fellow engineers. Is the complicated build process worthwhile just to obtain a
nicer syntax (for the current definition of "nicer")?

~~~
JustSomeNobody
>At some point you have to ask yourself how much of this is good engineering
(does it help the end user?) and how much it's just having fun and impressing
fellow engineers.

Javascript (and most Enterprise) developers will tell you it's the former.
Nearly every other developer will tell you it's the latter.

~~~
mrweasel
Enterprise Java developers are used confusing and magical build tools, so a
few tools for JavaScript isn't going to strike them as being weird or complex.

~~~
watwut
It is just a question of willingness to learn.

~~~
thekingofh
I don't think I agree. Willingness to learn vs willingness to expend mental
capacity are different. Sometimes the mental capacity to learn the abstraction
equals what it would take to just deal with the complexity that the
abstraction is attempting to hide.

------
narrator
I think why there's so much churn in javascript frameworks is that in a
dynamically typed system as soon as the framework objects get too big and
complicated they become burdensome to remember and everyone starts chasing the
next "bloat free" system. Then the "bloat free" system gains features and
complexity and everyone gets annoyed and chases after the next thing. Ever
wonder why Java codebases last forever and ever without being scrapped for the
latest whiz bang every year? It's the static typing and the lack of cleverness
in the language. The static typing helps manage the complexity and you can
delete stuff and know you didn't break anything because the compiler will say
so immediately. This is why Typescript is such a breath of fresh air. I
actually get some help from the IDE like I'm used to with statically typed
languages.

~~~
dwaltrip
To make this argument, you need to explain the corresponding lack of churn in
Python and Ruby frameworks.

~~~
rdiddly
Maybe it's not "statically typed" but "strongly typed" that counts. Both
Python & Ruby are strongly typed. Speaking personally, I definitely appreciate
anything that helps make sure type conversions are intentional and
predictable. Whether that's truly the explanation for the larger trends, I
don't know, but it's a thought.

------
bborud
The curse of having been around for a while is that after a while it looks
like the world is on auto-repeat. The antidote for this is to take a deep
breath, smile (without looking condescending), say "that's interesting" and
then wait and see what can stand the test of time.

~~~
nikki93
Cool. :O What have you seen that's cool and what's repeating? Maybe it's all
cycles anyways at diff. frequencies.

~~~
Cacti
Well, we just spent 10+ years reinventing the GUI development of the 70s and
80s, and about 8 relearning why relational data is important.

~~~
bborud
I have a slightly different take on the latter: we learned that doing
specialized persistence that solves hard problems is hard. And it is pointless
when it doesn't even solve the most basic problems of reliably storing data.

We also learned that just because something calls something a "database", it
doesn't mean that it replaces what came before it. There's room for new
categories of things that solve different problems than, say, relational
databases, when it comes to persistence.

~~~
dfox
We ended up just simply not caring about how "modern right way to do things"
looks like. Essentially any persistent data can be stored into PostgreSQL and
NFS mounted storage server and ideal way to do rich clientside javascript is
to serialize the whole thing out of some server-side object tree.

~~~
bborud
I've come to be suspicious of people who claim to do things in a "modern" way
:-).

I had a roundabout journey from trying to beat more traditional technologies
into shape to deal with massive transaction rates, giving up, writing more
specialized (but narrow scope) stuff, then changing jobs to a (competing)
company that pioneered building more general alternatives to SQL servers (for
internal use).

As I came out of that company I saw all these projects trying to mimic what we
had been doing so I figured "okay, good, I'll try that then". Since I'd spent
the last decade in territories where traditional SQL servers posed challenges.

I learned quite a few things. The first was that while I had been working with
people who really knew how the guts of a database worked, in "the real world",
most developers see the database as something that contains black magic.
You'll meet people who don't even know how to design a schema given certain
dominant access patterns -- and it'll be their job to design, and work with
the schema. This surprised me.

The second was that people who weren't really up for the task would make
database products. Not to mention any names, but I remember reading through
the source code of one of the more popular "modern" NoSQL databases and
wondering "how are they getting away with this? They are not even trying". It
was bad on a technical level, an architectural level and it demanded too much
proactive behavior and attention from developers. And they happily marketed it
as something it most definitively wasn't.

As a consequence I also misjudged how fast NoSQL databases would evolve early
on, and much more importantly: mature.

One database we used curiously never lost any data and never corrupted its
data (which all the other databases we used did), but holy shit was it a lot
of work to keep the database humming. It was just so godawfully sloppy and
focus was on adding features -- not tightening up what was already there. And
things stayed like that. For a long time.

So how do I approach persistence now? I put as much as I can into things like
PostgreSQL and when I really need high speeds to solve narrowly focused
problems, I write custom solutions for that. But I try to make things as
trivial as possible and I fret over any implicit or explicit promise I try to
make.

For the most part, PostgreSQL will do the job.

------
brandonmenc
[https://github.com/verekia/js-stack-from-
scratch](https://github.com/verekia/js-stack-from-scratch)

Rediscovering the horrors of setting up a Java web app in the early 2000s,
except now you configure it with json instead of xml.

~~~
ourmandave
Jesus Christmas! I thought it was a parody for a minute. There's 27 things
listed to set up.

    
    
      01 - Node, Yarn, package.json
      02 - Babel, ES6, ESLint, Flow, Jest, Husky
      03 - Express, Nodemon, PM2
      04 - Webpack, React, HMR
      05 - Redux, Immutable, Fetch
      06 - React Router, Server-Side Rendering, Helmet
      07 - Socket.IO
      08 - Bootstrap, JSS
      09 - Travis, Coveralls, Heroku
    

And this: _This is the V2 of the tutorial, major changes happened since the
2016 release. Check the Change Log!_

Read: all your v1 sh*t's broken.

~~~
Cacti
The amount of effort we've put in to avoid just basic sane development
practices and discipline is astounding.

We _could_ spend a few days thinking through the problem and developing a
solution that makes sense using our known tools and technologies, by analyzing
the issue at fundamental properties, OR FUCK IT, spend a year writing a new JS
library that is so full of obfuscated crud that no one can tell if you
actually solved the problem or not.

I get it, writing new libraries is fun, but the old tools are there because
they've been working, and well, for 30-40 years.

------
albb0920
I was very frustrated when I tried to move to gulp+sass+babel+uglifier tool
chain, It took me an afternoon to set everything up before I can write any
actual code.

The whole thing looks like to be designed toward make big and long-term
maintained website, not toward helping you to hack up throw away site quickly.

Stuff like gulp, after I installed it globally, I still have to install it per
project, which makes little sense to me.

It used to be just "compass init; compass watch", and start write stuff,
uglify JS before deploy, then done.

I still hates JS, I don't get why a language once hated by everyone, now is
sexy again. PHP in contrast, have improved a lot since 5.3, and it actually
quite fun to write these days.

~~~
fetbaffe
PHP is the diamond in the rough. Don't let all the bad tutorials fool you,
beneath is a great platform where you are truly productive.

You get far by only having PHP and you get twice that by only installing
composer.

No insane build steps, no running server process that needs to be hot
reloaded, composer is faster relative npm, decent typing system and built in
development web server.

To make PHP a superb language(okay, a better language :-) I wish for three
things.

    
    
      * Typed callable signatures
      * Function autoloading
      * Generics
    

Looking forward to the possibility of a jit in PHP 8.

~~~
alexfarran
Have you looked at Hack? It has all those features.

~~~
fetbaffe
Unfortunately not. Have thought about to add it to our test runners.

Sounds nice! If I understand correctly, the setup is a bit more complicated.

------
sparkling
As a "ancient web developer": i will come back once you JS folks have agreed
on a tool set and actually use it for more than 6 months.

~~~
CharlesW
> _i will come back once you JS folks have agreed on a tool set and actually
> use it for more than 6 months._

It works as a joke too, but the vast majority of JS developers aren't using
tools younger than 6 months old. Even current hotness Vue.js was originally
released in 2015, and Webpack was initially released in 2012.

~~~
mattmanser
You seem to have forgotten the latest hotness yarn, which is indeed less than
6 months old.

~~~
CharlesW
My point wasn't that there aren't interesting tools younger than 6 months,
just that nothing compels JS devs to use them or even pay attention to them
until they're as established (in age, use, GitHub stars, whatever) as is
comfortable for them.

~~~
mattmanser
All the instructions for everyone now uses yarn though, so you are affected,
just like everyone was affected with the bower switch, gulp switch, etc.

The churn in tooling is unavoidable even if you use slightly less fashionable
frameworks.

~~~
lumpypua
The trouble is that yarn is legitimately better than npm. My life is better as
a developer because of yarn.

I'm not claiming that all those transitions were for the best, far from it,
but the real question for any language community to answer is: "how much churn
is acceptable in the pursuit of better?" JS is an ongoing cultural experiment
in seeing what happens when you turn that dial to 11.

~~~
mattmanser
That's irrelevant in many ways. non-javascript languages deal with this by
improving the existing tools.

And realistically speaking, yarn is not a discernable improvement over npm.

The cultural experiment has a huge cost to programmers and it's been an utter
disaster. Even PHP has leapfrogged javascript.

------
skyisblue
I'm an ancient web developer who would build entire web apps in django. I've
tried creating forms with react, but it took 10 times longer to build it in
react than it would have in django, maybe i'm just new to react, but i don't
see how it would be faster even with more experience.

In django i would just create a model, a form class and a template and that
would handle the rendering of the form, form validation, and saving the data
into a db. But with react you would have to create the components and also
create a separate api that would handle the retrival and saving of data.

Are there any ancient developers out there building web apps faster with
react/vuejs/angular than django/rails?

~~~
SadWebDeveloper
> I'm an ancient web developer who would build entire web apps in django

No, you aren't an a "ancient web developer", ancient web development goes way
back before "CSS" even existed when "standardization" was hot topic and Opera
was the best of the best. JS-fans keep trying hard to dismiss everything "we
won" before in favor of their own "js-based" flavors (sass/less/react/etc)
favorite motto "one languague to rule them all, one language to bring them
all" (... and in the darkness bind them).

------
zlynx
Really ancient web developers know that Javascript adds hardly anything to
most web pages. Some HTML, CSS, a few iframes (or just frames!) and form POST,
and you've got a web site that's faster than most of today's junk.

I think my reaction to modern Javascript is to just ... don't.

~~~
nkristoffersen
If only it was all about speed :-)

These days it's all about the customer/user. And that user wants
functionality!

~~~
tobltobs
They want functionality, but they don't care if the functionality is brought
to them with a SPA built on the latest JS fart or some older than two years
stack.

------
ilaksh
Except she stopped before he learned async/await, which is how you usually
actually want to do async in Node.js now. It is even built into new versions
finally without transpilation.

I'm not ancient but I am 39 and have been doing web programming for many
years, going back to the days when PHP was popular. I switch over to primarily
JavaScript and Node.js around 6 years or so ago.

To all the haters, there are very practical reasons I started using Node on
the backend years ago. Trying to build a collaborative real-time web
application with Twisted and whatever was a huge pain. With something like
Node.js its much more practical because you get async and isomorphic (same
codebase on client and server).

Point being, JavaScript has been a big deal for quite a long time, and it
hasn't taken _all_ older developers up until just now to catch on.

And now we are actually one or two trends removed from that initial wave of
popularity. Plenty of the young guys who basically wrote the book on Node.js
and created the most downloaded-ever npm modules moved on to Go or whatever
years ago. And plenty of them decided to move on to Rust (or a few picked up
Nim if they are smart).

~~~
z3t4
While async/await is a nice abstraction/sugar, you will be much better off
actually learning "async" programming without the training wheel. Then once
you master "async" you can go back to use the abstraction/sugars if it still
makes sense. For example Promises are very bad abstraction because you will
make a lot of errors if you don't have a deep understanding.

------
wyldfire
> Then JavaScript and its modern frameworks ate backend, frontend, and
> everything in between, and it was time to re-become a web developer in 2017
> — who writes JavaScript.

Gee, I always thought that Javascript was a mediocre language, sufficient for
its initial purpose. I assumed that node.js was just someone's idea of
"wouldn't it be neat if I could have this on the backend too and use the same
representation of data on backend + frontend?"

I have to admit it sure does sound popular these days. But I still am under
the impression (delusion?) that a dedicated backend implementation in a
better-suited-language is what I really need. That said, I have little
experience with web dev.

~~~
Silhouette
I think it's important to keep some perspective here.

JavaScript is a popular language for one major reason: for native front-end
web development, it has effectively been the _only_ language. If you didn't
want to use plug-ins, you were going to use JS. If you wanted to use some
other language, it was going to be transpiled to JS.

Node is also popular for one major reason: it's the same language that people
who do front-end work already know, but running on the back-end. You can
(mostly) use the same libraries on either side. You can take someone who's
familiar with one side, and they can reasonably quickly be productive writing
code for the other.

None of this changes the fact that JavaScript _is_ a very mediocre language by
modern standards. Like many popular languages, it has improved over time, but
like many popular languages that have been around for a while, it has a lot of
fundamental warts that you can never fully escape.

Neither does any of this change the fact that JavaScript's surrounding tool
and library ecosystem _is_ very mediocre by modern standards. The lack of
stability, standardisation and longevity cripples progress and results in huge
amounts of duplicated or otherwise wasted effort. This is partly a cultural
thing, and partly due to technical limitations in a language that was never
designed for programming in the large but is now being pressed into service in
that role.

JavaScript is the language of the moment because web development is the high
profile field of the moment, but don't let the blog posts fool you.
Enthusiastic but often inexperienced developers working in JavaScript write as
if everything else is somehow old-fashioned and out-of-date, yet many ideas
hailed as radical advances in the JS community have been absolutely routine in
most of the programming world for decades. There are plenty of people getting
on with doing useful work -- often much more productively -- using those oh so
horrible, old-fashioned, out-of-date tools. They just don't need to shout from
the rooftops that they now have a standard way to import code from one file
and call it from another one, or to combine code from multiple files but strip
out parts that are never used to keep the size of the output down, or to
separate input, output and data processing, because the rest of the world was
learning these lessons in the 1970s and 1980s. :-)

~~~
tannhaeuser
I partly agree with you but I still like JavaScript and the ecosystem around
it.

There's something to be said wrt. "worse is better" when it comes to
JavaScript, as in "JavaScript is such a crappy language that it has managed to
go unnoticed by architecture astronauts for most of the time". By which I
mean, JavaScript front-end code of the jquery-era is extremely compact and to
the point, avoiding metadata layers and other bloat.

In judging JavaScript backend code, lack of experience of developers should be
taken into account, who mostly came from front-end developer roles.

------
rdiddly
This is like one of those pharmaceutical ads that vividly tells you about all
the hideous side-effects of the drug. The cognitive dissonance is so high that
even if the benefits happened to outweigh the downsides, I wouldn't know or
care because it's just too ridiculous to even think about. And I'm not
suffering from any disease the drug claims to treat, either.

------
mark242
So let me get this straight. You need to go through all this code in 2017:

[https://github.com/verekia/js-stack-from-
scratch/blob/master...](https://github.com/verekia/js-stack-from-
scratch/blob/master/tutorial/05-redux-immutable-fetch.md#redux)

...in order to replicate dispatchEvent and addEventListener?

~~~
steven777400
Looking at some of these examples/techniques reminds me of the "Enterprise
FizzBuzz" that we used to make fun of... except now no one is laughing and
it's a serious technique. The magic Redux strings are were I draw the line.
Absolutely not.

~~~
matmo
You don't need redux for a hello world app. Don't use redux for hello world
tier apps..

Relevant: [https://medium.com/@dan_abramov/you-might-not-need-redux-
be4...](https://medium.com/@dan_abramov/you-might-not-need-redux-
be46360cf367#.cpij8yjcg)

------
icc97
I attacked the modern Javascript approach through first focusing on functional
programming.

1\. Python + functional programming in Python

Python is hardly a pure functional language, but it's lovely and simple and
has all the core concepts including list comprehensions. This leads you on
to...

2\. Haskell

If you want to find a pure functional solution to a Python problem, first
search for the Haskell one and translate it. Then read Learn You a Haskell [0]
which was the funniest programming book I ever read and almost, almost taught
me about monads (I had it for a second, then tried to explain it in Python and
all was lost)

Now you can relax cause the hard bit is done.

3\. Read Javascript the Good Parts and only pay attention to the functional
programming bits. Suddenly mentions of currying aren't so scary.

4\. Work your way through the funfunfunction [1] videos, especially the
functional playlist [2] and for added bonus he has videos where he works
through the first few chapters of Learn You a Haskell.

Then you've got map, reduce, filter all completely under control. Now
immutability makes more sense, arrow functions don't look so strange, promises
are just friendly monads really and we all love those.

Now you've got Immutable.js [3], lodash, underscore all reasonable to
understand.

React's moaning about state and pure functions makes reasonable sense.

5\. Babel really isn't that hard. Just following the Meteor + React tutorial
[5] got that all working without me really noticing. Then, holy moly you're
all reacted up, with JSX and pure sweet smelling functions.

6\. Follow some of Dan Abramov's excellent blog posts such as about getting
eslint up and working in Sublime Text [4].

Yeah that's as far as I've got, but adding in Redux to this mix doesn't seem
so scary, at least I understand the language now. Angular will just have to
wait.

    
    
      [0]: http://learnyouahaskell.com/
      [1]: https://www.youtube.com/channel/UCO1cgjhGzsSYb1rsB4bFe4Q/
      [2]: https://www.youtube.com/playlist?list=PL0zVEGEvSaeEd9hlmCXrk5yUyqUag-n84
      [3]: https://www.youtube.com/watch?v=I7IdS-PbEgI
      [4]: https://medium.com/@dan_abramov/lint-like-it-s-2015-6987d44c5b48
      [5]: https://www.meteor.com/tutorials/react/creating-an-app

------
ChuckMcM
From the article -- _The point is, learning modern JavaScript requires human
intervention. Things haven’t settled down long enough for curriculums and
guides to gel and mature, and for best practices to become authoritative for
more than a few months._

And this is why its not the right path. Two things really strike me about
'modern' JS, one is that everyone rewrites the same dam things in a different
way just to say "Yeah, I'm the person behind the <mumble, mumble> framework."
which adds no value over the <grumble, grumble> framework, just that it uses
some new construct of the hour.

The second is that when you're being thrown into a sea of change like that,
you have to learn the fundamental language and its environment so that you can
move between the frameworks and still be effective. Learning any particular
system will apparently be useless.

~~~
jimmaswell
I've had a productive enough time for the last 5 or so years not following any
of the JS sphere and just sticking to jquery and the occasional other small
library (dynamic color picking widgets and the like) as appropriate. It's not
a sea of change unless you make it one.

~~~
ChuckMcM
That is a solid strategy, and one I endorse, but it is one that is criticized
by this article and others like it which would consider you an 'old tyme' jS
developer. :-(

------
pmarreck
I'm one of these old school backend developers.

I'm kind of still waiting for someone to build, like, an Erlang (or Elixir)
for the frontend. Maybe compile actual Erlang to it via emscripten.

Then code up a way to interface with the DOM, as well as model it in tests,
and I could be a frontend developer again! (except for CSS... hrm)

I'd be happy to never look at JS again, frankly.

I think Elm currently comes closest to what I'm looking for

------
beamatronic
Outstanding. Sadly, your article simply confirms for me that I want to stay in
my world which starts at the application server and ends with the database.

------
RikNieu
I went from barely knowing html and CSS to slinging react/redux apps with es6,
bundled with webpack, out for paying clients in less than a year.

If you just take your time, carefully go through tutorials and study a couple
of open source projects you'll be fine. Especially if you already have years
of development experience. You can do it!

~~~
dep_b
This is perhaps why it's not a good idea to learn JavaScript. Since there's a
lot of kids down there that learned how to throw something together in the
course of a year.

~~~
midorimidori
Eh. I started out by learning Javascript and creating a basic CRUD app using
the MEAN stack. Year after, I was hired as a contractor at a Fortune 500
company, and then transitioned into full-time at the same company 2 years
later. Now I juggle around several different programming languages; I'm
honestly glad that I started with Javascript.

------
bordercases
My contribution would be to point out the Rule of Least Power to people again.

[https://en.wikipedia.org/wiki/Rule_of_least_power](https://en.wikipedia.org/wiki/Rule_of_least_power)

A lot of the times when technology is being created in a space where existing
technologies already solve the problem, and even moresoe when these frameworks
are an "extension" of such platforms, the NIH syndrome comes as a cause of
being unfamiliar with how the original technology solves the problem. Rather
than RTFM and internalizing that way of thinking, the libraries are rebuilt.
Even worse, some get adopted by new developers that don't know better as being
standard.

jQuery, motherfucker, I'm looking at you. HTML5 and CSS can go further than
many expect, including myself.

------
matrix
Great article. This quote in particular resonated for me:

"I had to let go of doing it The Right Way from the get-go, and allow myself
to fumble through using suboptimal or just plain amateur setups just to get
comfortable with individual tools"

Coming from languages that have good build and dependency management tools,
JavaScript is a highly unproductive developer experience. Yes, you figure it
all out eventually, but I shudder to think how much developer productivity is
wasted today on JavaScript ecosystem complexity and constant tooling and
library churn.

Hopefully 5 years from now, we'll all be looking back in disbelief at what we
used to put up with to build web apps.

~~~
anjc
> Hopefully 5 years from now, we'll all be looking back in disbelief at what
> we used to put up with to build web apps.

We've all been saying that for 20 years when it comes to web dev :/

------
bluepnume
After burning a lot of time getting all the javascript tooling I wanted
working, for the umpteenth open source front-end javascript library I wanted
to publish, I threw together this:

[https://github.com/krakenjs/grumbler](https://github.com/krakenjs/grumbler)

Pretty opinionated on the tooling it uses, but good if you just want to say
"Fuck it, I want to fork some boilerplate, write some code, and
build/distribute it", then worry about the finer details later, and swap in
specific tooling that you need later.

------
leeoniya
I also dislike forced tooling, which was the reason for writing domvm [1]
which can be used as a drop-in <script> with no tooling. It's a practical mix
of virtual-dom, composable components and OO (as needed).

Pardon the shameless plug, but the whole project started as an easy way for
moving from jQuery spaghetti to a fast data-driven virtual-dom view layer so
seems fitting to post here.

[1] [https://github.com/leeoniya/domvm](https://github.com/leeoniya/domvm)

------
Sandman
I've been long enough here on HN to remember how people used to laugh at Java
in the comments, bemoaning the time it took to set everything up before you
can start working with it (although it wasn't really that much trouble then,
and it certainly isn't now) compared to how easy it was to start working with
Javascript ("Hey, all you need is a browser and an editor"). How the tables
have turned.

------
unit91
This is exactly why I switched to ClojureScript for new projects, and have
ported over a few from JS. One of the best decisions I ever made.

------
franciscop
The main problem I've found (as an _modern_ JS developer) is that in many
situations "mainstream" (AKA C/C++) CS topics are not so relevant to JS.
Javascript is Async by default, function-based instead of OO (until recently),
dynamic typed and was made to mess with the DOM.

So I feel like _some_ of the concepts taught in the most recommended books
such as Clean Code are only tangentially relevant and some times just plain
irrelevant. On the other hand, massive books/material written for pure JS are
really low quality compared to these classics (except some blog posts, but
with these it's difficult to get a round education).

So the most difficult part for me was to find out which concepts were relevant
for JS in high quality books and which were not, something that is not easy
when you don't know these concepts. Then learn the things not mentioned that
are important for a _modern_ JS developer such as NPM, exporting modules,
minimization+gzip+tree shaking, etc.

~~~
Joof
Functional style may be less mainstream, but it maps a little better to node.

------
peterwwillis
The only reason I want to learn about modern Javascript development is to
learn how I can replace it all with a small shell script. I assume it's all
basically a new, more complicated incarnation of PHP that can run in that
horrifying bloated ubiquitous user interface from hell that everyone is
addicted to. (Get off my lawn!)

------
overcast
Express/Node seems to work just fine for me at this point. I settle on Vue for
the frontend, and that's about it. The bundling/minifying/whateverfying
flavors of the week, I've basically passed on. Always added so much more crap
to a project, and in a lot of cases made everything bigger.

------
jksmith
I'd like to take this time to show some love to ISAPI extensions and filters.
Wrote some kickass stuff with that technology about 15 years ago (in Delphi of
course).

~~~
hh2222
I recall using some open source Delphi software that allowed auto reload of an
ISAPI.DLL just by replacing the DLL in the folder. That saved an iisreset.
Never got a chance to thank the technical wizard that created that.

~~~
jksmith
Damn that's sweet. I remember all the IIS restarts. Prolly in the 100's.

------
keithyjohnson
Oh god here comes yet another JS framework - [http://vanilla-
js.com/](http://vanilla-js.com/)

------
nojvek
Is it really that crazy complicated though?

Simple browser = script src=x Simple node = index.js

What if you want some libraries included? specify your libs in package.json
and npm install.

What if you want to publish your libs? Npm publish.

What if you want to have dependency tree bundled for browser as single script?
Webpack

What if you want nice types, latest features and validation for larger
projects ? Typescript loader in webpack

What if you want a nice state management library? Preact /react

There's a ton of crap and different ways of doing things but I bet fundamental
things are here to remain which solve a large % of use cases.

I would say things are getting simpler in some manner. You don't really need
lodash and jquery nowadays. The standard js in browsers has improved quite a
bit.

------
z3t4
You don't have to use every damn framework and compile to JS language out
there ... You will do just fine with vanilla JS!

Most important parts to learn about JavaScript: 1\. Scope and closures, like
that your function can access variables from a parent scope, and that those
variables are frozen in time. 2\. Events and "async", like button.onclick =
someFunction, where "someFunction" is called when a user click on the button.
If you learn just those two concepts you will know more then 95% of the
JavaScript programmers out there and it will be more fun to write JavaScript!
And all those frameworks are no longer needed.

------
Animats
_I had to let go of doing it The Right Way from the get-go, and allow myself
to fumble through using suboptimal or just plain amateur setups just to get
comfortable with individual tools._

Javascript started as a language for small programs. While it's possible to
write well-structured large programs in Javascript, the language does not
compel modularity. By default, everything is global. Modules and objects have
to be built out of closures. There are many ways to do this, and if you have
several libraries, each probably does it differently. Hence the pain level.

~~~
z3t4
For front-end, just start every .js file with:

    
    
      (function() {"use strict";
    

and end with

    
    
      })();
    

and write all global variables in ALL_CAPS, or with Big First Letter if it's a
constructor function / Class. If you want global functions, give them name-
spaces, like UTIL.handyFunction = function handyFunction() {}

~~~
Animats
That's how to fix _code that you write_. It doesn't help with code that you
import or copy from elsewhere.

~~~
z3t4
Sometime it feels like people intentionally make their code hard to copy/reuse
... While the code might do awesome stuff, it will however not live long due
to manageability problems. When the author reads his own code six moth later,
he's unable to fix that bug or add that feature, because he has forgot about
the hundreds of global variables, functions and couplings he had in his head
when writing the program.

------
pweissbrod
As someone who works heavily in the big data apache stack I will say that
javascript's rate of change and deprecation wears me out!

------
pjmlp
I rather stay an Ancient Web Developer, using MVC tooling for Java and .NET
until WebAssembly gets mature enough.

~~~
flukus
I'm trying to pay off my house while I can stick with .net. If the world ever
moves more towards javascript I'll change industries.

------
diminish
At some point someone will write an MS Access or File Maker Pro in JS. And
finally a Visual Basic 6 client as well​ as an SQL database right in an single
page JS app. At that point client side JS tools will stabilize. vb6.js will
then last forever.

------
Yokohiii
"Modern" is the new "Nonsense".

------
cs02rm0
I know I'm struggling with modern JavaScript tooling.

I've been using React with JSX and maybe as little as React router too. Trying
to get router added was so painful. NPM, Babel, we pack, grunt, gulp, etc and
then you find you've been given instructions for something on an old react
version and you need different tooling for a new one. Or the instructions give
you something that's really only suitable in dev not production.

I actually gave up trying to add Flux and wrote my own implementation in
vanilla JS which seems ludicrous to me.

~~~
z3t4
While React et al can be nice, you don't really _need_ it if you already know
vanilla JS.

------
stirner
I think the PHP docs are very much "paralleled".

------
neves
I liked the interactive workshops linked in the article. Do you have any other
recommendation of good ones?

------
lorenzosnap
mmm... I am surrounded by Java guys who worked with SWING (gone and forgotten)
JSP and STRUTS (same story). They talk about the beauty of Java 8 and that
they are waiting for Java 9. I wish I could tell them about this article,
because out there plenty of people still treat JS as a toy

~~~
merb
> because out there plenty of people still treat JS as a toy

actually I think it is. that so much stuff comes out for it is a clear factor
that we are not there yet. I also think that we either get a good language to
compile to js (scalajs, elm, clojure) or that WASM will be stable and supports
the DOM, before we reach the "JS endgame" (a stable technology which will have
backwards compatible stuff for at least 5 years)

------
SadWebDeveloper
> New Problems, Not-Yet-Established Solutions

FTFY: Zero Problems, Not-Tested Solutions

------
loppers92
Modern Javascript is: "Not to use Javascript"

------
madphrodite
As an old SA and systems programmer my exposure to 'js everywhere' (node +
angular -w- nosql backend) has convinced me that it's best left to hobbyists
and experimenters. The same kind of folks that liked the gentoo linux
distribution. If you can make your business run with js front to back good for
you. I don't want the pain.

Javascript + the node paradigm is such a bad systems approach that I've never
even bothered dealing with learning it to any extent. One look at an async
waterfall and nested callbacks + libuv 'transparently' handling blocking
routines was enough for me.

------
brilliantcode
The big objection to Javascript is likely arising from what you've seen 10~20
years ago. The fact is, the older you are, the more likely you will reject it.

I'd say look hard at your own skepticism and actually test it out. While it
doesn't make sense to write a blog using React/Redux, what one needs to get
over is he fact that Javascript is no longer just "rendering documents" but
the next evolution in software development as everybody moves to using a
common codebase and components.

Why build complicated native applications when a thinly wrapped SPA in
Electron will be indistinguishable to the customer? The only objection here is
the engineer's ego and reversion to the familiar.

Enterprises will still run on Java, but minimizing code and weight the ROI on
managing existing legacy technical debt for a simple CRUD desktop application
vs. utilizing current Javascript technologies will be a continued pattern as
Javascript wins more buy-in from the corporate executives.

This is coming from the biggest Javascript skeptic. After learning that the
problems Javascript were solving were already very difficult, I feel more
comfortable speaking the most active language on the web. Nay, I feel anxious
that I've not fully caught up with Javascript technologies.

~~~
pekk
That isn't a fact, just a personal opinion. Disagreement with that opinion
isn't a matter of ego or having an outdated view. A lot of people have looked
hard at the language and actually tested it out and found many actual flaws.
To rule that out you have to assume that everyone except you is just being
stupid.

At best, you can do things with it, and you still have to if you want to run
on browsers, so if it makes you happy you have some happy years ahead of you
before it becomes irrelevant. But other than running on browsers, the main
reason anyone uses it is that they are familiar with it or have sunk costs and
aren't really that aware of the alternatives. Javascript has nothing that many
other languages didn't have before it, except that artificially enforced
monopoly on running in browsers.

~~~
brilliantcode
I find it amusing to find so many luddites on HN. Take what you will but you
are going to find to hard software engineering jobs in 10 years when
everything moves to Javascript and Frontend Application development becomes
the new norm. With progressive web apps, that day is closer than you think.

Opinion sure, but some are more probable than others, and valuable in
predicting the future and allocating resources accordingly.

The most used language on stackoverflow is Javascript, does not tell you
anything about trends?

Javascript is no longer the hack you are thinking of with ES6. ES6 is world
class and I find it hard to fathom 19 year olds in SV building desktop
applications using Java Swing & FX (which supposedly some old timer HN claim
is happening which is a lie because it's way more time consuming, I've built
with Java Swing and Electron and people commenting have no fucking clue the
night and day difference) vs Node.js + Frontend framework of some sort.
Walmart also adopted Node.js fairly quickly which sort of kills the argument
that Java is king. In fact, less code is a trend in the enterprise with the
rise of Scala and other less verbose languages that run on top of JVM.

Javascript has evolved from it's humble roots in the browser, it is now
expanding and finding developer mindshare well beyond the browser (in case you
didn't know about Node.js).

I find it hard to continue this discussion when it's clear you haven't spent
any time recently with Javascript and instead relying on your outdated
misconceptions about Javascript.

Please spend some time with the modern javascript tech stack before you offer
a rebuttal so you are using the latest facts.

~~~
justaaron
Wow. just wow. The notion that anyone less than pleased with the idea of
Javascript everywhere is a luddite is beyond shockingly absurd. "Javascript-
everywhere"(as you appear to advocate) is, at it's core, a denial of the rest
of the technological eco-system. (The web makes a lousy UI... see "the 90's")
Languages have their use-cases. Javascript is only becoming hackier and
hackier as it attempts to agglomerate "classes" etc. (as a prototypical-
inheritance single-threaded language that was DESIGNED to run in the browser
initially) While one can only complain of minor brain damage from learning it,
and it certainly has it's front-end web uses, I find your comment utterly
bizarre.

~~~
brilliantcode
> Javascript is only becoming hackier and hackier

ES6 is NOT a hack. It's world class and expressive. It definitely doesn't
resemble the old Javascript.

> prototypical-inheritance single-threaded language that was DESIGNED to run
> in the browser initially)

Yes, said by literally every evolving technology. Javascript is NOT rendering
in your browser anymore. It's powering a lot of mission critical applications
used by the same people who once bought into JVM and now choosing to opt for
rewrite using lighter and saner stacks.

> While one can only complain of minor brain damage from learning it, and it
> certainly has it's front-end web uses

It's not limited to front-end but back-end. This alone brings a ton of value
by removing the context switching between different languages.

Reading your comment, it's clear you haven't spent enough time with Javascript
by calling it a "hack". Node.js is not a "hack" and neither is NPM. These are
the new tools of the trade that's dominating all other stacks (just take a
look at stackoverflow-its a measure of everyone).

I can't believe some people would be willing to push Java Swing/FX to their
developers when a far more lighter and saner platform exists in the form of
think HTML5 clients.

Single Page Applications are the same as desktop to 99.99% of the users out
there. Your customers don't give a shit if it's written in Java Swing or
Electron + SPA. What they do care is that you move as quick as their changing
expectations. You can't do this with a late 90s technology built on the
assumption software should mimic a heavily short sighted interpretation of the
world-that you should write everything in terms of classes because the world
is made out of objects and hide many parameters and layers buried under a
hierarchy. To be more insulting, Java applications require a heavy JVM pre-
requisite on the client side, riddled with zero day security vulnerabilities.

