It’d be cool if meteor 1.6 included a folder called “Landing” that automagically handled this use case… same way server, client and imports automagically tackle their use cases. There’s an argument for adding something like this into core meteor as 90% of apps built with meteor need this ability.
6 Likes
Yes, shipping that #@$ is priority, however for a product that is just getting out the door in 2017, there are so many ad tools available for instantly sending traffic to your landing pages that, at least for my purpose, being able to test and try different landing page approaches rapidly is important.
1 Like
using cookies solves the problem of confusing the user. people type in yourawesomesite.com and when they land they are either logged in or logged out. simple.
This is a fantastic idea and I’d imagine pretty easy for MDG to implement.
Yeah-- even if it was an MDG package that you could add (and not necessarily in core). I guess it gets murky because they’d have to include a server-side routing (and router) setup right? This is pretty easy if they target it to react (just use react-router) but if they’re trying to support blaze users, it gets more completicaly
Yeah right now one workaround is to just put a .html file in /public.
What are the main concerns with a Meteor-served landing page? Is it the overhead of an extra DDP connection, loading time of the whole app bundle, anything else?
Also having to use a mongodatabase for just having a landing page (while working on the app) sounds a little too much(even if you can get one for free at mlab)
EDIT: The appropiate sentence here is not “to use a mongodatabase”, but “having to keep mongo dependencies” don’t want to confuse anyone sthat read this in the future.
You don’t have to have a Mongo database to run a Meteor app. You can remove the mongo package and set MONGO_URL=whatever to prevent Meteor from even trying to use Mongo.
1 Like
Yeah but that sounds more like a trick ( i have used that ) than actively encouraging non-database sites (especially when you are working on a project and there’s only a landing page) since last time I checked even if you removed the mongo package some dependencies made it being included in the bundle (maybe it’s different now)
You can definitely remove the Mongo package and completely avoid including anything related to it! You’ve been able to do that since Meteor 1.2.
Well maybe I did something wrong then, but I have a deployed site (post 1.2, I think it’s on latests 1.3.x) without the mongo package and when I type Package.mongo in the console it still shows it.
This is the list of packages included
meteor-base
mobile-experience
blaze-html-templates
jquery
standard-minifier-css
standard-minifier-js
es5-shim
ecmascript
check
email
ddp-rate-limiter
force-ssl
and when I look into versions file, mongo is still there 
Think about scaling a business, too. You would likely put a marketing team in charge of the landing page, and they would probably want to use a well-known CMS to make updates to it. So it would make no sense to have the landing page be part of the Meteor app, as it would be less straightforward to make changes to.
Well, if meteor had such a feature, maybe developing packages to easily edit them would be an option (instead of having to use another CMS).
Anyway I have good expectations with 1.4.3 since I believe the problem of downloading all the bundle size can be solved with the async loader (code splitting). For the other issues mentioned I am not sure, but I think DDP and mongo dependencies are quite tight to the core/Blaze and are gonna be there until npm decoupling and Apollo can be easily switched on.
Search engines may not index your Meteor app. Google will run some JS before indexing, but Google still isn’t indexing JS-heavy webapps without work on your end. Spiderable may not be reliable without special consideration for hosting environment.
People may not find a Meteor app organically due to poor SEO. So unless there is a budget for subscribing to a service such as prerender.io, or a big advertising budget, static pages might be worth consideration pre-launch.
Not to mention that one of the most important things during early marketing is being able to make quick changes to your landing pages, and tying it to your Meteor app slows this down.
1 Like
Why not using SSR? After all, Meteor is just a framework powered by Node. It’s not that hard to setup SSR as it exposes its connect middleware throughout its webapp package. You would have done it with every other Node based framework like Express, Koa & co.
loading time, landing pages are typically for marketing and need as fast a page load time as possible. big webapps it’s not as much of an issue. the roadmap mentions better page load time improvements with async loading though, so maybe that’ll be solved soon
By the way, with SSR and cache, Meteor is able to spit out its first byte in less 1ms. Not bad, I would say for a performance sensitive marketing team 
1 Like
As far as I know, SSR only works with React. Please tell me how this can be reliably accomplished with Blaze outside of using spiderable/phantomJS.
Another downside is that marketing teams might wish to use their own purpose-tailored tools/CMS just for the purpose of marketing, and if the landing page is tied into Meteor then they may not be able to use the tools of their trade. But this is assuming that a marketing team even exists.
Though, I favor React, Blaze, Vue & Angular2 are also able to render to a string. SSR is doable with these view libraries as well.
There are multiple advantages in coupling your landing page with your app: less DevOps, more code reuse, less maintenance, eased signup strategy, more coherence with your analytics … Doing a CMS in a back office isn’t that hard as well. There are some nice example like Orion.js.
The only downside I can see is code splitting which is still not part of Meteor Isobuild for the moment. Some solutions exists but they are a bit too tricky for being used in production environment.