mirror of
https://github.com/meteor/meteor.git
synced 2026-05-02 03:01:46 -04:00
e24eec2084
Ever since Meteor 1.5 first shipped, dynamic modules have been fetched over a WebSocket, which is appealing because sockets have very little latency and metadata overhead per round-trip. However, using a WebSocket requires first establishing a socket connection to the server, which takes time and may require a WebSocket polyfill. An even more subtle problem is that we cannot use dynamic imports in any of the code that implements the ddp-client package, as long as the dynamic-import package depends on ddp-client. By switching from WebSockets to HTTP POST requests, this commit radically reduces the dependencies of the dynamic-import package, while preserving (or even exceeding) the benefits of socket-based dynamic module fetching: 1. The client makes a single HTTP POST request for the exact set of dynamic modules that it needs, which is much cheaper/faster than making several/many HTTP requests in parallel, with or without HTTP/2. 2. Because the client uses a permanent cache (IndexedDB) to avoid requesting any modules it has ever previously received, the lack of HTTP caching for POST requests is not a problem. 3. Because the HTTP response contains all the requested dynamic modules in a single JSON payload, gzip compression works across modules, which produces a smaller total response size than if each individual module was compressed by itself. 4. Although HTTP requests have more latency than WebSocket messages, the ability to make HTTP requests begins much sooner than a WebSocket connection can be established, which more than makes up for the latency disadvantage. 5. HTTP requests are a little easier to inspect and debug in the dev tools than WebSocket frames. 6. The new /__dynamicImport HTTP endpoint is a raw Connect/Express-style endpoint, so it bypasses the Meteor method-calling system altogether, which eliminates some additional overhead. 7. Fetching dynamic modules no longer competes with other WebSocket traffic such as DDP and Livedata. 8. Although the implementation of the /__dynamicImport endpoint is a bit too complicated to allow serving dynamic modules from a CDN, that remains a possibility for future experimentation. In other words, how modules are fetched is still just an implementation detail of the `meteorInstall.fetch` callback. 9. As with the WebSocket implementation, the module server is totally stateless, so it should be easy to scale up if necessary. I wish I had appreciated the advantages of an HTTP-based implementation sooner, but I think the transition will be pretty seamless, since the new implementation is completely backwards compatible with the old.
Meteor is an ultra-simple environment for building modern web applications.
With Meteor you write apps:
- in modern JavaScript
- that send data over the wire, rather than HTML
- using your choice of popular open-source libraries
Try a getting started tutorial:
Next, read the guide and the documentation.
Quick Start
On Windows, the installer can be found at https://www.meteor.com/install.
On Linux/macOS, use this line:
curl https://install.meteor.com/ | sh
Create a project:
meteor create try-meteor
Run it:
cd try-meteor
meteor
Developer Resources
Building an application with Meteor?
- Announcement list: sign up at http://www.meteor.com/
- Having problems? Ask for help at: http://stackoverflow.com/questions/tagged/meteor
- Discussion forums: https://forums.meteor.com/
Interested in helping or contributing to Meteor? These resources will help:
We are hiring! Visit meteor.io/jobs to learn more about working full-time on the Meteor project.
Uninstalling Meteor
Aside from a short launcher shell script, Meteor installs itself inside your home directory. To uninstall Meteor, run:
rm -rf ~/.meteor/
sudo rm /usr/local/bin/meteor
On Windows, just run the uninstaller from your Control Panel.