
The melting pot of JavaScript (2017) - lewisflude
https://increment.com/development/the-melting-pot-of-javascript/
======
spricket
I really like the kind of sanity that TypeScript brings to JS, super well
designed and usually a pleasure to work with. That said, I've worked in many
languages and I can't see any reason you would willing write your backend in
JS or TypeScript.

Java, C#, Rails, and to some extent Python are much saner choices. The massive
churn of the JS ecosystem bleeds through to the backend, hard.

JS could use a little more of the cruft and process that makes Java and C#
especially so "uninteresting".

Java especially is kind of a joy to work in if you ignore the cruft.
Everything is generally well documented, the libraries are mostly very solid,
code is almost always backwards compatible, there isn't a zillion ways to do
everything, frameworks tend to live for a decade or so.

And it's faster than JS, and uses way less memory, and mostly solved
dependency hell and bloat over a decade ago.

Java feels like it was designed, not grown. Everything follows similar
convention so it's easy to pick up new libraries. The advantages are many. The
drawbacks are few as long as you use things like Lombok and code generation
liberally. By the way; code generation using agents, annotation processors,
and bytecode manipulation is pretty much standard and a godsend for doing
interesting things (and getting around the cruft) .

In java, I can write code on the fly at runtime, or even during compile time
using standard tools. Js barely even supports reflection. This is a huge
underrated shortcoming of js if you're doing anything complicated

~~~
orangeeater
> Js barely even supports reflection. This is a huge underrated shortcoming of
> js if you're doing anything complicated

Can you explain what Java offers with regard to reflection that JS doesn't?

My feeling is that reflection is almost moot in JS since you can
inspect/mutate objects at runtime however you like. But maybe I'm missing the
point of reflection.

There is a Reflect object with a bunch of static methods on it in ES6. It
mostly just replicates functonality that already exists in the language, and
my suspicion is that it's mainly there so it can be extended at a later date
without breaking backwards compatiblity.

~~~
orf
> Can you explain what Java offers with regard to reflection that JS doesn't?

Among hundreds of other things, getting the return type of a method and
getting the input parameter names (+ types) in a way that doesn't revolve
around literally parsing the functions toString() representation.

Oh, and typeof checking that isn't disgustingly broken.

~~~
pitaj
> getting the return type of a method and getting the input parameter names (+
> types)

Type information literally doesn't exist at runtime, though. Isn't it kind of
ridiculous to compare languages like that?

~~~
lopatin
> Type information literally doesn't exist at runtime, though.

Correct if I'm wrong, not all types get erased in Java. Doesn't type erasure
only happen for generics? Say I have a non generic, plain Java class and want
to inspect one of it's method's return types at runtime to see if it returns
class A or class B. I can do that, right?

~~~
pitaj
I was talking about JavaScript. In JavaScript there are no typed functions or
arguments, so that information doesn't exist period.

~~~
lopatin
Right, so I guess I'm not understanding your point about why comparing two
languages like this is ridiculous. Java has a full blown runtime reflection
system (it's "types exist at runtime"). JS doesn't. So Java wins in the
reflection category.

~~~
tracker1
But in JS, reflection is pretty much not needed... I don't need to use
reflection to see if an object has a quack method, or that I call it with the
right types... I just call instance.quack() ... It's up to you as the
developer to keep your interfaces and composition in line.

It's actually _WAY_ easier than with C# or Java. Since the use-case of
reflection itself is largely unnecessary.

~~~
lopatin
Calling a method and seeing what happens is not a substitute for reflection.
You can do that in Java too btw.

------
DLA
Dan Abramov wrote a brilliant post here, IMO. So much here. Unix Philosophy,
yes please. Considering the cognitive load of tool options and configuration
knobs, and the impact of the JS ecosystem for beginners. "A tool should work
with (almost) no configuration." Amen. "Mind your output" from tools (errors
must be helpful and sort the important from the unimportant); I've felt this
pain and have abandoned tools at the start because of incomprehensible errors.
Love the idea of toolboxes w/r/t dependencies. Read the post for the details.
Great work Dan!

~~~
undersheet
> cognitive load of tool options

First time I hear options are bad. Many options and competition lead to best
products. There are enough posts and people who tell you what you should use.

Or just use npmtrends or npmcharts. 1 second later you know what is going on
and what module you should pick.

Why are people criticizing something they have never used?

~~~
DLA
My point here on this one is simply that it's investing to _think_ about this
factor. For beginners (which I am not), too many options can be confusing.
That said, setting reasonable defaults for detail options so things work well
without needing to configure then to start is a nice way around this. Deep
options exist and can be adjusted as needed but a solid default configuration
is set out of the box. "There are enough posts and people who tell you what
you should use." \-- sure but what if opinions very widely? There's the
cognitive load or put another way friction-to-first-use.

~~~
undersheet
who said that JS is for beginners?

------
_hardwaregeek
Very nice points here. I've always been struck at how the JavaScript community
never really adopted the Rails ideas of convention over configuration and
optimizing for developer happiness. While it's easy to roll one's eyes at the
marketing lingo, these principles do truly make Rails a charm to use. Right
now, even setting up the most simple Webpack-Babel-Node config requires
writing a whole lot of config and set up for very little gain.

~~~
undersheet
In JS there is a lot of convention but on a micro level. The times of
monolithic Rails apps which have strict conventions are over and it's good:
Too much magic and strict conventions often forced devs into patterns which
didn't match the use case. Even experienced Rails devs tried to solve every
problem the same way.

You also confusing matters. You need Webpack, Babel etc for the frontend not
the backend. And even in the frontend it got abstracted away by things like
creat-react-app. So you shouldn't them see them too often.

~~~
_hardwaregeek
First, Webpack and Babel are totally used for backend. If you look at a lot of
Node libraries, they use ES6 modules in their
[docs]([https://github.com/graphql/graphql-
js](https://github.com/graphql/graphql-js)). While you could use mjs for this,
it's still experimental.

I do think create-react-app is a good innovation in the JS world. However,
I've never found a good equivalent on the back end. Setting up even the most
basic CRUD REST API requires a whole lot of typing for very little reward.

As for convention, I think JS could do with more of it. I find that when I
talk about adding more convention, people take it quite literally as "we need
to reinvent Rails in JS". That's not at all what I mean. Convention can be
something as simple as Rack, which is a consistent, useful interface between
servers. Convention does not and is not tied to monoliths or MVC or any other
aspect of Rails.

~~~
com2kid
> I do think create-react-app is a good innovation in the JS world. However,
> I've never found a good equivalent on the back end. Setting up even the most
> basic CRUD REST API requires a whole lot of typing for very little reward.

This is where services like Google Firebase Functions become useful.

I went from having never written a REST API in my life, to up and running in
under 20 minutes.

First time I went to create some endpoints on my own server, wow, that was a
pain.

~~~
_hardwaregeek
Firebase is a dream. It's almost a shame they got bought by Google because
it's such a fantastic idea. All of the things I used to dread setting up
(auth, deployment, serverless) are automated and dead easy. The documentation
is clear and caters to the common usecases. I managed to set up a Sendgrid
email that sends on database writes within an hour or two.

~~~
com2kid
> The documentation is clear and caters to the common usecases.

I wouldn't quite say that, but I'll agree with your other points. :)

(More than once the docs have been out of date, or just flat out wrong,
costing me many hours of development time...)

------
zach43
I personally think that the JavaScript community is doing a great job with its
tooling and approach. Compared to other language environments I’ve worked with
(C, C++, Python), most common JS tools work in predictable, user-friendly
ways...also they frequently have good documentation and “getting started”
tutorials.

It is good to see that the community is open to introspecting and improving
even further

~~~
hrabago
Ten years ago, JavaScript was my go to when I wanted to expose others to
coding. It still is today, but now that comes with the caveat that the most
popular libraries and framework require a significant amount of prior
knowledge to understand and to start using.

I haven't done this exercise in a long while, but the last time I tried to
start a project from the "most current and stable releases and
recommendations", I ended up not being able to get anything running. In the
end, I had several hundred megabytes of libraries downloaded, a complicated
configuration, and a non-working application.

Today, there are toolsets to get you started with everything and produce a
running application, but it's almost totally opaque. I'm afraid to use them
because the first time something breaks, I don't know if I would be able to
resolve the issue.

I would still rather have a decent understanding of how things connect.

~~~
kibwen
JavaScript is _still_ what I use to introduce programming to new people,
because for people who haven't done their dues learning how to use a command-
line, the hardest part of getting started with programming is getting your
computer set up to do it at all. And since everyone already has a browser,
getting started with coding only requires showing them how to open the
developer console.

~~~
oaiey
Fair, but most stacks including the previous infamous ones are two or three
lightweight installs away. The VSCode/Atom/Sublime generation of IDE
replacements made that possible.

I come from an environment (.NET) where setup was a day or two of work but now
is a matter of 10 or less minutes).

~~~
jancsika
10 minutes is still two orders of magnitude longer than "<ctrl-shift-c>."

~~~
pdimitar
And? Is 10 minutes so damning?

------
vinceguidry
I welcome the slow transformation of Javascript into Ruby. Every single thing
in there is already a thing in the Ruby ecosystem. Convention over
configuration. The careful, but automatic dependency management. Principle of
least surprise.

All things I didn't know how much I relied on until I moved to NodeJS and
found them non-existent.

~~~
humbleMouse
What you said could be true of Java or any other modern server languagae.

------
lewisjoe
I just wrote a proposal for my team today as to how the front-end tooling has
changed recently and why we'd need to adopt them in our workflow.

[https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c...](https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c28f7020a3a523)

With confidential details masked, it's still a pretty good read for the rest
of the Internet. Outlines why JS fatigue is not really bad but just
improvements and what exactly is stopping us from adopting those improvements.

Resonates a lot with Dan's write-up. Excellent piece by Dan. A much needed
one. I'd probably link this along in my proposal.

Note: We've built a pretty fat browser app with plain vanilla JS, strictly ES5
only, crude bash scripts for building a bundled js & all such ancient methods.

~~~
perfunctory
Really curious what is actually wrong with "crude bash scripts for building"?

I had experience with both types of projects - the ones with home made crude
build tools (in Python, not bash), and the ones with modern javascript build
pipelines. The first build never broke. The second build would break every
couple of months for no obvious reason without us touching the project
structure.

~~~
gedy
Maintenance. Because seems they are usually written/owned/optimized by some
build brainiac that becomes a bottleneck or leaves at some point.

~~~
TeMPOraL
The equivalent "modern" workflow is written, owned and optimized by build
brainiacs with turnover on the order of weeks. I'd say that maintenance of
"crude shell scripts" is much less difficult and expensive than keeping up
with the latest webdev "standard practice".

~~~
untog
You'd be wrong. I'm not arguing that Webpack is a deeply confusing system, but
there are tens of thousands of people out there figuring it out too. Almost
any question has an answer a Google search away.

Your bespoke bash script has no such community.

~~~
TeMPOraL
But my bespoke bash script has longer shelf life, which is the entire point
here.

------
c-smile
JavaScript was designed to be a glue language - to connect output of one
native function with input of other native function. And do all of this in UI
event handlers.

And it was almost perfect (modulo hoisting, semicolon omission) for that.

The trouble has started when Web, as a platform, has failed to provide safe
alternative to JS aimed for extendable way of delivering and running high-
performant code on the client.

Ideally we should have something like <script type="binary/bytecode"> with
something close to JavaVM and HTML DOM exposed to it. At least 15 years ago.
So we would have a lot of compilers, static compilation and code analysis.

Instead we have tons of weirdest possible solutions: Web "threads" with code
that need to be downloaded and compiled before running, that ugly WebAsm,
transpilers-of-something-into-JS. C++ code "transpiled" into JS, in whose
nightmare that bright idea was born?

Yet we have crowds of talented people wasting time of writing about how to
really HACK the platform that was not meant to be used this way.

Create bunch of problems to ourselves just to overcome them heroically. Far
from being productive.

~~~
pitaj
> something close to JavaVM and HTML DOM exposed to it

> ugly WebAsm

WASM isn't fully functional as a standalone alternative to JS in the browser,
yet, but you can essentially use it that way with things like wasm-bindgen in
the Rust ecosystem. And it performs essentially what you're describing, being
a VM running bytecode in a sandbox.

~~~
c-smile
> but you can essentially use it that way

"Essentially" is a nice word. You can use it for example as JavaScript is a
programming language, essentially, yeah.

W3C DOM was defined initially in terms of Java interfaces.

Where we would be now if we were allowed to run Java bytecodes in browser
directly from the very beginning?

<script type="binary/web-bytecode" src="myapp.class">

Today we might discuss -strip-dead-code option in your favorite compiler of
XYZ language. Instead of fighting with would-be-linker npm.

~~~
int_19h
> Where we would be now if we were allowed to run Java bytecodes in browser
> directly from the very beginning?

We'd be ranting at JVM for not having the features necessary to compile high-
perf C code into it, for one.

Which is why Wasm is fundamentally a better approach. It's that one case where
it makes sense to go as low level as possible (while retaining cross-platform
support), to allow as many future possibilities building on this foundation as
possible.

~~~
pdimitar
Are you not forgetting something? Java is to this day several times faster
than JS and sources for that abound on the net (including [0]).

No, we wouldn't fight for how to compile C in it. We would very likely fight
to make the payloads and bootstrap times smaller.

[0][https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/faster/javascript.html)

~~~
int_19h
Faster than JS doesn't make it fast enough. Look at how it fares versus C in
those same tests.

~~~
pdimitar
Fair, but do we really need C levels of performance on the web? That's
madness. They are mostly CRUD apps for God's sake. They don't have to be able
to run liquid simulations at 200FPS.

IMO the level of Java / Erlang performance is, and should always be, plenty
enough for the web.

~~~
int_19h
For CRUD apps, JavaScript is plenty perf-wise already. The reason why there
have been many attempts to push things further is precisely because people are
trying to build web apps that need more (including 3D games even).

------
ausjke
I never got the idea of nodejs or javascript for backend, tried it a few times
and eventually returned to python and java. It's much easier for python/java
to add event-loop and/or restful framework than making javascript looks like
python/java one day as far as backend goes.

In 2019 I still have 0 interest in javascript/TS for backend, the thousands of
modules under node_modules alone is enough for me, and not all real world
product need async/promise/callback/SPA, javascript is over-heated too much,
not fun at all.

~~~
hombre_fatal
You don't get to just add an event loop and start writing async code in Python
or Java. It opens up its own can of worms now that you're straddling the sync
and async worlds. Compare working with Netty (async) to Jetty (sync). It's
certainly not trivial.

That Javascript is async-everything is one of its best and often overlooked
features in these comparisons.

I think this snippet encapsulates a lot of why Javascript is actually very
pleasant on the server:

    
    
        const results = await Promise.map(urls, (url) => process(url), { concurrency: 8 })
            .then((results) => postprocess(results))

~~~
beatgammit
I don't think it _is_ overlooked. JavaScript doesn't scale, both in terms of
code complexity (callback hell) and across cores, and the "gold standard"
these days is microservices, which has a ton of issues.

If you want to look at bolt-on async working, check out C# or Rust. They've
basically taken JavaScript's new async/await and added threading (at least
Rust has, not sure about C#). You can write an async app and have it run in a
thread pool without much fuss.

I don't know what the story is for Java, but seeing as C# is effectively the
same thing, it's not hard to imagine adding async being easier than adding
threads or performance to JavaScript.

~~~
joelfolksy
FYI, async/await (a promise type + async function decoration + await
expressions) was actually invented by C#. It was designed to operate
seamlessly with .NET's concurrency framework, the TPL, which uses a thread
pool. So it was actually the case that _Javascript_ took async/await and
_removed_ threading.

------
w4tson
Is it unfair to say that some of these problems are caused by a lack of
awareness (or an unwillingness) to learn from other communities (like, Ruby,
Java etc) that have solved these some of these problems already?

~~~
oaiey
No. And that is also why JS is successful. Newbies with little oversight
create new tools. Of thousands of them, one or two become popular because of
non-functional reasons (right blog post, right fit, easy use, ..).

Welcome to the mess :)

~~~
jskaggz
Tech pop-culture... Navigating these technology growth explosions is like
searching for solid reference architecture in a booming shantytown. Some parts
of these settlements eventually get things like running water, working sewage,
urban planning.

~~~
oaiey
Do not disagree to that. My comment is not a compliment to JS just a brutal
analysis.

------
throwaway427
Let's say you'd like to write front-end code in a language that hides as much
of the problems with JS as possible, preferably one that comes with a standard
library, has elegant (or at least ergonomic) JS to <lang> interop and
bridging, simplifies async code, and has a simple, integrated toolchain for
targeting JS (all these amongst other things), what would you suggest?
Basically what's the best language to write Javascript in : )

Dart? Elm? Clojurescript? Objective-J?

~~~
scns
ReasonML

~~~
throwaway427
Oh I forgot about Reason. Does it have a standard library that obviates the
need for pulling in things like lodash, etc?

------
raxxorrax
Unpopular opinion time: I understand why people prefer TypeScript/CoffeeScript
but for me personally it just destroys the incentive of a scripting language
and I am a fan of keeping deployment as simple as possible and to me
transpiling is equivalent to compiling. Packaging is bad as it is.

True, maybe everything is different in large scale applications but I hate it
if I find something interesting implemented in TypeScript and in 95% of cases
I will just move on.

Javascript is not a beauty and any superset just seems like a facelift. The
result looks like old and used car tires.

disclaimer: I am no web dev but somehow come in contact with JS frequently.

------
me551ah
You never really learn javascript, you learn frameworks. I was a js developer
about 7-8 years ago and dabbled with jQuery , dojo and the likes and then
moved over to backend and mobile development. I tried getting back into
javascript again and realized that I just could not get in and start coding.
There are a lot more frameworks now that I have to learn to get started and
I'm sure that a few years down the line, these will become obsolete too.

~~~
MarsAscendant
Interesting. I stopped touching frameworks on my second year in. It's the same
problem I have with trying to develop within the constraints of someone else's
work: I find it confusing and anxiety-inducing.

I'd rather write my own stuff, unless I'm woefully unequipped to to begin
with. (Cryptography, authentification, credit card handling...) I feel like
I'd learned quite a bit of JavaScript, specifically – especially with the help
of someone like Angus Croll
[[https://javascriptweblog.wordpress.com/](https://javascriptweblog.wordpress.com/)].

I'm not that clever a JS developer – or a programmer, for that matter – so his
`compose()` and `curry()` sound magical to me.

------
mc13
save

