Some days ago I have migrated a lot of the available content for Velocity to https://velocity.readme.io/. With this it’s now easier to contribute by creating or improving content. So if someone has useful content that is currently missing there, feel free to open a GitHub issue with the content or write me directly.
1 Like
11 secs - checked. Dev instance with debug, cold start with no cache, 407 scripts including packages and some decent images. And I do not do any processing in the beginning, all subscriptions are on a minimum level.
I cant imagine how I can shrink it. I have not seen lazy load for templates or packages, it is all loaded in the beginning.
1 Like
You should measure the load time of the built app. That’s what matters for your users. A built app is concatenated, minified and compressed.
11 secs may still affect the developer experience. You can split the app into smaller chunks by using packages, to reduce the effect of the 11 secs waiting for developers of you app.
I don’t know how people aren’t hearing about it. I first learned about Meteor from some Tuts+ article, and they have a huge readership.
Personally, I think large-scale adoption will take time, but that ultimately Meteor will be adopted on a large scale, and I think it will redefine web development when that happens. I have no basis for that opinion, but I do believe it. And I know the phrase “something is going to redefine whatever” gets thrown around a lot, especially in the media, but in Meteor’s case, I really believe it will have that effect. It completely (and elegantly) solves the problem of maintaining state that has been part of the nature of teh Intarwebs since the beginning. It’s like Meteor has patched teh Intarwebs.
Wow, lots of posts here with some great info. For me I’d like to see the platform itself improve; SSR, subscription management, routing, pagination etc. The community can look after everything else IMO, including a possible commercial package repository. I’d happily use Meteor to build regular content heavy websites once we have SSR. In fact, a good solid CMS would help Meteor penetrate the “Wordpress” market as Meteor can do so much out of the box and this is the route I intend to take as I advance my Meteor experience.
MDG have done a great job building a fantastic platform, it’s free, open-source and it can only get better. I think some people need to stop complaining so much and realise how good we actually have it.
I think the biggest challenge to Meteor is that its a late contender to the monolithic framework space, and the world is kind of burned by those. Everyone I know who did Rails/Django/etc is now raving about raw node.js and microservices. They want to build and control their stack, and looking into the Node framework space assures me of that: most popular options are small and boilerplate.
Using Meteor requires company-wide buy-in, and considering that Meteor’s scalability is uncertain, it makes the buy-in that much harder.
Still, I like Meteor so I’m not calling off my bet 
4 Likes
Agreed. Also, Meteor first hit at a time before Angular, Ember, React, Ionic etc. were huge - the landscape’s changed quite a bit since then.
I completely agree with you. The product is absolutely important, but evangelize the framework is a full time job that have to be done since day 1. DHH and Jason Fried made an awesome job on this side since the very first release of the product and without tens of millions in the bank. And that is what I feel like the weakest aspect of Meteor: not enough effort put on evangelizing the product. Not enough samples. No conferences to gather the Meteor community around a common goal. I would suggest to put in place the following actions very quickly:
- Organize a worldwide conference partnering with O’Reilly by Q1 2016
- Promote what are the most successful startups adopting Meteor – Twitter made a lot for Rails
- Set up a team of technical evangelists paid by MSG to speak around the world at javascript related conferences
- Set up a free support service for 3rd parties which want to invest in Meteor development – something like Meteor Lunch Pad Program
- Work with a set of selected partners to create Meteor coding school
- Target the big enterprise market. I want to say a couple of things about this. Rails failed to be adopted by the big enterprise market, primarily because Rails stack is really far from the enterprise usual production stack. But Meteor is based on Javascript and Node and many companies have Node in production today.
- Work on collecting Meteor related market metrics – how fast community is growing around the world, how much Meteor programmers get paid, how many companies are using Meteor to create products and projects, how much Meteor developers are compered to Java/Spring and Ruby/Rails because companies can save millions of dollars adopting this technology
- Work with the big 5 consulting firms around the world to create a Meteor culture in customers team. They could do a lot on this side if only they would be supported to understand the real advantages you have using this technology
6 Likes
Did I read correctly somewhere that there was an initial push to get lots of stars in github. If so then what we are seeing here would be similar to what happens when one buys traffic to a site and then continues to have ongoing expectations that are based on those levels of traffic. While Meteor seems to have its legitimate role and a place under the sun, perhaps those github claims caused some folks to get in, believing that sun will stop shining on everything else. Now that they are in, they are discovering that there is competition and that even their trusted colleagues are kicking back with something else.
Well, looks like adoption is picking up! 
5 million active users!!
Meteor is an overkill relative to what?
…
Relative to me checking out a complex insurance policy and working on it alone for several days. In that case, use of Meteor might be an overkill. However, if someone ever asks to two people to collaborate then you would have to start good part of it from scratch. So, why not do it properly from the very beginning - even when it’s not obvious that it’s required.
I will repeat it again that Meteor’s adoption is actually increasing very rapidly. As a freelancer ,
I am getting much more projects than I can spend time on even after working 60 hours a week. The biggest plus is my clients are extremely happy and impressed with both the web app speed and the development speed.
For non tech people who had been trying wordpress to create a webapp, meteor seems magical.
Meteor has already overtaken rails in terms of popularity on github.
React Developers find meteor as their perfect backend.
The number of people looking for meteor developers and the number of meteor developers is continuously increasing as seen on weworkmeteor.com.
The best way meteor is described in its docs:
the best teams, with the biggest budgets and the longest schedules, now build applications in JavaScript that run on the client. These apps have stellar interfaces. They don’t reload pages. They are reactive: changes from any client immediately appear on everyone’s screen.
**They've built them the hard way. Meteor makes it an order of magnitude simpler, and a lot more fun. You can build a complete application in a weekend, or a sufficiently caffeinated hackathon.** No longer do you need to provision server resources, or deploy API endpoints in the cloud, or manage a database, or wrangle an ORM layer, or swap back and forth between JavaScript and Ruby, or broadcast data invalidations to clients.
1 Like
JS
- JS is the most popular language. But JS is the most popular language because it is the only language browsers support, not because it is very sexy or easy.
- Client side HTML rendering is sexapeele idea from developers point of view only.
- Server side JS is not a step forward (even on steroids like Coffee, Type Script, etc… and powerful IDEs like WebStorm)
- Sharing JS code between client and server is overestimated. Developers can reuse knowledge, but it hard to reuse code and save a lot of time
Anyway I appreciate MDG and believe they do their best to deliver the best JS experience and build engine for Front-end developers. MDG should concentrate or their own target group. It is hard to convert Full-Stack, Back-end, mobile developers, big teams and enterprises to new “religion”. Don’t try to be universal.
Mongo
- MongoDB is pretty cool. I love it. But most of the real-life domains are tabular (RDBM) or relational (GraphDb). DocumentDb is very specific. MongoDb is misused in Meteor. I am looking forward for neo4j.
- Normalization is not a goal itself, but denormalization, embedding and handwritten data access logic it is not a step forward, it is a waste of time.
Real-time UI is overestimated too. It is ok for chat applications, but do I need 10 comments in real-time under by post? Not sure. Likes? I mostly interesting in the topic itself, not in the real-time rating.
DDP everywhere.
What wrong with HTTP? WebSocket protocol is required for Meteor but it is misused.
HTTP has a lot of capabilities on board (e.g. cachability ) and can benefit from existing middleware, firewalls, etc…
Off-topic. Browser vs Mobile
- Mobile applications started to generate more internet traffic then browsers.
- Startups start from mobile apps
- Mobile apps will slowly slowly kill browsers
Disagree with this - sharing code between client and server allows for all sorts of goodness.
This, however, I’m in total agreement with. Apollo can’t come soon enough.
2 Likes
I second much of what was said previously:
- Need a killer App that showcases Meteor
- Need support for SQL-type and other DB’s (enterprise won’t switch to Mongo just like that, not to mention ACID compliance which may be a regulatory requirement).
- Built on top of JS / Node makes it very appealing
But I’ll add this:
Meteor’s strength is that it makes it very easy and quick to deploy a complete App, thanks to the well-thought out data on the wire, built-in view layer, and the ecosystem (e.g. autoform, roles, Semantic, Blaze, and now React etc.)
However, big companies don’t always care about speed and ease. They can hire more and get larger teams (remember how a typical developer in large corporations only writes a few lines of code per day?). Companies care about quality, code / tech reuse, standards, compliance, documentation, etc.
While I love Meteor because it made it easy to deploy our App quickly, I don’t see a bright future for it commercially – I expect the community to take it over at some point or it metamorphoses to something else. Angular 2 is out, React ecosystem is growing (not as fast as people think, but still …), EmberJS is incorporating Virtual DOM too and so on.
MDG is doing a great job, putting up a great fight. Would love to see them succeed.
Concerning your Browser vs Mobile comment, look at the browser as a very sophisticated and well-ironed out virtual machine. You can write single code and deploy everywhere. This is what we used to like about Adobe AIR / Flash (this too had its own VM to deploy same code cross-device). Cordova is here to stay for many technical, business, and structural reasons.
What’s the catch, how do are you finding Meteor clients if you don’t mind my asking?
I have no problem finding clients in general, but selling people on Meteor is often like pulling teeth, and mostly works with cash-strapped non-technical clients who just want an app fast and cheap and don’t care how it’s done. Which is not where I’d want to be.
While code sharing between client and server is absolutely possible I (personally) didn’t find a lot of useful cases. I tried to reuse validation, but found than data access, business logic and UI validation is quite different. Let’s say for business logic it is enough to check new password against one regexp, but for UI I need to check several specific cases (lenght, special character, etc) and provide human readable messages for all the cases in all the languages.
In general idea to do “the same” both on client and server side looks week from the architecture point of view.
But I can be wrong, if you have some ideas please provide me.
Pure business logic normally works well in both locations, so for example calculating the sales tax for an order line or the total value of an order. You usually want to calculate those on the client to show the user, but if you are persisting them you’d need to calculate them again on the server (for the obvious security reasons).
Validation for inter-related fields would also be shared (e.g. if this property has this value then another property must have a value in this range).