
State of JavaScript 2018 Survey - cstrat
https://stateofjs.com/
======
messit
Javascript is becoming the next c++, what a mess. I can now write a function
in about 10 different ways.. In all their efforts to fix it, it only becomes
worse. Loads of fancy new features (mostly copied from Coffeescript), but the
basic type system is still not fixed!

I miss the simplicity, readability and power of Coffeescript. -> function
without context binding, => function with binding. That's it!
does?.this?.prop?.exist, nope still not possible in JS. Ah well, the community
hates CS and loves all the amazing new features of ES+. Until you look at a
random codebase out there of some outstanding JS dev's utilising all the
latest features. One big mess of conflicting strategies, unreadable code,
poorly documented, bloated, etc.. etc.. But hey, we're using promises,
reducers and spread operators everywhere, we're super smart!

When will the JS community start improving on the quality of the code instead
of adding new language features, tooling, frameworks and so on? Try to think
of better names for your identifiers to start with, using an intuitive naming
system throughout a large codebase so it becomes actually readable. No, will
not happen, too boring I guess.

I'm writing Typescript now to pay the bills. Adding even more complexity, it
scales so well, mainly because you can use the 'any' type. Said enough?

~~~
andrewmcwatters
Honestly, I think the only thing that sticks out to me is that JavaScript
treats addition and catenation as the same thing, and, humbly, I don't think
they are. Maybe some folks here more intimately familiar with good type
handling can give their two cents.

But, I've enjoyed dynamic typing in languages where values had types and
variables didn't, and because there wasn't any consolidation of addition and
catenation, everything was fine. Also type coercion seems to be a pain point
in JavaScript for some, whereas explicit type conversion through function
calls in other languages seems to remove these issues, in my experience.

And TypeScript seems to bring a lot of powerful concepts to developers who
enjoy the benefits of strict typing, which is great.

But, languages that continually expand their grammar complexity and usage
conventions feel harder to master to me. Now and again I come back to Lua's
reference manual and learn something new that I don't see other developers in
that space recognize, and that's the simplest practical scripting language I
know. It's complex syntax in Backus-Naur form is one section of the reference
manual.

ECMAScript literally has multiple chapters to explain its grammar. I just
don't understand how you can truly master that. At least, you certainly would
not know all of the edge cases with the language.

~~~
combatentropy
> type coercion seems to be a pain point

Yeah:

    
    
      Boolean("0");  // true
    

I believe type coercian should pass through the types from simplest to most
complex.

    
    
      false;                 // boolean, the simplest data type
      Number(false);         // 0, number
      String(Number(false)); // "0", string, so Boolean("0") should have been false

------
jph
Svelte is the best JavaScript UI framework I've seen in many years, better
than React, Vue, etc. I'm using it for real work. I would love to see Svelte
on this list.

[https://svelte.technology/](https://svelte.technology/)

~~~
shaabanban
Hmm I briefly looked at it and I am certainly intrigued. I really like the
simplicity of await blocks, but I have some reservations about the template
syntax, namely that it reminds me a lot of angular.js. Syntax like

    
    
      {#each cats as cat}
    

reminds me of ng-repeat, and of course there are other similarities.

I'm not necessarily saying that that's bad, but as a matter of personal
preference I tend to prefer the html-into-JS approach of JSX / React over what
is essentially implementing a subset of javascript as part of the template
syntax.

I don't like that you have to ask what parts of javascript you are allowed to
use within a template.

------
Someone1234
Mock me if you want but I found this survey confusing to take. The
titles/subject areas are disjointed from the questions, then the first
question is just the word "Reason." No explanation, just one word, "Reason."
Took me longer than it should have to realize what was going on.

~~~
tobyhinloopen
Same here. I recall vaguely that "Reason" was some kind of tech and not an
order to reason about something.

~~~
DonHopkins
There's a Reason for everything.

[https://www.propellerheads.se/en/reason](https://www.propellerheads.se/en/reason)

------
spullara
The state of JavaScript 2018 is the 10s spinner as it loads all the JavaScript
necessary to run the survey.

------
andrewmcwatters
Just some feedback to share here for thoughts (I shared it in the survey):
most of the time I didn't really care enough to give specific reasons why I
_did_ or _didn 't_ like something, and felt like it was a retention pain point
in the survey.

If I like or dislike something, that should be enough. I know people want to
know where things can improve, but honestly, a lot of the time the answer is
"the whole damn thing is worthless to me, and there's too many cons to correct
and not enough pros to validate its existence to me."

I _realize_ that's not constructive, but if something is fundamentally
unappealing, no amount of steering is going to fix that in my eyes.

~~~
tobyhinloopen
This. There were too many & vague reasons for like/dislike to choose from and
I didn't feel like answering that for every technology

------
SoylentOrange
Great survey, very excited to see the results.

The option of complexity really spoke to me. If you’re building a small one-
off website, then you want something short of a framework like React, but
something more modern than Jquery (manage state, reactive style programming).
What can you use?

I feel modern client side JavaScript assumes you’re working on a large, long
lived site that you plan to maintain. There’s no equivalent of “I just want to
create something quickly for use by about 100-1000 people for a few weeks”

~~~
was_boring
This is how I coach my team through this: use the right tools for the job.

Now what does that mean? Just displaying some data and accepting some input,
or requirements are unclear? No js required. Now they want some interaction,
like a hover effect? Use vanilla js, jQuery, or plain css. Requirements keep
changing and you have more the 25 lines of js? Maybe start thinking about
vuejs to enhance the page and using a simple script tag. Starting to have
several hundred lines of js and you can't remember where in the file that
function is, or you are required to minify? Start thinking of vuejs plus a
build tool.

Do you need js everywhere? The answer is almost certainly no. Do you need to
enhance a page with js? That's about a 50/50.

Obviously this is just my advice, but was born from working on small teams, at
startups where requirements are often unknown, change frequently, and time to
market matters.

~~~
jkoudys
Plenty who will disagree and say they do want JS everywhere. I can build my
dom much more cleanly using nice declarative js than html with all its silly
and inconsistent rules, and letting react do the rest. I'm happier writing my
style rules as objects, then having emotion apply it to style elements. Much
happier using JS for everything than some old html+CSS that uses JS to add a
few bells and whistles.

~~~
was_boring
I gave you an up vote, because that's the great thing about this industry --
there are many valid opinions and options for each problem. Its more about
balancing tradeoffs then anything else.

Mine stems from working in the industry for nearly a decade, and shipping 100%
js projects in a variety of frameworks (angular, react, vue and backbone to
name a few). Most of the time, but not all of the time, I see iteration and
maintenance costs far exceed simpler js enhanced pages.

If js everywhere works for you and your team better, then that's what you
should do.

~~~
jkoudys
Oh I've been around a long time too, and I've definitely had that experience
in the past. Presentation logic was the really _big_ one years ago. Few devs
seemed at all bothered if their views were extremely complex, contained
heavily nested conditionals, poorly componentised, etc. Presentation wasn't
seen as "serious" code, because real devs did backends. As a result, so much
of our available tools, libraries, docs, blog posts, etc. were valued based on
how quickly you can churn out something that matches some mockup at one point
in time, and that's it. You'd never make any significant updates, only create
new pages to replace it. In this world, a completely separate dev (or
designer) would throw together the HTML/CSS and the ecma dev would link up
some events to the buttons.

I've really seen it flip after React matured, and everyone started transpiling
w/ bundlers. I don't have some `colors.scss` with a bunch of constants, and
then redefine those same constants in my .js anywhere -- I have a .js file
with my palette. I don't embed logic into the template with a bunch of `<div
ng-if` stuff anymore, I can use the same `if` I use everywhere else. All my
static analysis for unreachable code detection, style guides, etc. runs the
same everywhere.

I'd argue that those "simpler js enhanced pages" aren't so much simpler, as
they are merely more familiar. 1 consistent approach in one language, that is
equally (or more) suited for declarative code, is simpler than 3 languages
with 3 approaches. One module that says `export default css({ p: { fontSize:
'16px' } });` then importing it into another file is simpler than some scss
`.MyBigClassName { p { font-size: 16px; } }` then remembering that classname
in your HTML. `h('p', { onClick }, 'Hello!')` (or `<p
onClick={onClick}>Hello</p>` in jsx) isn't more complicated than `<p
class="foobar">Hello</p>` and some js elsewhere that says
`$('.foobar').click(` or whatever.

I've taken this approach with my very intern/jr heavy team, and they all take
to it really fast. It tends to be the older devs who are more resistant,
because it requires changing old habits.

~~~
was_boring
> I don't have some `colors.scss` with a bunch of constants, and then redefine
> those same constants in my .js anywhere -- I have a .js file with my
> palette.

Thank you for your reply. Do you have an example repo of using this pattern?
I'm afraid I'm not terribly familiar with _not_ having any css files and
instead defining it in a js file. create-react-app maintained by facebook
doesn't seem to follow this pattern (unless I'm misunderstanding).

~~~
jkoudys
[emotion]([https://github.com/emotion-js/emotion](https://github.com/emotion-
js/emotion)) is the main lib doing it now -- it's pretty popular among the
React crowd, and sits at 5k stars right now. It's a nice, gradual transition,
since it mostly follows scss-like syntax, and the docs all use tagged
templates. e.g. `const className = css\\`p { font-size: 16px; }\\`;`, but
`const className = css({ p: { fontSize: '16px' } });` works fine too.

What's cool is you can use the same obj conventions for the CSS as a React
component's `style` prop, or a regular Node's style. e.g. if I have `const
headerColor = { color: '#ff0000', backgroundColor: '#00ff00' };`, I can say
`<div style={headerColor}>`, or
`Object.assign(document.querySelector('p').style, headerColor)` too.

------
vinayms
What's funny about the JavaScript world is that there are basically two
activities that happen: create yet another SPA framework and create yet
another "script" suffixed language in which to code and transpile. Nothing is
done to JavaScript itself at structural and semantic level. Even the standards
seem to focus too much on peripheral aspects such as spread, arrow function
etc which are no doubt useful but don't improve the language itself. The
language is still as flawed and imperfect as it has always been.

Why don't anyone think of incorporating at least the low hanging fruits for
which developers have to migrate to a different language and transpile? What
they do add is halfa$$ed, like _const_. It boggles my mind. I created an
experimental framework called JEEP to remedy the sort of things I am ranting
about. Jeep has been happening in several iterations since 2015 and before
every iteration I checked if the latest standards would make the framework
redundant but sadly the need for Jeep only intensified. Finally I posted the
2018 version here on Show and elsewhere and the response was staggering, in
that nobody gave a f.ck. I am not bitter, no, really, but just amazed as to
what people find interesting and flock to and what they ignore happily.
Admittedly, the framework is quite unconventional and needs some reading and
experimenting to be done in order to be fully appreciated, leave alone adopt,
and it may even be advocating the sort of things that an average JavaScript
developer is not interested in, but the sheer lack of even "what the f.ck is
this $hit" was astounding. Some stats: collectively there has been over 3500
views but only 2 comments and a handful of likes, stars, upvotes etc. I am
sure it will get attention eventually, hopefully sooner rather than later, its
been just 10 days yet, but the initial response is something that has made me
recaliberate the priority of an average JavaScript developer.

------
nelsonic
Does anyone else get the feeling this survey is designed/run (or at least
"sponsored") by the Facebook engineering team...? It's _heavily_ biased
towards React, GraphQL & co. with a token mention of Vue.js and Angular so as
to be less _obvious_. Of _course_ "the state of JS" is going to say "everyone
is using React" if the questions are _designed_ to collect that biased data...

~~~
Keyframe
What do they have to gain from it?

~~~
nelsonic
@Keyframe React/Relay/GraphQL/etc, are Fb's "re-interpretation" of several
Open Source technologies that already existed in the community e.g: Elm &
RethinkDB.

Facebook gains each time a developer uses their "stack" because they extend
the Fb ecosystem and widen the "talent pool" of potential engineers who can
work on Fb's data-harvesting and Ad machines.

So when a "survey" is designed to promote the Fb tools by people who use Fb
tools (scroll to the bottom of [https://stateofjs.com](https://stateofjs.com)
...) I cannot help but be a _little_ "skeptical".

Facebook are trying to _OWN_ the JS dev ecosystem just like try to _OWN_
everyone's personal data! And they are "getting away with it" because no other
(major) Tech company is doing anything to challenge them. :-(

~~~
Keyframe
Makes sense when you put it like that. Question here is why no other major
tech company is doing anything to challenge that. Microsoft might be the one
to step in, considering their JS involvement now.

------
jkoudys
I was surprised to see no mention of rxjs at all, considering observables (and
pipelines) are phase 2. Somehow ramda is there, though.

I'm hoping the results show a lot of passion behind koa! I love that approach
in general, especially since I find express pretty clunky for reporting errors
from async operations. It still seems like the public hasn't really taken to
koa yet, unfortunately.

------
tjholowaychuk
It has improved in some ways but it's still incredibly fragmented, maybe more
so with CSS-in-JS, TS, Flow, etc. Especially with the potential of languages
like Elm, Rust, Go and others via WASM, it's going to be very hard to justify
JS IMO—unless you understand the tradeoffs and still just prefer JS as a
language then that's cool, the others aren't perfect either.

------
christophilus
Odd how ClojureScript is in the survey, but Clojure is not listed in the
possible “other languages” section. Oh, well. We Clojurians are used to being
overlooked.

~~~
golergka
ClosureScript is trying to replace JS for areas where you have to compile to
JS such as front end and and Node.js, just as all other languages in that
category.

~~~
christophilus
They have another category of language, though, in which Go, Scala, etc are
listed but Clojure was not.

------
olivier_allouch
You definitely need to add parse-server.

------
mlthoughts2018
At the bottom of the page,

“Note: to improve results relevance, we keep track of data such as your
referrer, location, device, browser, and OS.”

Give me a break. _Obviously_ not relevant for a _survey_. Only relevant for
whatever bullshit they’ll do with this data later on, unrelated to the survey.

“To improve results relevance...” this is just pure contempt for site
visitors.

~~~
sgdesign
Survey author here. We didn't have the time to correlate device/browser/etc.
to other data points last year but we did use the location:

[https://2017.stateofjs.com/2017/front-
end/worldwide/](https://2017.stateofjs.com/2017/front-end/worldwide/)

Also I'm curious what kind of nefarious "bullshit" you think one can do with
browser statistics. Market special weight loss pills uniquely targeted to
Safari users?

~~~
mlthoughts2018
Are you crazy? People buy data sets with browser statistics and location all
the time, to augment other data sets that attempt cross-device user tracking.
The more instances of browser fingerprints I have, the better I can tie you
between different devices. I used to work for a company whose whole business
model was essentially to buy data sets like this and normalize, join and
aggregate them into much larger data products sold to third parties or queried
in mobile SDKs.

There are whole companies that exist just to collect and aggregate disparate
data sets like this to make cross-device advertising measurement more
possible. If you can only match 0.01% of the users in some ad campaign, then
being able to even just _double_ that fraction by also finding the same users
on other devices is hugely valuable. The signature of your browser stats,
location, and choice of what to browse absolutely can enable this matching,
and a host of other techniques (like matching to similar users if no exact
match is found, and using machine learning on huge sets of traffic data to
learn how to perform the matching).

It sounds like your lack of imagination is putting people at risk in a
disturbing way to me.

