Bundling new (existing) languages with the default ("common") CDN build

[joshgoebel]

Currently the plan is to include the following new languages:

• Dockerfile
• Go
• Kotlin
• Less and SCSS
• Lua
• Plaintext
• R
• Rust
• Swift
• Typescript

.. and to remove none.

This brings the default bundled size up from 50kb (CDN copy) to around 75kb or so (which still seems trivial to me, since it's pre-gzip). Powershell was on the possible list but weighs in itself at a whopping 35kb (so many keywords). Once we decide to add them we're probably stuck with them for quite a while...

If anyone would like to share any thoughts, feel free. There is additional discussion here: #1119

I created a new issue for a bit more visibility.

Plan is to sort this out soon so the 9.15.11 release would include these new options and have a larger file size.

[joshgoebel]

After we have a more refined build process I'm still interested in releasing a LARGER build also... and then I'd throw a bunch of other things in there that aren't huge but you've probably heard of. That build idea is currently running around 135kb.

[joshgoebel]

@egor-rogov Any objections to a "Highlight.js already has support for KOTLIN, are you loading an extra language file that you now no longer need?" in console.log for people who upgrade but don't remove the extra JS reference they now no longer need? Would that be helpful or noisy?

[egor-rogov]

Umm, what is that extra reference you are talking about?

[joshgoebel]

Right now if they are loading an extra js file from the CDN to support these languages. After this they would be just wasting time and bandwidth.

[egor-rogov]

So it's true not only for Kotlin, but also for any other "promoted" language.
We were discussing a possibility to show somehow that a requested language is not available (#1569). Maybe we need the same sort of warning for a twice-registered language?
I don't think console message is very efficient.

[joshgoebel]

Yes.

Well often it’s a visitor seeing the content. Not the sites author. You don’t want to break their experience. Red error messages would be a bad look for what isn’t a serious problem. Just annoying.

[egor-rogov]

It may be yellow, not red (: And disappear in several second, for example.
Do you think the author will read log messages if he ignores release notes and he's own site content?
I'm not against some console output, just don't believe it's useful.

[joshgoebel]

I'm not against some console output, just don't believe it's useful.

The only two choices in my opinion are console output or nothing - not some sort of visual thing. I agree it's probably mostly useless. :-) It would have to be a VERY serious problem before I'd bother a sites readers/users about it.

[tajmone]

@egor-rogov:

I'm not against some console output, just don't believe it's useful.

Agree, but it won't be harmful either.

@yyyc514:

The only two choices in my opinion are console output or nothing

Then it's about making the console output appealing somehow — e.g. to style the console output element to mimic the look of a real shell window, with borders, a scroll bar, a top bar, monospaced font, etc. Something along the lines of the consoles shown here:

• http://web-console.org (just an image, to show how it would look like)
• https://asciinema.org (an example of animated console inside a web page)
• https://bellard.org/jslinux/vm.html?url=https://bellard.org/jslinux/buildroot-x86.cfg

It could then be perceived as a way to represent the build process in the browser. For users who are not interested in it (and don't understand it), it might be a way to get a feel of how the building process looks like from the developers' perspective. For those who are acquainted with the nitty-gritty of HJS build system, it might provide real-time useful information.

[joshgoebel]

Are we reading the same issue? Lol. This is about how to best communicate to a developer whose using highlightjs that they may need to change their code to include a few less files. But the developer typically isn’t the one reading the webpage. It’s some random Joe who definitely doesn’t need to be bothered about this.

I thought a console item might be nice for the more attention to detail developers who care about such things. I know they are out there.

[joshgoebel]

@egor-rogov Since we'll find it MUCH harder to remove languages than to add them I'm going to yank R and Dockerfile. Leaving the adds:

• Go
• Kotlin
• Less and SCSS
• Lua
• Plaintext
• Rust
• Swift
• Typescript

Easy enough to add more later and this feels a little more tightly focused. Pretty soon I also want to see about having a "larger" prebundle, so that should reduce pressure to keep adding things to the smaller bundle. If someone wants "the kitchen sink" they should use a larger bundle (where we could throw in all the popular functional languages, etc).

[egor-rogov]

Hmm, aren't they quite popular? No fundamental objections, though.

[joshgoebel]

HAHAHAH, now you want to weigh in after saying it was up to me? :-)

I'm not sure... but they don't feel "general" to me... if I could go back I'd likely remove Apacha/Nginx from the default bundle, feels a little "system"... but my point was it's gonna prove harder to take things out - and no one here is clamoring for anything. So I say be a little more conservative.

If someone comes along pushing for one or the other we can always add them in the next release. :-)

[egor-rogov]

HAHAHAH, now you want to weigh in after saying it was up to me? :-)

Nope. Just had to reply somehow since you mentioned me in your comment (:

[joshgoebel]

Ah. It was just a heads up. Closing with #2204.