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
I feel quite the contrary. Meteor adoption is increasing rapidly and meteor is becoming popular not only among the developers but also among tech enthusiasts. I have been freelancing full time as meteor developer at https://nikhilda.ga/ since last 6 months and since then developed 6 web apps and have been approached for many more.
Meteor is a complete joy to work. The packages developed by community (especially by @arunoda , @aldeed ) are extremely useful in implementing almost all sort of functionalities. Those who are already stuck with other tech might find it difficult to shift to meteor, otherwise as far as I think the overall demand of meteor is increasing rapidly.
3 Likes
I feel like this conversation is really a branch of the article that went around earlier this week about why you should “never use mongo.”
My current field and peer group is really based around marketing and regardless of our niches, we’re in a small market in general. We must remember, although major markets have a lot of developers, most people in fact are not in major markets and that has a lot to do with this.
So with that base knowledge, why are most of my peers not adopting meteor? First, doing brochure sites with meteor is almost not worth it. Doing routing, SSR, etc. really kill that, especially when SEO and Social Sharing are thrown into the mix. Would someone really abandon their tried and true LAMP based CMS for meteor? Probably not.
For firms who are true development shops, why would they leave their tried and true methods as well? They have years invested in .net, java, python, whatever. They’ve got their hosting figured out, their scaling figured out, almost everything figured out because they’ve been doing it for years. They’re also used to SQL because again, they’ve been doing that for years.
It’s just not worth it to overhaul processes that have been refined. And that’s OK.
Meteor needs to focus on people like me, and those of us in this thread. We’re people who are flexible, nimble and attracted to new ideas. I would look at ruby/rails adoption rates and compare meteor to that as it will be the most comparable market in terms of how it changed the scene versus how meteor is changing that scene.
A tip that might help. It often did the job for me: Don’t only search for Meteor specific solutions. A wider scope is any solution that is implemented as Node.js package or as JavaScript library. For learning you can apply the same technique by searching for information for the topic in general without any Meteor specificity. Then make the transfer yourself to use it with Meteor.
For bringing non-Meteor packages into Meteor there are now easy to use solutions:
- Npm: The trusted source for JavaScript packages, Meteor resources and tools | Atmosphere
- Browserify: The trusted source for JavaScript packages, Meteor resources and tools | Atmosphere
- Bower: The trusted source for JavaScript packages, Meteor resources and tools | Atmosphere
- Or just copy the JavaScript files and wrap them into a Meteor package
4 Likes
Rails (again using it as comparison) had these same issues when growing in popularity - in fact, routing for example, was an ongoing issue until the framework merged with another framework (Merb). This trend is now visible with flow and iron when it comes to routing. Projects are meant to increase in size - hence packages are the solution technically. However, best practices are still emerging from the community. That cliff might be the real show stopper right now. I’ve to consider many options now and still need to investigate for example which packages I truly need for my solution. Would I go for Blaze or React - and what will break? Confusion is the bigger snail.
2 Likes
Meteor needs killer tutorials for beginner developers. In the past, I started learning Rails and became developer thanks to tutorials offered by companies such as Code School. I did not even know much about Rails back then, but their online courses had a great reputation, and I just went with it.
1 Like
From my POV, as with any Open Source, the quality of the documentation (such as how it works behind the scene, scoping vs, DOM) a clear roadmap of what we need to learn. There are many things to figure out. We need a lot of faith to accept the journey. People maybe stick to what they already know well.
2 Likes
How beginner are we talking? And how killer? 
The Discover Meteor book is pretty awesome and it’s how I got my start, though I’ve got quite a bit of coding experience. I imagine at some point, Code School will have a Meteor course.
2 Likes