PHP Vs. Meteor for simple Websites

Hi all!

I know I’m in biased place. Still I would like to know if there is any reason to develop in Meteor for a simple site with no need for real time/colaboration, etc. The site will have about one page with some editable info (BO) and one or two forms (contact form). It will not have much traffic as it is for a freelancer PC repair friend.

I have not made any test, but I believe that Meteor will be to much weight on a server for something so simple and PHP with Apache would work better. Any points in favor of Meteor? or PHP if you feel is the best option. I don’t know much of either also, so that is not a factor. I need to learn both though.

Thanks all

I come from PHP world and I invested deeply in learning it, over 5 years of professional experience, and when I came to Meteor and saw how easy it is to setup a project, and get up an running I almost fell from my chair, felt like I was living under a rock.

Points for Meteor:

I will soon create a Meteor Tutorial specifically crafted for web-designers on for now, it can be a good starting point for you and you can skip the “collection” and “publications” and “reactivity” parts of it if they are of no interest.


Thank you for sharing your experience.

My background is. NET. I’m trying to make it to developing through freelancing so free stuff is essential. Many people look for php(and WordPress) development specifically because it’s better known so I’ll need to learn it eventually.

But I have came across meteor like a year and half ago at the same time I was looking into nodejs and was blown away by it. About half a year later I made intro course in coursera and loved it.

Like you said, most things are so easy to setup and develop that is much fun to do it.

My feeling is to develop all things in meteor, but what about system resources? Isn’t meteor heavier than a lamp stack? I have a feeling it is a lot heavier, ram and cpu, maybe removing websockets will throttle traffic quite a bit, still there is is all the other things.

Does it make sense to put such weight because of something so simple? Can I disable unnecessary things like websockets and that will help to the point this does not make any sense anymore?

By the way, I would love to see that tutorial of yours, specially something about deploying apps into production. :slight_smile:

My feeling is to develop all things in meteor, but what about system resources? Isn’t meteor heavier than a lamp stack? I have a feeling it is a lot heavier, ram and cpu, maybe removing websockets will throttle traffic quite a bit, still there is is all the other things.

This is a big story. We worked on a social network and we invested a lot in scaling Meteor to the sky. I can tell you for a fact that Meteor is trully scalable. If you don’t want websockets (not keeping connection with client alive) it can be more performant, because one page app, client perceives the load only once and that’s it. No more requests to the server, or if you want requests the bandwidth will only be filled by relevant data, not already rendered views which consume server CPU.

There is a solid principle in programming: first focus on making your app secure, and leave performance last. When you’ll be needing to scale Meteor, most likely you will have traffic, having traffic can generate revenue, generating revenue will imply that you can spend on scaling :slight_smile:


Another option for a website this simple is just build it using a static website generator like Hexo (Javascript based) or Hugo (Go based). Meteor’s docs and guide are built using Hexo, github source for guide. You can then deploy to Amazon S3/Cloudfront for basically free and have a very fast website.

Our pre-beta website is also built on Hexo and deployed on Cloudront.

@skirunman, Never gave too much thought into static website generators, but now that you mentioned…why not. Seems a good solution for this kind of project. Still have to dig a little if it is feasible as I want my friend to be able to add some content without much hurdle and have a contact form. Any tips?

@diaconutheodor, I still feel like the need to check ram use at least, but I will certainly check how to scale meteor better. Any more tips, for this kind of institutional site, besides the websockets?

Thank you both :slight_smile:

Just a quick update as I was researching a bit I came across a very nice JS project that enables CMS on any site and seems perfect for this kind of little projects that will not have much traffic:
What it does is that it stores the content for you on their servers and when your pages starts loading the DOM it injects the most recent data into it. There might be a small flash, but from what I saw it is quite fast and usually we don’t see any flash of content.

I’m looking into for contact form now.

I believe I’ll be going with meteor for most projects if the weapon of choice is up to me, except for this kind of very small projects were I’ll have static sites with this kind of strategies. For me makes more sense than a generator as there are less configs to be done and is easier for customer to admin the content.

Thank you both for your input.

Many-a-programmer learned this the hard way. Spent money and brain power worrying about problems that ended up never materializing.

Premature Optimisation is a killer.

The more general principle is YAGNI - You aren’t gonna need it - One of the elements of XP.

I think you guys are missing the point.

Why would I buy a server specific for a meteor project that will kill too many resources when I only need 1 page without any dynamic content? I can put this on a cheap VPS without an hiccup and probably many more like it on the same cheap server. The same thing cannot be said for a meteor app. Besides that I have fewer things to worry about as the code will be simpler with just HTML, CSS and JS.

It’s financial more than optimization.

Deploying a php website is far simpler than a meteor app. I mean, the dev version and the prod version of a php website are 99% similar (no xdebug for prod…). And you can have LAMP out of the box with few (only one?) commands.
The dev version of meteor is wonderful, but deploying it, gosh! (deploying it… on your own little and lovely server)

On a other hand, yes you can do great things with 100 lines of code with meteor, fewer than with php, even with a micro framework like silex, BUT the things you thought were simple are not.

  • What about file upload? You can with other node.js framework, but not with meteor (it will make the server reload with the file in memory). Oh yes you can, but with amazon. $_$
  • What about urls and routing? Central for php, but with frontend frameworks you need … packages! See the issues for iron router’s github page. Flow router will save you? Oh its major developer has recently gone :cry:

Well, I am more criticizing some parts of Meteor rather than giving advices, but yes I think that [quote] Meteor will be to much weight on a server for something so simple[/quote]
It’s a pity to stop or cut best parts of Meteor just because you’re not using them! Meteor is a true Internet 2.0 framework.

This article (they are discussions about it on this forum) describes with success the current state of creating websites, hem… learning JavaScript :wink:

I advice you to take ready templates for HTML and CSS and implementing meteor …
Don’t worry about memory and cpu … its not a big project !
I’d recommend working with php but you will need something like jquery to manipulate the Dom …

Give a try to Panoply CMS - - Please pull it from GitHub, not from Atmosphere.