Hacker News Reader

Comment by BinaryIdiot | Hacker News Reader

Same. ECMA changed to using dates a while ago and people are still saying "ES6" and "ES7". I've also seen people refer to all new syntax and features as "ES6" including things that in ECMAScript2017.

Honestly though I think ECMA has some of the blame for this. I don't think they do a very good job communicating changes and versioning.

View on HN

Yeah I think there is just a lot of friction when moving from the concise "ES6" to the lengthy, and somewhat awkward "ECMAScript2015". The fact that so many people still use the terms ES6 and ES7 gives others even less incentive to use the official naming scheme. Hopefully, it will iron itself out in the future.

What did ES5 change to then? I never heard. Honestly, ES2015 just seems odd to me.

I think its not just the length but the concept: Every other language has a normal looking version (Rust 1.12 announced! Java 8, etc). They had that with ES3, ES5, ES6, then decided (perhaps for very good reasons) to change to a unique (?) version scheme.

C and C++ also use years. For example, C99 was standardized in 1999. C++11 was standardized in 2011.

In my experience ES6 means "modern". Anything that wasn't there before 2015.

Considering we're encouraging everyone to use transpilers and features from the future, and that browsers will forever lag just a little bit behind, I don't think that's a super bad idea. Most programmers don't care exactly which features are in ECMAScript2015 and which are in ECMAScript2016 etc. All they care about is "Can I do this thing I saw in a code example? Oh cool, it works".

Detailed versioning is an implementation detail.

> Considering we're encouraging everyone to use transpilers and features from the future

Please don't encourage this. Transpilers have a huge set of dependencies and technical complexity. I know everyone is in a hurry to use the next standard ASAP but, especially for new people, I think transpilers should be recommended against. Otherwise now you now need a build process and you need to learn how to use map files to properly debug back to your original code not to mention being unable to properly debug on older / alternative browsers.

> Detailed versioning is an implementation detail.

For the engine sure but for everyone who needs the features they need to know what is supported when, etc. It's far, far more than a simple implementation detail.

It's a good point, they are complex. But on a team doing a complex spa, you'd need someone who's a tooling expert right?

> But on a team doing a complex spa, you'd need someone who's a tooling expert right?

I would argue no. Granted not everyone needs to be an expert on the tool chain and this ends up happening probably a majority of the time anyway but if most are ignorant how the tool chain works I don't think that's a good position to be in either. When a bug / misconfiguration issue rears its ugly head you need more than a few people being able to debug it. But even outside of that I think it's incredibly helpful for the developer to fully understand how something is going to be built and deployed.

I agree with what you're saying. You don't want to get stuck in a corner. That's smart and pragmatic. Perhaps an expert that mentors the rest of the team? I just don't see how we can do without software build tools. They are so common in almost every language/platform I've used.

> I just don't see how we can do without software build tools. They are so common in almost every language/platform I've used.

All depends on your use case. Honestly if you're working on a web app you actually don't need any build tools if you really didn't want to.

But ultimately I wasn't advocating for zero build tools. The way JavaScript works you can write your own scripts (I wrote my own, barely one page of code for minifying, packing, versioning, testing, etc) or use any of the systems if you want to. It's all not that hard. But I don't think only one (or small handful) of people should know how to use them and I think we can vastly simplify what some of them do today (looking at you, babel and webpack).

Ya that's true. I'd just really hate to ever see another 10,000 line jquery monstrosity ever again shudder lol.

I agree with you that writing build scripts and using build tools both are not very hard. Who finds them hard? I'm sure Babel and webpack could be improved. What would you propose for how to improve them? Thanks.

Yeah, there's also that the naming convention has changed formats so many times in the last few years too. People need to see repeated pattern for it to sink in.

Reply on news.ycombinator.com