Skip to content

Conversation

ix5
Copy link
Member

@ix5 ix5 commented Mar 28, 2022

Reasoning

Recent changes (made by me) have (inadvertently) introduced ES6 1 Javascript features to the generated client code which are only compatible with "modern", i.e. post-2017 browsers.

This PR aims to make the client code once again ES5-compatible since it wasn't a conscious decision and we do not want to lock ~6% 2 of global users out of reading and posting comments just out of laziness.

See also discussions in #822 (comment), and sorry for making @Kerumen sad. If we decide to move to ES6 and other niceties, it should be a conscious decision backed by data and arguments, not my late-night copy-pasting.

Footnotes

  1. Also called ECMAScript 2015?

  2. Maybe just 4%, but still, out of a reported 4,6 billion internet users, that'd make 186,400,000 people...

ix5 added 3 commits March 28, 2022 22:00
Use ES5-compatible syntax instead
This way, we're not inadvertently dropping support for
pre-2017 browsers.

`const` and `let` are keywords that are only available in
post-2017 ES6 Javascript.
This change instructs the `webpack` bundler to express its
wrapper functions in ES5-compatible syntax, meaning Isso's
client side Javascript retains compatibility with pre-2017
browsers.

This change turns e.g. this arrow function in
`embed.{min,dev}.js`:
```js
/******/ (() => { // webpackBootstrap
```
into:
```js
/******/ (function() { // webpackBootstrap
```
@ix5 ix5 added client (Javascript) client code and CSS bug labels Mar 28, 2022
@ix5 ix5 added this to the 0.13 milestone Mar 28, 2022
@ix5 ix5 merged commit cc5f706 into isso-comments:master Mar 29, 2022
@ix5 ix5 deleted the js-no-es6 branch March 29, 2022 20:04
@Kerumen
Copy link

Kerumen commented Mar 30, 2022

@ix5 I don't understand why this is needed. Aren't we using Webpack for this reason? Can't we write our code in modern syntax and let webpack convert it for us? This is how every app and libraries does these days, I don't get why we can't do that. Disclaimer: I haven't dug into the codebase, it's just a random idea.

@ix5
Copy link
Member Author

ix5 commented Mar 31, 2022

Re: Your questions:

Aren't we using Webpack for this reason?

The move to webpack was mostly to enable testing via Jest and associated tools. It's a massive dependency carrying megabytes of transitive dependencies and I'm not happy about it, but it was a necessity of moving forward.

Can't we write our code in modern syntax and let webpack convert it for us?

Adding the following to package.json:

diff --git a/package.json b/package.json
index e481c7f..4049ac8 100644
--- a/package.json
+++ b/package.json
@@ -13,6 +13,9 @@
   },
   "devDependencies": {
     "jest": "^27.5.0",
+    "@babel/core": "^7.17.8",
+    "@babel/preset-env": "^7.16.11",
+    "babel-loader": "^8.2.4",
     "webpack": "^5.68.0",
     "webpack-cli": "^4.9.2"
   }

balloons the size of installed packages from:

$ npm ls -all | wc -l
830

to

$ npm ls -all | wc -l
1159

package-lock.json swells from 8363 to 10901 lines.

$ find node_modules/ -name '*' -print0 | wc --files0-from=- -l
[...]
1057313 total

1

While the current state is already very unnerving to me, adding even more cruft pushes the dependencies to a level that is not reviewable by humans any more.

This is how every app and libraries does these days, I don't get why we can't do that.

Yes, it seems that's the way the wind is blowing these days. But just as a reminder:
For 0.12.6, released just a few weeks ago, we had this:

    "almond": "^0.3.3",
    "jade": "^1.5.0",
    "requirejs": "^2.3.6",
    "requirejs-text": "^2.0.15"

Taking jade out of the equation (because we dropped the templating), we are left with just three packages which each have no further dependencies.


I'd like to underline that this PR only restores the status quo of syntax that was already present just a few weeks ago.

If this project is to move towards a new standard of JS syntax (e.g. ES6 and getting rid of the drop-in promise "polyfill"), it should be because someone can demonstrate the actual need for this. There has been a lot of enthusiasm for new and shiny DevOps tools, helper bots and the like, but I have yet to see anyone actually contribute any new Javascript test or an improvement to the client in recent weeks.

If the lack of "modern" syntax is actually preventing people from contributing, then I'm all for lifting this "restriction". But until there's good evidence, I see little reason to throw so many internet users under the bus (or to introduce a total of more than a million lines of code in dependencies).

Footnotes

  1. Yes, not all of that is code, lots is configuration and metadata, but still, almost impossible for a human to sift through and verify no rm -rf --no-preserve-root /, cryptominers or malware are present

@ix5
Copy link
Member Author

ix5 commented Apr 23, 2022

An updated data point:

Since making the Jest dependency an "optional" one 1 in d797bed, the amount of total installed packages is 166:

$ npm ls -all | wc -l
166

With babel dependencies added, we get 589:

$ npm ls -all | wc -l
589

Footnotes

  1. I did not know before that this could be done in package.json and that you needed to explicitly tell npm to ignore those packages with --no-optional)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug client (Javascript) client code and CSS
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants