Curious what package you used for the REST API?
I’m using Restivus, although it’s newer, it’s actively maintained and it’s really clean and (mostly) easy to follow the documentation and looks like it’s coming along nicely.
2 Likes
For what its worth and in answer to the questions about why start-ups aren’t using meteor. I was at a Facebook hackathon a couple of months ago and of the 20 teams, probably half used Meteor for their product. I now this isn’t a great representation, but because of how well it excels in getting something quick working, I suspect it is being used a lot in other hackathons or even educational settings. Places where rapid development and feedback are more important than scalability and flexibility.
Oh, well I wasn’t talking about using a Meteor package for a REST API, I really meant using Meteor in place of a REST API. I haven’t really done much backend development myself. One company I worked at rolled their own REST API framework powered by C#, it was solid, but totally custom. My current boss used Sails for one backend project, as well as writing a REST server from scratch in C++ to serve content from an embedded system over LAN 
1 Like
Speaking of the benefits of using Meteor instead of writing a REST API, I just had a thought. Have you guys seen devdocs.io? They use IndexedDB and AppCache so that you can use the site offline; it’s really nice.
I was thinking, if you could make a Meteor app work offline by simply toggling a flag—that is, have it go ahead and update the local MiniMongo while the user is offline, and send changes to the server when the user goes back online—it would be killer! Obviously some kind of API might be needed for reconciling changes made this way, but it’s possible. Maybe there are even packages that do this already, does anyone know? But if it was advertised as a built-in feature, I think it would be a huge selling point.
I do wonder about scalability and performance – C# and Java still seem to have a huge performance advantage for large enterprises.
In the past couple of weeks while diving in to Meteor I have been thinking the same thing.
In your opinion what would such a video series/tutorial cover?
My take, fwiw, is people try to cast it as the golden goose. We found that it is the easiest and quickest way to build a platform for modeling objects and editing/creating them. Our arch is very SOA orientated with meteor controlling how data is transformed as it travels through the stack by way of being our interface to mongo docs (out models).
It is super easy to start building essentially a simple forum or social media style project with meteor, which is empowering, but it seems like quickly people wander into the complexities of meteor when looking to implement more advanced functionality…even if that is only integrating some pre existing js lib. Imo that’s gotten waaaay easier and far better documented, but of all the people I’ve shown meteor to every one of them has raised that issue…and lack of ORM/sql support
Hey, btw you can actually add the appcache package to cache your app’s code offline. For example, docs.meteor.com works offline 
2 Likes
Javascript is as fast as C/C++, C# or Java.
V8 is the reason why JS is so fast. Billions and billions invested.
Node.js helps a lot too.
check this out
In a hard math problem Javascript is marginally slower than C, even faster than Java in some cases.
What JavaScript and Node.js gives you though, is that it’s easier to write good code. Think I/O code for example.
Continuing the discussion from What factors are slowing down Meteor adoption?:
.NET and Java application servers had serious time to mature. Remember the days when IIS and webSphere would take two coffeebreaks even to launch - and tend to break in times of performance peaks. For example, Java garbage collection storms inside webSphere around 2011ish, required some serious hardware to overcome most challenges.
Scalability is often a term used too easily - scaling mechanisms should be part of the design, taking in consideration more than the default platform. MongoDB provides some awesome features in its replication engine. Take a look at this article here: https://meteorhacks.com/lets-scale-meteor
1 Like
@muaddib, I love JS, but this article is meaningless. Even Visual Basic would be as fast as C with this benchmark code.
2 Likes
I love JS, but this article is meaningless. Even Visual Basic would be as fast as C with this benchmark code.
I really, really had to restrain myself for saying this too. With more horrid examples. Wouldn’t initially use VB pseudo execution runtime as example, but now I am completely satisfied. Zenified again.
1 Like
If idiomatic JavaScript was as fast (even asymptotically as fast) as any of those languages, asm.js wouldn’t exist.
Don’t worry guys about telling me wrong. I like criticisms, and I know most of the people think c++ outperforms JS.
I’ve a math background, and I often did contests with my CS friends about writing algorithms in (Python) JavaScript vs C++. Sorting algorithms, numerical methods, shortest path, etc…
The test was simple: both contestant try to find a solution to the problem. When one contestant finish, the other one has 25% more time to deliver.
The results of such contests led me to this conclusion. When you don’t have unlimited resources to write your software, as in this scenario, the pressure force you to write poor code. And javascript helps you since it takes less time to write good code than when using C++.
Always keeping in mind that Node.JS is C++, Javascript is C++, and you can always expose C++ classes to JS.
Given that, I admit I’m really opinionated 
Okay, I just released an example of using webpack-dev-server and react-hot-loader together with Meteor:
https://github.com/jedwards1211/meteor-webpack-react
2 Likes
Like others said, the fact that adopting Meteor requires adopting both a new back-end and front-end framework is probably a big reason (although that’s changing with React and Angular efforts).
I also feel like Meteor makes complex things very easy, but also still makes things that should be easy pretty complex (SSR, routing, managing subscriptions, pagination, etc.).
I feel like maybe some developers are initially impressed by Meteor’s well-earned wow factor, but then hit a cliff when their project’s scope gets larger?
I think there’s nothing wrong with Meteor diffusion by now, it’s just tailored to a specific niche: I find that unless your app truly needs real-time, Meteor is a bit of a overkill.
My Meteor Problems:
- lack of mature packages
- hard to debug (too much magic / reactivity)
- lack of “pro” tutorials / samples
- I miss SQL
I wrote a medium sized “professional” website with meteor.
And I had a really hard time. I am not even sure if I would do it again with Meteor.
Whenever I got in the more “pro” regions like an admin interface, payment (we use Braintree) or all i18n topics (i18n Google SEO is a nightmare), it was really hard to find any good informations, tutorials or forum posts.
This is kind of a chicken / egg problem. No pro devs, no pro solutions.
For most of the above problems you can find a package (if you are lucky). But not one was bug free. So I always had to step into the package code or rewrite it by myself.
Oh and: I am really sorry, I tried hard, but I don’t get the point of using MongoDB.
In a pro environment SQL has so many advantages, so many mature admin solutions, auto import for csv. ACID. Normalized schemas…
http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/
I sometimes feel like Meteors focus is maybe too much on “easy to learn” than on the pro features.
3 Likes