There’s a nice E-Commerce App written for Meteor: https://github.com/reactioncommerce/reaction
2 Likes
reaction commerce is a complete shop. I mean a support framework (library) or package is better to be provided. It may support check in, check out, cart, inventory, pay method, shipping, .etc. So it is low-level package but works for NoSQL MongoDB. If NoSQL is not suitable for transaction database use, it can be tried to use SQL or dual database.
Another important package is social network package.
Meteor needs a foundation that includes a list of basic app packages (frameworks).
None of these things are important when judging the usefulness of a framework such as Meteor or Angular. So what if there’s no social network package, or e-commerce package? That’s irrelevant.
I think the main factors slowing down Meteor adoption is simply that many companies feel it’s too young and therefore high risk. That is, until a developer comes in and convinces them otherwise.
3 Likes
One would think it would have taken the world by a storm by now, with most startups adopting it by default. And yet, its market share is tiny, its job market is non-existent. What’s up with that? What could be the possible reasons? Am I missing something?
I learned about Meteor since last week. I’ve always done my development in Rails - which took serious time to get really adopted. The job-market will take some time, as it would take experienced developers to take on a migration / porting of existing services; most companies rather play it “safe” with responsive, event-driven, blocking I/O servers. I think that storm is just starting.
I think the biggest showstopper is because it requires a new way of thinking. Familiarity helps - a lot! When I first started the Meteor tutorial, I felt I didn’t see something new. Until I saw it in an useful app. What I saw was reactive - and that triggered me to invest time in haunting forums, reading horrible tutorials, eating the full API and finally getting somewhere thanks to the manual. Change scares the s*** out of people, when they have been doing something else for a long time. However, packages such as CoffeeScript, Iron CLI and Jade help to fix that perspective.
Second, the Meteor story isn’t really helping to adopt quickly. Hate to do this, but Rails nailed this by doing two awesome things: docs and generators. Even though the tutorial is great, it doesn’t really teach you the love. The Rails community has the RailsGuides and the extensive API doc. If I ever needed to learn basics, I would find it there. I spend googling, SO-haunting, book-purchasing and the manual eventually got me to the Deps part. There is serious room for improvement there.
Then there is life cycle. The whole idea is to develop, test and eventually deploy it into production. Many tools aren’t simply recognizable to take on these tasks. When I want to do an administrative task, I do not want to spend time on information I do not need - most stuff is hidden. Even though it amuses me (it is the hacker way – learn your game by pulling out your last hairs), it makes the learning curve steep.
It is certainly not monolithic - Meteor is quite free minded when it comes to changing the way I need it. The platform meteor provides is to support the framework as tight as possible. It is certainly not toyish for senior developers - as JavaScript has been an implementation language for most application servers thanks to Mozilla Rhino and JBoss. Anyone who still believes that ECMA implementations of these days are still similar to DHTML from the days of Netscape, are the same kind of people who feel the need to use Twitter for broadcasting their bowel movements. The magic stopping doesn’t have to be a show stopper. Any experienced developer knows you simply don’t become a wizard overnight. And overhead doesn’t stop any company who currently are using Rails (that can’t scale) or Django (brrr…) for real stuff.
Meteor is not the solution for everything. But it doesn’t need to be. I’ve been a Rails lover since the very beginning and I dropped it in a heart beat after playing with this.
5 Likes
I regret how negative I was being in that post, I was in a bad mood because there’s always some friction when changing toolsets. To add something positive to the equation: the thing that ultimately convinced my boss and I to start using it was how we can use it to create an API with out any REST boilerplate, and the fact that it sends updates to subscribed clients as well – these features far outshine any other frameworks I’m aware of.
Before getting started with Meteor, I had often thought it’s unbelievable that I’ve seen so much Mongo-REST boilerplate written essentially from scratch, and that there has to be a better way to do that. So the value of Meteor is no surprise to me.
Having Blaze fit right into that reactive stack is cool too, and I’m willing to bet it takes less code and performs better than React in some cases (theoretically it should be faster since the updates can be more granular, and it doesn’t have to do anything like React’s virtual DOM diff). But, it does have less flexibility in certain cases, and my boss and I were just already in love with our Webpack/React frontend stack. And I’ve worked out almost all the kinks with that.
So I think MDG’s priority should be keeping its API components top-of-the-line and adding support for other databases/backend integration. I think other UI technologies may take the lead, but it seems like Meteor has a huge head start on everyone as far as being a modern API framework.
1 Like
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 