Comment by fvargas | Hacker News Reader

Comment by fvargas | Hacker News Reader

Parent Full thread

I think ES6+ has done wonders for JavaScript and has made it a highly expressive language. It's true there are quirks and poorly designed aspects which can be confusing at first glance. But like with any language, once you understand how it works, you learn to work with it. Moreover, as the language continues to improve, many of those quirks become irrelevant.

It's important to understand that, by virtue of having been bestowed with a monopoly over the web, JavaScript holds a great deal of leverage as a language. If you want to develop for the web, you pretty much have to adopt JavaScript into your stack. It's no surprise, then, that Node became so popular. Being able to use that language you're forced to use for the client on the server and to run the same code has major benefits. The Node and npm developers got many things right to be sure. But Node and its ecosystem, by virtue of offering JavaScript, benefitted immensely from developers' desire to unify a previously disjoint part of their stack.

I find myself asking instead, how far will JavaScript's reach continue to stretch? Electron and React Native have become extremely popular. It's not just speculation, there is undeniable momentum.

I think ES6 is the worst thing that ever happened to JavaScript because it killed it's best feature: being a small language that runs everywhere.

Now when I want to use a JS library, I have to think: what is this author's philosophy about language extension? Are they going to start using some new feature that some other library I depend on is incompatible with?

You used to be able to run JavaScript anywhere on any device. Think about how powerful that is. We sacrificed that for supposed gains in "ergonomics".

People hate callbacks. People hate "this". But if you ask people who really learned how to use those things, they're not problems at all. They're only problems if you're coming from Ruby.

It's like someone took an Apple and said "this is gross, it's not juicy and tangy like an orange!" And then they soaked it in vinegar and wrapped in orange skins. Now it scores well on orange-ness but is that a virtue?

Who's writing native ES6 code? Support for IE8 is just now starting to slip in the community (due too old, mundane things like Object.defineProperty). Almost every package on NPM targets ES3. Also, IE never ran everywhere. Targeting IE8 is hard, targeting IE6 was a nightmare.

I can't speak for you, but I've worked at a few companies and done some contracts overs the last 5 years and supporting ie8 easily stopped around 2012.

Microsoft ended support for IE8 early 2016. Until then most open-source libraries supported it. I wrote an IE8-compatible application this year and only had to downgrade a few random libraries.

I see this misconception a lot in this thread. "Yes, people say the language has problems, but there are people can work around the problems, so they aren't really problems!"

The very fact that you need to learn to work with X means that it's a problem. Otherwise, all languages are just fine.

everything is stupid if you dont understand it. JS is pretty good at not getting in your way.

>everything is stupid if you dont understand it.

Some things are stupid even after you understand them, and JS has plenty of those, as its creator and its greater evangelizer both admitted.

There is no "stupid" and "clever". There's only "consistent" and "inconsistent". JS isn't very consistent.

I really don't agree, as a developer writing predominantly js. It's still pretty standard to compile es6 down to at least es2015 using babel or typescript, meaning js still runs everywhere. I've also literally never met anyone who thinks that callback-structured code is "not a problem". And you can work around issues of "this" and lexical scoping to the point where it isn't as irritating, but it's completely unintuitive to a new js developer, and IMO at least never stops feeling "wrong". There are also a ton of features aside from arrow functions and promises that completely change the way code is written for the better- off the top of my head I use ` string formatting, classes, let/const declarations, and module loading every day.

> It's still pretty standard to compile es6 down to at least es2015

Yea, but that means if I want to use your library, I need a build chain. It used to be I could just do require("you") or <script src="you"> and be done with it. That's what we lost.

Actually I need n buildchains, one for each npm module I use. And they better all be compatible and target at least one common runtime. And that better be a runtime I am comfortable deploying for my app.

> I've also literally never met anyone who thinks that callback-structured code is "not a problem"

Well here I am. Pleased to meet you. Might I also point you at: http://callbackhell.com There are many of us.

I think what this really shows is how much professional ES6 programmers live in a filter bubble.

This also explains why you think "just transpile" is a reasonable substitute for a simple, run-anywhere language. Professional ES6 programmers think everyone has 40 hours a week of paid time to spend maintaining a build chain.

Javascript+Node used to be one of few languages that you could use without a build system. That's no longer the case. Maybe the loss was worth it to you. Fine. Makes sense. I wish more people would just acknowledge something has been lost, and that amateurs are struggling now at the expense of pros.

I think you missed that the parent meant that libraries are compiled _before_ publishing. So even if the library is written with ES6 you can simply require it with no build setup.

Many (most?) libraries are not built that way. There are plenty of libraries that use async in their exports.

I agree with a lot of your sentiment. But there's still nothing stopping you from writing ES5 or even ES3 and just ignoring ES6. Thats what we do and it works great for us. And we build extremely high end interactive apps using virtual dom, webgl, etc.

that's really interesting - would love to know more about your JS stack and your project structure?

i wish i could upvote you 100 times.

> It's still pretty standard to compile es6 down to at least es2015

...aren't ES6 and ES2015 the same thing?

Yeah, they are. People get confused because ES6 === ES2015, "ES7" === ES2016. I sometimes make the same mistake.

If you transpile down to an old version of js, does it matter what language you're transpiling from?

The minute you decide to transpile, you no longer really using javascript, and this discussion isn't really relevant any more.

What are you talking about? ES6 transpiles down to ES5, and this is what people publish libraries as. The language version compatibility story is way better than it is for most languages.

Well, jQuery is the single most popular JavaScript library ever, with over a decade under its' belt, and going to be around for likely another. Its' style was not predefined by the JS language... It has a monadic style in nature... Likewise, JS didn't prevent coffee-script or transpilers...

That said, I still feel that not sending the event registration context (not just the target) in with the event is a mistake... escalated by the use of fat-arrow functions today. You never know where things will go.

As to callbacks, I think it provides a great base... allows for easy extension and progression. I do now prefer Promises where async/await is available or via babel.

Java 8 isn't the same as Java 3... it's changed... languages evolve, and JS has done so rather rapidly the past 6+ years... It looks to be settling in a bit now. Next will be the module support, and that shift will be more painful than everything that came before.

I don't mind the context class sugar... there are places where it makes sense, and far cleaner than the prototype syntax. I tend to only use it for UI components, and even then sparingly. Just the same, other parts of ES6+ have been incredibly great.

Reply on news.ycombinator.com