[Discussion] Is an ES5 build/distribution necessary?

[puzrin]

Editor: Adding some answers here at the tope for anyone else who finds this with Google.

If you're using the library as a direct dependency

There is no need for an ES5 build if you're using the library as a first-order dependency. Just build us separately and drop the web build of the library directly into your project. (either as a separate JS <script> tag) or concat it to the end of your monolithic build. Simply:

# from any unix shell
cat highlight.min.js your_monolithic_js_bundle.js > final_build.js

And of course you can do this easily with a build system as well.

If you're using Browserify

Evidently you can simply enable the global option. [more details would be helpful]

---

The original issue:

Ref: https://github.com/highlightjs/highlight.js/issues/2501

As you know, v10 announced stop support of IE11. But, indirectly, published releases become not es5-compatible any more. If you have cases where es5 (babelified src) is still needed (except IE11) - please post here details.

Support of es5 may be considered for prolong if a lot of demand exists.

---

[Maintainer]: I know it's mentioned above, but just to be very clear this issue is NOT about IE11 (or other legacy browsers) support. The ship has sailed on that. This is only about whether there is value in proving a pre-build ES5 distribution to use with picky/older build systems that haven't caught up to ES6 yet.

[joshgoebel]

From my point of view, package demands could be isolated. Propagating those to app requirements (discussing bundlers) is out of scope (IMO).

Now that I clearly understand your goal I probably would not have said much of what I said and simply stuck with "Sorry, ES5 is simply not supported for IE and other browsers." :-) Oh well, water under the bridge.

IMO operating with guesses is not constructive. There is wide-used browserslist "default" preset. You may not like it or disagree with it. But some people prefer rely on it without care about details of each browser.

Every suggestion is a guess until properly researched, no? :-) I was merely pointing out that browserlists own "default" preset itself seems to mostly agree with our policy (once you remove a few outliers) to drop ES5. When it will finally match completely I obviously have no idea. I'll avoid guessing. :-)

Those comment was given in context you were giving advices without knowing details and side effets. Any your decisions about hljs are ok. But attempts to "intrude" into outer processes can make someone feel uncomfortable.

I offered some suggestions - most people appreciate this. You may take them or leave them. There is no reason to feel uncomfortable.

i will try multithreading support instead of written recommendations.

That's an idea! :-)

...i had to spend notable time for bundler changes... ... forced users like me to participated in hljs process...

No one is forcing you to change your bundle setup or forcing you to participate. You're free to leave.

At this moment, bundling to es5 is completely automated process with almost zero cost for you.

So it's ok when you make the suggestions, but not when I do? :-) Seems a bit unfair. :-) I've already addressed this zero cost myth. Implementation, maintenance and support costs are real costs. Time it takes to make hotfixes to deal with stupid ES5 only bugs in older browsers is real time that we don't get back. Asking people "are you using the ES5 or ES6 build?" makes diagnosing and triaging problems harder. "almost zero in a perfect world", maybe. "almost zero" in the real world in 2020, definitely not.

[joshgoebel]

This is past the point of being constructive though. You will continue to make the decisions you feel are best for your project, and we will also do the same. If there are any final thoughts lets air them then return this thread to resting in peace or perhaps helping @john-doherty if he still needs assistance :-)

[puzrin]

I'm giving you warning now so when things break you can't say it came as any surprise. You could be doing something about that today vs waiting for it to break tomorrow. But obviously that's your decision. :-)

I have a bit different long-term plan. Sate of browsers is not static. When es6 become really mandatory in hljs, browserslist may give complete different result, and changes may be applied wihout pain. Strategy of "doing nothing until possible" looks more attractive for me.

So it's ok when you make the suggestions, but not when I do? :-) Seems a bit unfair. :-)

Weight of suggesion is direcly related to "who will pay for it".

• When i suggest es5 build - i'm ready to help with PR and not bother you about es5-specific problems. It seems i'm responcible for my proposal.
• When i get advice to rewrite bundler... person who give such advice is not responsible for it.

Logic is simple and honest, IMO :)

I've already addressed this zero cost myth. Implementation, maintenance and support costs are real costs. Time it takes to make hotfixes to deal with stupid ES5 only bugs in older browsers is real time that we don't get back.

My suggestions are based on my experience. I respect your time and would never suggest "difficult" unpleasant things. See how many project i support in my orgs. IMO i have reasonable stat about transpile to es5. If question would be only in doing PR - i could do that.

I suggest a minimalisic thing - completely automated es5 build without support, "use on your own risk and not with ie11". That could be enough until better time come.

And of cause, i'm ok with simple answer "i don't like to support es5 build" :). In my eyes personal preferences are normal and don't need technical proofs.

[john-doherty]

Hi @joshgoebel, you're right that gulp was not the issue, it's more the gulp js minifier I'm using. The es6 only option is a blocker in my case, unless I was willing to do more than copy and paste it into my project. I did not have time, so went with prismjs.

I think that's the concern here, it's a potential barrier for new users - which could hurt future adoption. I don't know the codebase, but cant you just add a minified es5 version?

[joshgoebel]

Strategy of "doing nothing until possible" looks more attractive for me.

👍🏼 There are definitely some real merits to that approach for sure. :-) The UTF-8 stuff might land in Dec/Jan/Feb timeframe. We'll see how it goes.

Weight of suggestion is direcly related to "who will pay for it".

That is a good point. It would carry more weight if you were on the core team though and also required to deal with support issues, fixing ES5 bugs, supporting these obscure browsers, issuing hot-fixes, etc... I find that all too often the PR is only the "tip of the iceberg" when it comes to the actual effort of getting a thing done. Perhaps your experience is different.

I think personally I'm much less comfortable with "use on your own risk" vs "it works on modern browsers, guaranteed". Obviously a matter of personal taste and perhaps OSS philosophy in general. We're not preventing anyone from transpiling (or even using IE11). We're just saying "it might turn out poorly, so we're not going to assist".

Even if I were more receptive we already dropped ES5 support in April. We have a plan to use ES6 features soon that (afaik) either make ES5 not transpile not possible or require even more developer effort to maintain. So adding it back with the caveat "use at your own risk" just to take it away in a few months makes very little sense.

i'm ok with simple answer "i don't like to support es5 build"

Well, but I also think our reasons are sound, even if you happen to disagree or think it's the wrong choice. It's a decision made with a reason, not just a whim. :-)

[joshgoebel]

I don't know the codebase, but cant you just add a minified es5 version?

No. See entire discussion above if you want more context. Supporting legacy build system plugins (when there are good alternatives available) isn't a priority. FYI: There are Prism issues talking about dropping support for IE11 and ES5 also. (though I dunno their thoughts on transpiling)

it's more the gulp js minifier I'm using.

FYI: Terser works great with Gulp and fully supports ES6. Just FYI. We use terser for our own builds of Highlight.js. So if you decided to switch in the future you could do so easily with Gulp + Terser as your minifier.

I did not have time, so went with prismjs.

Prism.js is a great project with much to recommend it. :-)

[ljharb]

ftr, that prism issue you linked hasn't had much discussion in the last 2 years, except to suggest using a build process to preserve support for those environments.

[joshgoebel]

I edited my last post to remove the "soon" and make it clear I'm not speaking for the Prism team.

I didn't pay much attention to the dates more so than the overall direction... that ES5 is on the way out. I'm also not sure the age of the issues in this case is a positive sign. :-) As I said they might be more willing to transpile - though again I'm not 100% sure why if they decide to drop IE11 support. There were a bunch of interconnected issues about the future of Prism - I'm not sure if you looked at them all. Some would really like to user regex look-behinds (as would we)... that of course will certainly break ES5, though that's likely still a year or more out due to Safari's lagging support.

[john-doherty]

I saw it had regular commits and was still use by Stripe so grabbed that... If this was my project, my concern would be that dropping ES5 would eliminate this tool from been used by any SaaS/API company that wants to sell to large orgs (many of which are still running old browsers/devices).

[joshgoebel]

@john-doherty It's possible there might be room for a docfix here somewhere... ie "Using Hightlight.js with Gulp"... where we could mention to use Terser to minimize (vs xyz, which doesn't support ES6)... the problem is often build systems and their setups can quickly get very complex... but perhaps there might still be value in a list of "hints" to guide people... I just don't know where that would go off the top of my head... perhaps a build system guide? "Hints for using Highlight.js with different build systems"?

dropping ES5 would eliminate this tool from been used by any SaaS/API company that wants to sell to large orgs (many of which are still running old browsers/devices).

I think the ecosystem has room for more than one alternative - with different alternatives having different goals and focus points. We're better at some things, Prism is better at others - like being tiny, and supporting IE11. Users can choose which things they value more. We don't have to solve the highlighting problem for every last person, organization, and browser on the planet. We're ok being Apple and removing the floppy drive first. :-) We're happy solving (and well supporting) the 95% case.

Perhaps for such a company Prism.js would be a better fit. Or perhaps if they are truly a profitable SaaS business with a dev team and a support staff then they could maintain (and support, and open source, etc) their own ES5 port of the library. It's not (currently) an insurmountable task (by any means) - it's just going to get harder and harder as time moves forward.

[joshgoebel]

https://babeljs.io/docs/en/babel-plugin-proposal-unicode-property-regex

Wow, truly, people are ingenious... though the output of something like /\p{ID_Start}/u is just SCARY and I wonder if it wouldn't have potential performance implications (though maybe that's what happens internally anyways and \p is just sugar). And of course sorting out subtle bugs if the behavior between ES5 and ES6 ever diverged could potentially be quite an adventure. :-)

[puzrin]

The UTF-8 stuff might land in Dec/Jan/Feb timeframe. We'll see how it goes.

If you mean /u regexp flag - this can be transpiled partially or just left "as is" with "throw exception in old browsers". Minimal outer try/catch wrapper should silently dim regression. I mean, some old bowser will not highlight code, but your package will not trash everything.

Usually, there are possibilities to keep acceptable compatibility (not full, but still useable) with es5 transpiler without pain for development process. If you need help with this - feel free to kick me anytime with questions or PR requests.

[puzrin]

Wow, truly, people are ingenious... though the output of something like /\p{ID_Start}/u is just SCARY and I wonder if it wouldn't have potential performance implications (though maybe that's what happens internally anyways and \p is just sugar). And of course sorting out subtle bugs if the behavior between ES5 and ES6 ever diverged could potentially be quite an adventure. :-)

There are no serious perf issues. I'm author of this madness, and it works well. Not sure if 100% can be transpiled (problem is negative classes and /y).

But, for this package i would prefer throw exception instead of bundle size increase. Then the only case to fight is syntax errors on script load. Workaround is to use new RegExp('foobar', 'u') instead of /foobar/u. Probably this can be automated with small babel plugin.