Not including SockJS in the modern JS bundle was a nice bundle size
savings (28KB before gzip), but SockJS works better than a native
WebSocket for clients that are stuck in unusual networking situations, and
the fallback of using dynamic import() to load SockJS when the native
WebSocket failed was much slower than simply including SockJS in the
bundle and using it from the start.
Moreover, the new `meteor create --minimal` starter app does not use
socket-stream-client (nor DDP), so going back to including SockJS in both
the modern and the legacy bundles should have no impact on the minimal
modern bundle size.
If you want to continue using a native WebSocket instead of SockJS, you
can always pin the older version of the socket-stream-client package:
meteor add socket-stream-client@0.2.1
I missed these packages when publishing 1.6.2-beta.0, since I hadn't
bumped their versions in #9439 as I should have, so the release script did
not republish them. Because of this, 1.6.2-beta.0 will not be usable, and
so I will publish 1.6.2-beta.1 ASAP.
The boilerplate-generator version bump is patch rather than minor, since
the relevant changes to that package seemed backwards-compatible.
To save size in modern browsers, JavaScript bundles built for the
web.browser architecture no longer statically include the SockJS library.
That's safe as long as native WebSockets actually work, but what if
there's a problem with the network that necessitates falling back to
long-polling or some other SockJS strategy?
In those cases, we can load SockJS using a dynamic import(), which is a
little slower than including it in the bundle, but that's OK because the
module will be permanently cached in IndexedDB in production, and falling
back to SockJS should be rare in modern browsers anyway.
Note that this trick would not be possible if the implementation of
dynamic import() still required a socket connection! (#9384)
