Hacker News Reader

Comment by hoodoof | Hacker News Reader

>> I really hope I’m wrong

I have good news - you are wrong.

ES2015 at last makes JavaScript into a consistent, sane way to program JavaScript.

Providing a consistent mechanism for imports and modules alone justifies its existence apart from the many other fixes, tweaks and features.

In many ways ES2015 is starting to look alot like other modern programming languages - that's a good thing.

One of the great things about ES2015 is that it provides an agreed upon standard for solving many of the common problems with JavaScript that were previously solved in myriad ways. When there is a consistent way of doing something in a programming language then alot of the noise and confusion associated with the many old solutions disappears.

JavaScript needed to grow up. ES2015 does alot of the needed growing.

View on HN

> In many ways ES2015 is starting to look alot like other modern programming languages - that's a good thing.

That depends on how you view Javascript.

If you consider it a programming language, the growing-up is a good thing. Making developers more productive and all that jazz. Of course, core WATs in JS are at a deep enough level that they're going nowhere (backward compatibility folks!), and anyone who's not already invested in JS should have the sense to look elsewhere.

If you consider it a runtime for delivering applications to the browser, it's really not so clearly a positive. A more complex language means more lock-in to existing runtimes, more room for bugs, more wasted engineering effort supporting the moving standard, less opportunity for lighter abstractions or more declarative assets amenable to static analysis ...

>> A more complex language means more lock-in to existing runtimes, more room for bugs, more wasted engineering effort supporting the moving standard, less opportunity for lighter abstractions or more declarative assets amenable to static analysis ...

Sorry you've lost me on this one - I'm sure "complex" is the wrong word and how the rest of your conclusions follow mystifies me.

So, you don't use any features added to any of the languages you use in the past 20 years?

Did it need to grow up, truly?

The module system needed to be sorted out, sure. Some of the rough edges around Number and Array, sure.

But let's not kid ourselves...everything else being added is basically just gravy, and it's gravy that sometimes comes at the expense of readability.

Just because it's not "a modern language" doesn't mean it isn't quite good at what it did--we still use C for that same reason.

Exactly my sentiments.

The module system is definitely needed.

For better or worse, npm's already become the defacto JavaScript package manager. It works automatically with every environment outside the browser and we're fine using whatever module system that is compatible with it in the browser. (I use Browserify)

These tricks aren't really new. We had them in ES5. The syntax may be easier to parse for experts .. people with multiple languages under their belts ... but these changes aren't really newbie friendly.

Is the new syntax worth it?

I'm a JavaScript newbie - the precise reason I choose ES2015 is because I am a newbie.

A modern language has features that make things easier for newbies. Modern should equal sensible, not incomprehensible.

Consider for example the module and import system - this dramatically reduces the complexity of the overall application and allows it to be structured in a modular and well organised manner. That makes things easier, not harder and more complex.

Again, I'll fall back on C here: C is a pretty simple and easy language, and before newbies were told that they were newbies and that C was hard a lot of useful program code got written by newbies.

Javascript, let's pick ES5 because it's convenient, is a generally accessible language. Like, we've built the entire modern web with it and without more fancy things, and it's been great.

Modern languages don't have things that make things easier for newbies--they have things that advanced users "think" they would've found useful earlier, they have things that advanced users who need speaking and conference gigs would prefer to have to present on, they have things that runtime writers would prefer to have for their microbenchmarks, and so forth.

Don't think for a second that any language features added are done for the benefit of new users.

Taking your module example: look, it's braindead simple (because it's a braindead implementation, honestly) to make an ordered list of modules and includes in JS. You learn the IIFE pattern, you order your script tags, and you're done. Once you have a little more genuine size in your app, you move to preprocessing your scripts, maybe just with make and cat--I've done this, it works fine. Only later do things get really complicated.

The nutziness of the current environment is that the developers are truly so fucking lazy and shinyphilic that they can't take the damned time to learn the old ways--the simple, obvious ways!--and then use them. Slow is smooth, smooth is fast.

You're new to JavaScript, but you're not new to programming.

That makes all the difference in the world.

Would you recommend Haskell, Erlang or arguably Go to a newbie programmer?

JavaScript has the benefit of being one of the most accessible languages these days, thanks to it being available in browsers.

Some people's first glimpse of production code will be from view source.

The myriad of "things a real language needs" is confusing and module systems neatly package up these crucial bits of technology.

Module systems are accessible to experts. Why not put enhancements there, rather than bake them into the language with no way to retract them?

What languages do you use that have not added features to the language for 20 years that you happen to use regularly?

It's not about refusing to use new language features.

It's that these aren't new features; they're old features with new syntax.

That's why Babel can transpile it. It's a case of old feature new syntax.

Exactly why I'm not taking any efforts to use Babel. I got no problems with .bind(this) and webpack. I don't need another task running just for some syntactic sugar.

Having actual class declarations and inheritance makes readability suffer?

https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/spr...

Reply on news.ycombinator.com