Convert libraries to use ES6 syntax

Change Proposals
#1

Should we update libraries to use ES6 arrow notation for curried FFI?

Old:

exports.log = function (s) {
  return function () {
    console.log(s);
    return {};
  };
};

New:

exports.log = s => () => console.log(s);

I’d like to recommend the latest best practices in the FFI section of the book, but I also want to make sure the referenced libraries follow these best practices too.

Full purescript-console update PR for reference.

1 Like
#2

As per my comment on the PR, I don’t really see a reason to go through and do this. Changing the syntax doesn’t improve anything materially and the libraries will no longer work in some situations where they used to.

It’s true the return {};s can be dropped though.

2 Likes
#3

I would argue that the best practice here is to stick strictly to ES5 in FFI code in libraries. If you don’t, you may be forcing downstream users to set up Babel or something if they need to support older browsers. You shouldn’t really be doing anything complicated enough in FFI code that ES6 syntax makes any real difference, I think. If you’re writing an app, however, you can do whatever you want, because you know what your compiling/bundling setup is doing.

1 Like
#4

That’s a fair distinction between writing libraries and writing your own app. I’ll incorporate that point in the book.

I’d be surprised if anyone truly concerned about reaching the 6% of browsers without arrow function support doesn’t already incorporate Babel in their deployment process.

#5

I’m not going to test it myself but I would like Try PureScript to work in IE11, and I would consider it a bug if it didn’t (provided that it was fixable without having to do something atrocious). Try PS doesn’t use Babel, and I’d very much like to keep it that way.

#6

In any case, it’s not really our place to make assumptions, I think.

1 Like
#7

Is the intersection of aspiring PS users and IE11 users non-zero?

#8

I don’t know for sure, but I think there’s a pretty good chance that somebody at some point has wanted to use it from IE11.

1 Like
#9

I don’t really think that “people who target these browsers already use Babel” is really that valid of a point anyways, because by moving to something like PS you are able to largely replace babel. If folks were to change to writing ES6 code for FFI then that would no longer be true. Meaning that this advice slightly improves the prettiness of FFI code at the cost of forcing you to introduce an entire extra compiler in your toolchain in cases where you would otherwise not need it.

I’d prefer the uglier FFI code.

#10

If your browsers don’t support modules natively you already need a bundler, whether you’re using modules or commonjs. That might be purs bundle, webpack, parcel, etc. Presumably if purescript switched to module-based ffi the bundler would change in the same release, and the rest of those tools support both.

Requiring commonjs for all of the PS pipeline makes it impossible to emit modules for tools which can take advantage of module (browsers, parcel, etc), but the reverse isn’t true.

#11

Moving from commonjs to ESM is a different discussion, and there’s no disagreement on that. When ESM happens, purs bundle will learn to parse ESM, and so the output of the simplest workflow not requiring you to bring in any additional tools — purs compile followed by purs bundle — will continue to work in all the browsers that it currently works in, including those that support neither arrow functions nor ESM.

2 Likes