4 ms·
The problem with Javascript IMHO is that it's difficult to say "enough". As someone who uses it everyday and loves it, I believe it's in a decent place now, but
by franciscop 5y ago
The problem with Javascript IMHO is that it's difficult to say "enough". As someone who uses it everyday and loves it, I believe it's in a decent place now, but it keeps adding more and more strange operators that virtually no one uses or has use for in everyday applications. Things like Symbols, BigInt, etc. are way too rare in JS and only useful under certain "ideas of workflows" to be worth being part of the core since they introduce a whole incompatible layer of dealing with things and don't mix well with the rest of the language. I'll even throw "classes" and "generators" to the list of things that were a mistake, as time has shown.
This is the same with the pipe operator, we already have arrow functions, thenables, and TWO different types of .pipe(), which makes syntax a lot cleaner when needed. IMHO adding this pipe operator "|>" would be a mistake, it only complicates the language making:
- Browser competition harder, when the language is really broad and difficult it makes it harder to create a new engine.
- Mastering Javascript harder, there's a lot broader amount of concepts there which are not really useful except.
- No real benefit as I explained. For some people's worldview it's better, but for us the rest of mortals[1] it's just overhead.
A really good indicator of whether something is useful in core JS is: has someone made it into a library or sublanguage[2] that is widely used? Or a language feature? Promises and events def passes that test, while Symbols, classes, generators and this new pipe operator definitely don't. Bigint is arguable, since it passes the test but remains fairly fringe use-case in JS.
[1] Note that I'm the first one to experiment with JS and try weird things! I'm just saying that these should remain broken experiments on my computer, or nice libraries in npm, but not part of the specification that no one uses.
[2] Coffescript, JSX, Typescript, etc.
- brundolf 5y agoI think it's important to separate two major categories of recent JS additions: 1) Advanced features that cannot be replicated without runtime support 2) Syntax sugar Symbols, BigInt, and generators are the former. Pipes and classes are the latter. (1) gives library authors access to low-level primitives that can allow them to do things that were literally impossible before (I've gotten a lot of use out of Symbols, personally), but they aren't often used directly in application code. (2) are usually more application-facing, and may or may not be a big enough quality of life improvement to justify their existence. I guess what I'm saying is: just because you haven't seen lots of Symbols or generators in the wild doesn't mean they aren't having an impact, or weren't worth adding.
- jamesknelson 5y agoTo add to this point, it’s quite likely that the vast majority of JavaScript developers are using generators and symbols, whether they realize it or not. The reason is that your build system of choice will typically have been compiling async/await into a combination of generators and iterators for years now. It’s probably getting to the point where it’s no longer necessary in a lot of cases, but these constructs that “nobody uses” were able to implement the newer and more widely features long before they were available in browsers.
- valand 5y agoMore point to add: (1) Adds more possibilities, performance improvements, operational shortcuts. (2) Adds redundant way to do one thing. IOften confuse more than help in the long run. The former also should not be excluded from application code. Application coder should also be familiar with what those are for.
- franciscop 5y agoThere's libraries to work with BigInt without "runtime support". Arguably Symbols and Generators cannot get there 100% of their features without runtime support, but for the vast majority of usecases out there (Symbols as a unique keys, generators as a stream of data) there are many ways of doing that with JS without the need of these constructs that are just as clean. For instance, Symbols solve such a very edge case (key collision) that IMHO it's def not worth creating a whole new abstraction for it. > they aren't often used directly in application code The problem for me with this is that abstractions leak, and suddenly you are wondering why you cannot add two simple numbers or why there's a 3rd level of hidden properties in objects.
- jimmont 5y agoThe teams working on evergreen browsers seem to be the more effective place for vetting the continuum between and including 1 and 2--they do remove features. Certainly better than the various experiments across the Internet (including the black hole npm).
- chana_masala 5y agoThis is a well reasoned perspective. After async/await I stopped obsessively keeping up with new JS features. The biggest thorns were gone. Regarding classes, intuitively I agree, but I'm curious about your reasoning.
- john567 5y agoI lost it over conditial assignment. That is absolutely something I have no intention of using ever. Also, JavaScript has some rather quirky behavior. I'd rather see a stricter JavaScript without the quirky stuff take it's place. FYI, symbols are incredibly useful!
- edem 5y agoYou use "no one" too much. Everyobe around me uses all of those and I'd definitely use the pipe operator.