DEV Community


Discussion on: PHP 8 features I wish also existed in JavaScript

peerreynders profile image
peerreynders • Edited

#1 Named parameters

just doesn't feels like clean coding style to use an object inside the functions parameter definition.

Everybody's entitled to their opinion - but at this point using an (options) object and destructuring it is an established idiom which means that adding "real named arguments" would add more complexity to the language for very little gain.

just doesn't feels like clean coding style to use an object inside the functions parameter definition.

That's actually pretty common in languages that support pattern matching on the language level (pattern matching is a conditional construct, destructuring is not - example: Elixir).

#2 Match Expression - There is a TC39 Proposal ECMAScript Pattern Matching - as it is only at stage 1 at this point it may never happen.

That said your particular example could be readily implemented with a Map:

const fontWeight = new Map([
  [100, 'Super Thin'],
  [300, 'Thin'],
  [400, 'Normal'],
  [600, 'Bold'],
  [900, 'Heavy'],

console.log(fontWeight.get(600)); // "Bold"
Enter fullscreen mode Exit fullscreen mode

PS: the examples employing objects in this manner overlook that an object's keys have to be either strings or symbols - while a Map's keys can be any value. So using a number on an object as a key will result in it being coerced into a string.

Granted it would be really useful to have something like Rust's match expression or ReScript's switch (i.e. OCaml's match).

However Franceso Cesarini of Erlang Solutions observes that newcomers to Erlang have three hurdles :

  • The first hurdle is pattern matching.
  • The second hurdle is understanding recursion and the whole concept of tail recursion versus non-tail recursion.
  • And the third kind of hurdle is thinking concurrently.

i.e. pattern matching isn't something that people find all that intuitive, at least initially - though from what I've witnessed once they "get it", they can't get enough of it.

#3 Optional Chaining is part of ES2020 (June 2020), Chrome 80 (February 2020), Firefox 74 (March 2020), Node 14.0.0 (April 2020). (caniuse: JavaScript operator: Optional chaining operator (?.))

(Related: Nullish coalescing operator (??) - caniuse: JavaScript operator: Nullish coalescing operator (??))

devmount profile image
Andreas Author

Wow, thank you for these detailed insights 😍👏🏻 I really like how the discussion explodes here 😅

peerreynders profile image

FYI: Often the answer is Use Functions!:

function fontWeight(value) {
  switch (value) {
    case 100:
      return 'Super Thin';
    case 300:
      return 'Thin';
    case 700:
      return 'Bold';
    case 900:
      return 'Heavy';
      return 'Normal';

console.log(fontWeight(700)); // "Bold"
Enter fullscreen mode Exit fullscreen mode
tomaszs2 profile image
Tomasz Smykowski • Edited

3 - it means for 15% of internet users app or website using optional chaining will break because older browsers does not support it.

peerreynders profile image

Given that you are supposed to be practicing Differential Serving anyway it's a non-issue.

ESNext is transpiled down to ES2017 to yield smaller bundles for modern browsers while larger bundles transpiled all the way down to ES5 are available for legacy browsers.

A Universal Bundle Loader
Bringing Modern JavaScript to Libraries
Publish, ship, and install modern JavaScript for faster applications

Thread Thread
tomaszs2 profile image
Tomasz Smykowski

Still, the post is a comparison between JavaScript and PHP, and you write about EcmaScript:

  • 15% of users have browsers with JavaScript that does not support optional chaining
  • I have to use transpiler from EcmaScript to JavaScript to be able to use it

= JavaScript does not support optional chaining

Thread Thread
peerreynders profile image

JavaScript is nothing more than a trademark of ORACLE America, Inc. which they obtained through their acquisition of Sun Microsystem, Inc.. The trademark was licensed by Sun to Netscape and later to the Mozilla Foundation.

Other than that JavaScript is just a colloquialism to refer to the scripting language features that are used for browser automation. ECMAScript is an effort to standardize that scripting language. As it is, no browser claims to implement any ECMAScript spec in full - they only aspire to do so (and often they implement features beyond the spec).

Back in the day we used jQuery to bridge gap between the variations between different browser vendor implementations. Today we use Babel to bridge the gaps that have emerged over time. The more things change, the more they stay the same - so while the tools have changed, we still have to bridge gaps.

You are free to use whatever dialect you prefer - though I don't envy anyone who may have to help support your work.

But ES2020 includes the Optional chaining (?.) operator so it is now part of what people colloquially refer to as "JavaScript" - MDN lists it under the JavaScript Reference - and it is available to everyone to use via Babel.