Thought more about it. Here’s some additional thoughts.
“Progressive enhancement” was an notion relevant to an earlier generation of web applications. Traditional web frameworks treat the internet like a souped-up fax machine. Pages were cooked up on the server and the presentation sent over HTTP to the dumb-terminal-like client. The problem has always been that HTTP was the wrong protocol for the web. It’s stateless, session-less, and basically uni-directional. For decades in enterprise we’ve had rich desktop clients which consumed data sent over the wire using stateful, bi-directional protocols (RPC).
We’ve been working around HTTP for over 20 years. Like adding JavaScript to handle client-side data validation so that we didn’t have to make a round-trip to the server, because re-rendering the whole page was so slow and inefficient. Then we added things like AJAX so that we could load in bits of data at a time, like populating the cities for a selected country.
What makes Meteor so revolutionary is that they’ve address the fundamentals of these issues rather than continuing to workaround them. DDP is everything that HTTP isn’t. It’s provies session-based, stateful, bi-directional communication between your app and server allowing the app to me located closer to the user, rather than centralized on the server like in mainframe architecture. You see this same approach taken in native mobile apps–the rich client app runs on the phone and only bit of data are sent back and forth over the wire. Client/server development in enterprise has been doing this for decades.
This is another matter entirely but Meteor also elegantly addresses the single biggest difficulty in developing web apps, which is keeping data in sync between clients and the server. In a traditional framework like Rails you might use ajax to load some data into the client for presentation. You might store it somewhere like in HTML5 cache or in a backbone collection. Then once the user modifies it, you’ll need to see if something change on the server and figure out how to handle that situation. You do this on an ad hoc basis in those frameworks.
Meteor solves the problem of keeping data in sync between the client and server by making the data you need transparently available everywhere. In the client the data is stored in a database (holy shit!) which you can query–a far cry from a simple static array or collection. The data you need it loading into that collection for you, changes to that data are instantly reflected in the client (reactive templates) and pushed to the server for you. And changes on the server are pushed down to your app (with templates reacting accordingly).
This kind of experience (for both the client and the developer) is often well worth some start up lag. I’d rather move forward and figure out smarter ways to improve application loading (cdn, rendering optimizations, progressive fragment loading, pre-loading data) than go back. We’ll be helped along as processors and transmissions speeds improve, and I think just as people are used to waiting a moment for their mobile app to load, they will get accustom to waiting a moment for a rich web app to load (a la Slack, Asana, Google Docs, Trello, Pivotal Tracker, etc.). These apps can be slow to start but very snappy once loaded, and they offer a new level of near real-time collaboration and reactivity without having to hit the refresh button like traditional web development frameworks. After working with Meteor for more than two years I’m flabbergasted why so many apps require a refresh before you see data changes. It’s so easy to development them in Meteor to be reactive.
Also many sites like blogs should load as fast as any PHP site since there isn’t a whole lot of template logic to load in the first place.
Of course we care about performance too. Our many small Meteor apps are quick to load, but we are in the process of splitting a large application in two. The idea is to separate in-house (backoffice) features from customer-facing features. Both apps will connect to the same database, but no sense in sending features down the wire to the client that they don’t have permission to use them anyway. Probably 80% or more of the code is for our backoffice team, so the client interface is going to be very light after our refactoring.
Meteor is still very young (version 1.1) and getting better all the time. The community is actively working to address these issues and some solutions already exists. Like fast-render and spiderable packages.
Progressive enhancement basically seems to assume a paradigm in which JavaScript is just a bit player used for enhancements to the interface and nothing too important. But those days are over for many of us, and progressive enhancement is dead.
