What factors are slowing down Meteor adoption?

community
61

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
62

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?

63

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.

64

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
66

@obiwahn Totally agreed for my personal case. I donā€™t have the answers, but these sound spot on.

67

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
68

Indeed Meteor needs more fantastic package developers like @arunoda and @aldeed.

69

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.

70

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:

4 Likes
71

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
72

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
73

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
74

How beginner are we talking? And how killer? :slight_smile: 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
75

How beginner are we talking? And how killer? smile The Discover Meteor book2 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.

I think the amount of hello worlds are quite available. There is a big difference though in what a tourist needs and a resident needs, and sungwoncho probably remembers Railscasts - video tutorials that went beyond hello worlds and actually went pretty deep into useful practices.

The Discover Meteor book is great to start, together with the manual and the API doc. It has been a real time investment from my side to use Meteor, because most ā€˜commonā€™ things I still have to investigate. I am already on over 70 pages filled with notes and references that are about using meteor beyond a quickly reactive website. There is just enough for coders. Not so enough for engineers. And hackers donā€™t need extensive tutorials (just forks and finds). The engineers are target audience regarding this topic, and donā€™t hate me for it - Discover Meteor is just a start.

3 Likes
76

I agree. Discover Meteor was what sold me on Meteor. Iā€™ve dabbled with the combo Angular and Grails but was still looking for the perfect stack for a new project. A friend suggested Meteor and the book. 2-3 chapters in and I had around 10 ā€œThatā€™s possible???ā€-moments. However, using the book for ā€œhow do Iā€¦ā€ is tricky for a lot of more realistic scenarios. Plus it had one issue. It didnā€™t relate to existing stacks! It lacked explanations regarding(ā€œIā€™m used to this way of doing things. How is that done in Meteor?ā€)

What I feel might be missing are instructions for developers used to MVC and highly separated front/backends. Meteor uses a different paradigm than what many are used to. Coming from Grails/Angular Iā€™m used to a hard difference between client and server. Iā€™m used to handling all of the ajax stuff. Iā€™m used to REST and using pretty much any DB I desire.

A lot of engineers become self-proclaimed evangelists. Not because they think something is awesome, but because theyā€™re used to it and canā€™t be arsed to learn something new from scratch. However, if you show them that what they used 50 lines to do can be done using 10 in meteor, that investment can be worth while. A lazy engineer is a good engineer!

Examples showing: This is how that app would be made using this stack vs this is how we make it using meteor.

Examples showing how long it takes to prototype something and financial gains from it.Thatā€™s how you get folks to meetings.

Luring them with ā€œmagicā€ isnā€™t the way to go. Luring them with efficiency and laziness might be! :wink:

1 Like
77

One of the reasons I have so many notes, investigating. In fact, I am so unsatisfied with some packages that are recommended, I am torturing myself to do something else then spending time on Meteor - just to be able to use it as a professional. Regarding REST vs DDP (which sounds like an X-rated protocol if you asked me), MVC and HTTP technology, the reactive approach requires a serious change of mindset - that just comes with the territory, no book or tutorial will help in that regard.

I am really lucky I know someone who is using Meteor already professionally - so I got a head start. The tools for engineers are quite poor. Gradle or other build tools usually donā€™t make sense to web developers doing a hacky overnight (unless they did an APK build once and sees it as a mandatory result by hitting the run button), while engineering software demands such tools - integration testing, unit testing, deploy in stages, performance tuning, etc. Ten developers on a core project canā€™t learn a twenty frameworks in 0.1 stages overnight without being met halfway. No commercial business would ever take a huge risk doing such things, without some solid facts and references.

2 Likes
78

@Sanjo: Thank you! This sounds like a really good idea.

79

Iā€™m positive these notes would be much appreciated by other meteor newbies like myself!
Perhaps a shared note github repo for everyone to use and append?

80

Iā€™m positive these notes would be much appreciated by other meteor newbies like myself!
Perhaps a shared note github repo for everyone to use and append?

They are mostly ā€˜notesā€™, and even though I might look civil on the forums - my notes are less sensitive, as they are targeted at a narcistic egotripping know-it-all :wink:

Isnā€™t there such a thing already? Or at least a Wiki/Wikibook? If not, it should not be based on notes, but an engineer FAQ. Right now, I am fighting cucumber-js to find my project files - and even though I like the idea of Meteor Testing, I am not paying for an unfinished book to tackle a configuration issue. And an one hour live talk on YouTube with poorly scripted un-autocued talk about the benefits of BDD only helps me on matters of insomnia. Such a FAQ/Wiki would be a first great step for professionals.

Let me share you these findings (these are notes - not questions, by the way).

Stack
A fairly simple note is the stack I am going to use:

  • Meteor (without Iron CLI, I am currently planning to build my own cli solution, as iron-cli doesnā€™t fit my needs).
  • CoffeeScript (keeps code readable and feels more like a dynamic language such as Python/Ruby)
  • Kadira for monitoring what will happen if I ever get that far
  • Stylus for CSS (because Sass and Less, well just miss that elegance)
  • Blaze (because it is a core template engine, has the UnderScore + JQuery support and is well adopted)
  • Cucumber-JS (integration testing, BDD)
  • Mocha (unit testing, BDD)
  • Nodejs (toolchain interpreter)
  • Flow router (because Iron is overly complex, hence I dropped the CLI with it)

Structure
I figured out that I need a couple of tools that would allow me to truly embrace my work in Meteor. One for example is a professional structure. Sorry, but hello.html, hello.js, hello.css is not going to cut it for me. Every project should be quickly handed over, so structure is king.

Generators
This structure will be my ā€œstandardā€ and why would I type a bunch of touches and mkdirs when I can do it in a single one? As I could do this in 5 minutes with Ruby - I prefer my toolchain to be untainted, so this I should do in JavaScript that can work independently with nodejs, like a preprocessor. Also, this little challenge forces me to undergo those steps mortal (or sane) men would avoid at the beginning. The advantage of a generator allows me to have default configurations and setup without giving away entire control. Also it enforces convention - a mandatory thing when working collaborative.

Testing
Long live generators, for they can be used to create features and step definitions. Using BDD inside the meteor eco-system without too much of academic thinking (read: philosophy how to structure the testing environment). Challenge is how to not directly deploy on the server where it is supposed to be in production, but the stage in between - user acceptance testing (read: somewhere safe for developers against stakeholders playing with features in order for management to empty customers wallet for more features).

Integration
How to setup HTTP calls, REST api to connect to other resources? Single page apps might run fine, but there will be always some non-compliant datasource that requires a connector or adapter.

Interaction
Since reactive design forces a new way of thinking, it forces also a new pattern of user behavior. Interaction design has just barely touched the surface in this regard. Probably have to steal practices from game developers and convert them to my own religion.

Auto-doc
I need something that can document the API as I build my application, without me overusing Cmd-C.

Bundler
Some kind of automation tool that automates the packages I tend to re-use but arenā€™t factory default. Preferred to be invoked through a generator.

Administration tools
Mechanisms to control the instance - startup, shutdown through a protected RMI. Professional apps should be managed by the guys clicking buttons and being certified for Microsoft Solutions. Also migration tools, similar in the usage mentioned before.

Security
Autopublish might be great, but I donā€™t want Joe at Tech Support promoting himself to a Mojito King on Bora Bora by injecting evil things and such. More importantly, I need to be aware of security threads and issues - like session hijacking, integrity risks and execution of arbitrary code to defend my ass against the legal guy. And when it does happen, thanks to this prior knowledge, I can hide behind corporate policies. I like Joe, though.

WWOT List
The Wonā€™t Work On This-List is the key to understand where the app wonā€™t work (the software breaking point). Itā€™s a tech support thing, and scars from the past might motivate Joe to investigate the security note more.

Scaling
When to scale, what to scale and steps need to be taken to scale it.

Performance
When to speedup, what to speedup and steps to be taken to speedup. What to loose, when to loose and quick ways to loose it.

Requirements
What to purchase, how much to purchase and expect to purchase when going live. How can I simulate and benchmark, how do I measure KPI and other facts instead of lying to the customer that ā€œwe did some performance enhancementsā€ based on wishful thinking.

TTDWSGW
Basic troubleshooting. Things To Do When Shit Goes Wrong. Where to start? In what chains are code and data executed? And more importantly in corporate decision-making: who to blame?

2 Likes
81

@greblak

Now letā€™s see where this goes: