Streaming live at 10am (PST)

Css file load order in Meteor

Hey guys,

I just used a Webflow layout in a Meteor app, which handles packaging up all the bits to be sent to the client and shipping them down. Instead of manually defining <link rel="stylesheet" ...>, Meteor minifies everything, sends it to the browser, and evaluates it for you.

One quirk that comes as a result is that you no longer control load order of resources by where in the document they appear. You can control the load order by naming / structuring your app such that Meteor will minify things in whatever order you want, but you are encouraged to make sure resources can be loaded in any order instead.

So, to the point: I’ve discovered that the load order of webflow.css and .webflow.css is actually significant. That was a bit of a surprise, since I learned the hard way years ago about CSS’ “specificity” rules. I guess both files contain equally-specific rules.

Would love to know if I’m wrong about this - but otherwise it’d be a nice (albeit low priority) thing to fix.


1 Like

@thunder After looking through the Meteor docs, you are correct- the CSS files are being loaded in a different order than one might expect.

Meteor outlines their rules for this behavior as follows:

The JavaScript and CSS files in an application are loaded according to these rules:

  • Files in subdirectories are loaded before files in parent directories, so that files in the deepest subdirectory are loaded first, and files in the root directory are loaded last.
  • Within a directory, files are loaded in alphabetical order by filename.
  • After sorting as described above, all files under directories named lib are moved before everything else (preserving their order).
  • Finally, all files that match main.* are moved after everything else (preserving their order).

Based on the above, I would recommend that you move the two library CSS files into a subdirectory named lib, so that your new file structure looks like this:


Hopefully that helps get you on track. Good luck with Meteor!


Hey guys!

Thanks so much for the help. I have it working, it is indeed easy to restructure the project files to affect the load order.

What I was trying to point out, though, is that it was surprising. So if it’s not feasible to write the rules differently so they are commutative, then perhaps a bit of documentation with a link from the code export window? Again, low priority, just thinking to save future users from the surprise.

Thanks again! Maybe I’ll write something up about using Webflow + Meteor. It’s great so far, only thing I haven’t gotten working is the js interactions (no big surprise there, I’ll just reimplement them I guess).

I think I have a hunch what might be going on with the front-end JS as well.

Since Meteor is essentially a single-page app, you would need a way to re-trigger the webflow.js “ready” event on all the modules, each time the virtual routes change.

We do have a fix for this in the works… let me see what I can do about getting it merged into production for you :wink:


Oh, that would be hot! Thanks :slight_smile:

Btw, on load order - I found another method that I like: meteor packages. It’s possible to define a small “package” with a js file that describes it’s runtime load order/dependencies, and other stuff. Very clean solution, meteor makes sure things will be shipped to the client in the right order. I’ll publish my solution as an example for others to copy.



Hi @thunder, we pushed an update to webflow.js which improves support for single-page apps.

Whenever you are rendering a page that contains webflow components (slider, navbar, etc), you will need to initialize them. On typical sites, this happens in the jQuery.ready handler. However, in single-page apps the HTML is being built dynamically.

We’ve added a method to manually invoke the ready handler on all components. This should be called after your HTML is inserted into the document.


Once the elements are initialized they should behave as they normally would in a webflow site.

Just before the route changes in your app, you will want to prevent those components from updating. You can do this by calling the destroy method.


Once the route has changed, you can call ready() again, and the cycle starts anew.

Hopefully this makes sense! Good luck with your meteor app.



I thank the OP for asking and you for replying.

Rogan Richeart

1 Like

Hello Thunder,

I’m writing at the moment my own chat tool and I’m really interested in your experiences with the combination of webflow and meteor. How you handle the changes if you have translated the code to templates. I’m not sure at the moment to use this combination. Could you use the animations ? is the generated code quality good enough for further maintenance ? I’m look forward to get an answer. Thanks

best Marcel

Hi Marcel,

I used it for a while for a little project, but have put that on ice - so I don’t use it anymore. My other projects are simpler, so I just host the flat files with almost no server-side component at all.

My $.02 - it was possible to make things work, but a little finnicky. I didn’t get animations working (but I didn’t try hard / care much for that project). Overall, I do not recommend it… though I don’t have any great alternatives. If you do want to make this kind of a setup work, my ‘site-update’ tool may help you:

I no londer use it either, but it should work. I wrote it for this purpose.


Hello Dan,

Thank you very much for your answer. I have checked your site-update tool and its look really nice. I will try to move forward with web-flow because I think for the first layout it will save me time.

I hope I get the animations running. Perhaps with the webflow.ready method after rendering.
If not will open a case in the forum.
Perhaps it is possible to trigger then manually?

Have somebody an idea how to do it ?

Best Marcel

@thunder - did you keep the meteor app running with webflow? What was that process like? Did you write about it?

Hi Eli,

I didn’t end up using that combination, and didn’t have the time to write about it.

You can integrate them, and the site-update tool I wrote (see above) helps to make it repeatable, but it takes too long / is too much work to do the integration that way. In the end, I think you’ll be better off either choosing between webflow/meteor, or resigning yourself to prototype in Webflow and integrate changes into Meteor by hand. Keeping some documentation will help you there in case you don’t touch a project for months or have multiple people involved.

Good luck!

1 Like