I've been using Meteor for months. It's such a pleasure to work with. It's what Rails should've been if it was written today.
They just keep on delivering on out-of-the-box functionality, compatibility with 3rd party libs, and more importantly - on a very solid architecture for real-time transport by guys who really know what they're doing.
Exact same experience. Development is easy and frustration-free. The team listens to the community AND delivers.
The platform is not just for playing around anymore, it has matured really well. See the case studies[1] - I, for example, love Hansoft X[2].
I think I would feel frustrated to have to go back to any other framework. Meteor is what web-development should be like. I'm not sure if Meteor is going to be THE platform everyone is going to use, but it definitely is completely changing the game and I suspect web-developers will be adopting the Meteor ethos.
I don't think either that Meteor is going to become de facto platform for all web development, but it's definitely going to be one of the main ones along with Angular, React and Rails.
I'm curious - do you think there is room for someone to come along with the right combination of stuff to become the "de facto platform for all web development"?
It's interesting also that people always talk about Rails but don't mention JSP and .NET, which I think are actually a lot more popular last time I looked around. I guess it depends on who you ask.
I feel like JavaScript is in a sweet spot right now because it has the inherent advantage of being the _only_ language you can run inside a browser, so you can do things with it that would be very hard or complicated in other languages.
I've wondered to myself a few times: perhaps Meteor would be even more popular than it presently is, if it had not been chained to MongoDB from the start. Even a different NoSQL db would probably have been a more popular/respected choice, at this point.
And, though I know this has been said before, it bears repeating: most developers who deal with data on a regular basis are best advised to go ahead and get comfortable with SQL. So far, it is BY FAR the best solution to the great majority of data-storage-and-retrieval use cases. I'm no expert, tis true, but I don't see JSON objects replacing SQL any time soon.
So, yes: as soon as Meteor includes official support for one of the SQL platforms, I'm all over it. It seems very promising, for those of us not locked in a death-rattle of foaming, red-faced JavaScript hatred.
Good question. I think Meteor is certainly the closest of such platform at the moment, but you don't have to go far to find a developer who really hates JavaScript and will never switch over. Such hate may or may not be justified, but you won't easily change their minds. At the same time, there are people - including me - who only develop with JS with no real need to switch over to something else.
I wish I had a more educated answer (guess?), since this is all just anecdata.
Has anyone built an Ecommerce platform in Meteor? Meteor is just this months hotness for building a specific type of web product, namely web apps. It's not going to become the defacto standard of anything else.
I've messed with it some, and so far, I'm not seeing what the advantage is on using Javascript on the server rather than Ruby or some other more advanced dynamic language. Ruby seems to have more advanced features and a better ecosystem around it.
I'm a data guy whose realized that all of the fancy data stuff in the world tends to be useless without a UI. I don't have time to put all of my effort into web apps, because then I'd have to take my focus off the data/business functions piece.
Meteor has been perfect for me. It works, I can easily integrate with it via the Mongo back-end, and the prototyping is super-fast. For the kinds of apps that I build (very industry specific apps for retail) I don't really have to worry about scaling to thousands of users, which means that Meteor isn't just a toy in my world. And even if I did have to scale, everything about the Meteor framework indicates that scaling Meteor is no different than scaling any other Node app.
When Postgres support comes, (its in the works) I'll be using this thing for everything.
Still waiting for the killer testimonial for meteor, until then I'd be too scared to try it with anything larger than a prototype or brochure site.
I don't want to be the first person attacking a completely new class of scaling problems using a proprietary tech stack that I may or may not have the ability to control.
Proprietary is the wrong word, as it is open source. The right word would be "immature", as meteor is an entire tech stack that hasn't been battle hardened by years or decades of other software that currently exists in other tech stacks.
The other piece is the meteor stack is designed to be hosted by meteor. Sure, you can, in theory, run everything yourself - but I haven't seen good case studies of that. What do you do when your app blows up and suddenly the hosting costs of meteor is too much of an overhead?
You can easily use things like Heroku and Modulus to host your site. I think perhaps you are misinformed about your options and should read up a bit more.
I use Digital Ocean with MUP and it works great with minimal efforts.
What kind of load does that app you host on digital ocean have?
Edit: I'm not at all suggesting that isn't possible to self host a meteor app, I am saying that I don't know what the "beaten path" is for other companies/apps/products that have self hosted a meteor app to a significant scale.
So... as it happens I have a lot of experience deploying Meteor apps to servers that don't belong to Meteor. In fact, I may have a greater variety of such experience than anyone.
As the lead developer of Sandstorm.io, I have deployed Meteor:
* As the Sandstorm front-end, where Sandstorm is designed to be installed by end users on their own machines.
* As apps that run on Sandstorm, and are designed to be extremely fine-grained (each app instance handling a tiny amount of data, e.g. a single document).
* As oasis.sandstorm.io, a highly-scalable centralized Sandstorm host.
* As apps.sandstorm.io, a fairly mundane use case (whereas Sandstorm is, comparatively, highly unusual).
I would argue that Meteor is not at all designed for Meteor hosting. Rather, Meteor is designed such that anyone wanting to build a PaaS around it will have a much easier time doing so than they will with just about any other environment. On Sandstorm, we find Meteor apps much easier to package than anything else, because the Meteor tools will output a self-contained app bundle that operates in a consistent fashion for all apps -- thus allowing us to write a common packaging tool that works with all Meteor apps. Other stacks are comparatively much more fiddly.
I would expect Meteor's hosting will turn out to be the best way to run Meteor apps primarily because they have kick-ass engineers there who will build an awesome product (disclosure: I know several of them), not because they've biased the framework in their favor.
> On Sandstorm, we find Meteor apps much easier to package than anything else, because the Meteor tools will output a self-contained app bundle that operates in a consistent fashion for all apps -- thus allowing us to write a common packaging tool that works with all Meteor apps.
What does that mean exactly? I admit, I only kind of know what sandstorm does from it's marketing page (looks like it offers VM's in a more user friendly way with an emphasis on security)
In what way does Meteor allow you to produce quicker or more efficiently than if you went with any standard linux stack?
Try installing Wekan, which is a Meteor-based app.
The thing that makes Meteor easier for us is, as I said, the meteor tools have a command "meteor build" which gathers all of the app's code and package dependencies and puts them into a self-contained directory tree with a start script that is executed the same way regardless of the app. This makes it easy for us to build a tool which turns any Meteor app into a Sandstorm package because the input is in a well-defined, self-contained format.
We are, of course, building tools for other stacks as well. It just takes more work.
Works great. Just isn't part of core. Meteor core is stubbornly trying to force use of atmosphere for everything. But everyine I know immediately installs https://github.com/meteorhacks/npm which allows for using regular npm packages.
I think inevitably the meteor team will bring this into core, or something similar, and we will be able to have our mix of atmosphere and non libraries.
I had totally different experience. I don't have much experience on meteor just working on some tasks for a meteor project. Hence issues might be related to it as well. But I felt it was very amateurish, there was no proper ordering/routing like in rails. I had to guess debug a lot to identify the source of files. Mongo was a pain to work it. My biggest issue was speed. It took a long time to reload after changes. From this experience I am not interested to work on meteor.
I don't keep up with meteor, but I have a question for those who do keep up to date on changes.
Can meteor apps be isomorphic -- in the sense that they render plain HTML on the server during first load, and then do the javascript loading thereafter?
I work on several client websites, and passable SEO is a requirement.
I know there's some hackery you can do to get single page apps to be indexed, but I prefer when it "just works" out of the box.
I have some react apps that use this model, and they index perfectly.
There is no first-party solution for this yet, since React support came out in this release. Hopefully we can make it automatic in the near future. I think this is a key advantage of the Meteor model - since the parts of the stack are expecting to be used together, they can collaborate to achieve functionality like this isomorphic, re-hydrating, SSR.
This is a hard generalization to make, but it's certainly true in the worst network condition case. Even if your client-side rendering happens instantaneously and your JS is (magically) 1kB, it's still 2 round trips before you can render anything instead of 1 (well, 4 instead of 3 for TCP connect, SSL handshake, HTML response). On poor mobile connections, a roundtrip will be 500ms+, so if you can render in less time than that on the server, it'll feel faster.
Sorry if I sound pedantic but the major gain seems to be related to the use of a cache. It is never said that "React apps render much quicker on first load". Actually, the author almost admits that its application was taking 500ms to render a page on server-side.
The issue is not so much about whether React components themselves are rendered on the client or server, it's about the network: all the JS and other data that has to be loaded in general before the browser can begin rendering.
With React you can use the same component code used on the client side to generate HTML on the server side and send that down the wire for first page load. The browser doesn't have to sit there waiting for entire libraries to load and then start building <div>s.
It does indeed appear to be so - and it works great if you disable JavaScript. In fact, if anything, it works better if you disable JavaScript, because it doesn't flicker and jump around as it renders. You might almost be forgiven for wondering why it wasn't just exclusively rendered server-side, really, except it'd probably be heretical to conceive of such an antiquated idea.
Over the years, Rails has evolved a lot of ways to do server-side rendering while sharing as much as possible between runs. React isn't there yet, but there's no reason that it can't do the same given enough time.
Until then, in many ways, as a user of a site with a modern JS-enabled browser, I'm providing my own CPU power to render dynamic content, thereby subsidizing the site's cost of supporting older/non-JS browsers with SSR at negligible cost to myself (though I suppose everyone's utility function handles occasional flickering differently). I, for one, don't see any problem with this arrangement.
Yeah, for a while we had to say ES2015/ES6 in all of our blog posts etc. but hopefully soon things can settle down. Especially when it gets to ES2016/ES7 and above, having the year in the name will be super convenient (like Ubuntu version numbers)
No weird hacks, lib includes and other nonsense you shouldn't really care about. And you can manage subscriptions to publications directly in your react components. It's magnificent.
If you were on the fence, now is a good time to jump in. It's easy to get started and you'll see that what took months in ASP.Net, and weeks in Rails, takes days or hours in Meteor. (No hyberbole)
If you don't mind spinning up your own server instances, our open source mobile JSON stack handles application level concerns like access control and data routing. Might be worth taking a look, as it gives you access to a whole open source ecosystem with support from multiple vendors and for most platforms. http://developer.couchbase.com/mobile
The only thing that I really disliked in Meteor was the reload/refresh for larger projects. This is typically a problem with anything Node related and refresh/reload times were around 10 seconds at its worst.
With the Webpack+React+Webpack, you get hot loading of only the module that has changed. Since much of the logic is on the client, your server code stays slim. Refresh times went from around 10 seconds to faster-than-I-can-notice.
Now if only there was a way to get hot module reloading working on the server...
This was my worst case and I did get it down to around 5-6 seconds by removing some Meteor packages (Meteor Toys in particular added a lot to build times but I also removed Velocity testing).
I believe they were incremental builds. Whatever happens by default when you make a change to a file.
With incremental builds. I have forked this project: https://github.com/wekan/wekan (~ medium size). On a 2014 macbook pro, reloading after a change in a template takes 10s. Not a dealbreaker, but this is frustrating. And this is with meteor 1.2. The slow build times may be due to the wierd frontend preprocessors (jade and stylus), but still.
Wekan author here. On my computer hot reload takes roughly 5s [Thinkpad T440s, ubuntu, 12go of RAM]. I'm not sure if the jade and stylus compilers add some time in the case I only modify JavaScript files, but anyway I plan to migrate these two package to support the new compiler API.
Still 5s is far from ideal considering the development experience with webpack and React hot loader.
On first glance seems like writing in React is way more verbose and cumbersome than the Blaze equivalent. What are the benefits of going the React route?
I've recently been using Meteor on a couple small projects and so far like it quite a bit. My main frustration though is unit testing. While there's the official Velocity test runner, documentation and code examples for integrating and effectively using the frameworks is very confusing (I personally use Mocha). I know there's some books and blogs to help alleviate this, but there doesn't seem to be one (or even just a few) de-facto framework/setups to illustrate how to properly unit test Meteor apps.
yeah, I'm aware of the Meteor testing manual. It has alot of good stuff, and for what I'm doing the link you mentioned mostly resembles my setup (although using mocha instead of jasmine). Just wish the testing was more "officially" documented with good examples and sample repos as opposed to buying a book. If you go on the meteor forums there is _alot_ of discussions on the different frameworks and how to piece things together.
It suggests that there isn't really that much work to do to make a basic SQL integration story that people can use. At this point when this makes it into core is a matter of prioritization and not stretching ourselves too thin.
For those with experience integrating Meteor with Angular, can you describe the benefits and tradeoffs?
Been looking to supplement or replace Angular's $resource with something a little higher-level on CRUD-heavy applications. Is Meteor a reasonable choice, or am I misunderstanding it's core value proposition?
If you're looking to replace $resource (a poor abstraction layer), you should create your own client-side model layer, or look into a library like js-data (http://www.js-data.io/docs/js-data-angular/)
I haven't tried using Angular with Meteor, but I know both pretty well. I would recommend trying Meteor with just Blaze (its rendering engine) before adding Angular. Maybe it's enough and you don't need Angular's added complexity.
The latest version of Meteor actually comes with support for Angular and React — so if you want it, it shouldn't be too hard to add. Personally, I guess I've grown a bit disenchanted with Angular lately. It makes some things easy, but I think it adds unnecessary complexity. I'm inclined to look for simpler, more functional/stateless solutions these days.
I've been on/off using Meteor for the past year. I think meteor has the potential to be the stack for developing applications in the future.
There are a few things that keep me off using Meteor.
Non MongoDB DB support
First class routing, recently the community seems to be moving away from iron router to flow router, but most of the community packages are using iron router. From my readings, they dont seem to be easily interoperable.
Interop with blaze (default view). With support for React, how do the existing community packages built with blaze be used with React
Does this release include support for ES2015 modules?
Edit:
>Meteor 1.2 will be the first step in making that seamless development experience: we're adding support for all its features except for modules
Oops. Didn't see that. This is a bit of a bummer. It'd be great to use ES2015 modules in Meteor packages. I hope there is plans to support them in the near future
I believe you still have to use a third-party package (https://github.com/meteorhacks/npm), but it's quite easy to use and I've never had any problems with it.
+1 If there's not a Meteor-specific package you're comfortable with then this is the option. Case in point, I prefer using stripe and twilio via meteorhacks:npm.
You don't have to wrap your async methods if you don't want to. Meteor prefers to use fibers since a lot of people find them easier to work with, but if you write async code it will generally work fine. The one thing is that when you want to call back into Meteor code, you need to do it in a fiber, so you'll probably want to write a little helper for that. Here's my version:
You don't have to use that. Meteor has had built-in support for npm since something like v0.6 (~two years ago). You need to declare your npm dependencies in your package.js but then you can go ahead and use `Npm.require`.
As someone who has been building on Meteor for a while and using many npm modules, I've never actually heard of "meteorhacks:npm", and to be honest I'm confused what it's for...
So, one thing holding me back from using MongoDB (and thus Meteor) is a lack of understanding how schema can be managed.
Say in MongoDB you are storing documents in a collection such as { property: "" }, and decide you want to change that to { property2: "" }. Does that mean you have to script a change to every document to convert these objects?
My go to stack for personal projects is React Node Postgres, while Meteor looks great I just can't live without the sweet built in postgres features like trigger functions. I'm on the lookout for a rails like framework because right now I tend to code everything by hand. Will give it an honest try once they support MySQL or pgSQL.
Have a look at the phoenix framework, written in elixir. While there aren't that many drag'n'drop solutions available than in meteor, everything is rock solid, fast and fault tolerant. Oh, and it is very familiar for rails developers, while also having powerful channel abstractions (incl websockets, meteor's secret sauce), postgres as default, and native implementations of channels for ios/android clients.
One of the things still holding me back from using Meteor with React is the lack of support for a module loading system.
It seems like if I want to define a component in a separate file, I'll have to assign it to a global variable if I'm going to compose it in another file.
Using global variables isn’t even the worst part. The big problem with this sharing model is that files are loaded in the alphabetical order, thus the only way to control that file a requires file b as a dependency is to give to b a file name that is before a in the alphabet (this is not true for Meteor packages where we can control the file order).
I've posted about the benefits of Meteor on HN before (the tiny apps I built were easy to do), and many times I've been told that the Meteor packages you'll use are out of date and require effort to make work. On this thread however people are saying using Meteor is buttery smooth. Any people care to chime on this issue? Without diving in myself and building a large app, I'm having a hard to determining if the Meteor package ecosystem is thriving or stagnating.
I've yet to come across a situation where something I wanted to do didn't a) have an existing Meteor package, or b) have an npm package that you can include using meteorhacks:npm by arunoda. I'm using Meteor for two enterprise-grade b2b projects (so: reasonable scale) and as far as I'm concerned the package ecosystem is freakin awesome.
There's one issue with Meteor that rarely gets mentioned. While you get hybrid mobile apps out of the box, you'll have hard time integrating native apps with Meteor backend. DDP clients are not official, and there's no minimongo on native clients so you lose critical part of Meteor's appeal. In the late game switching to native apps is more cumbersome compared to when you have a regular REST API backend. But still, Meteor is a amazing piece of technology and I'm happy to see this update.
Is it fair to say that Meteor is an alternative to Relay and Falcor for managing state with the server? It also seems like it's competing with Redux and all the Flux libraries, right?
The plus side of all this is that React seems like it's becoming the ubiquitous "V in MVC". This is great news, since this means designers should soon feel at east working with JSX, regardless of which platform the company uses. It also should mean that using Meteor for developing mobile apps using React Native should be straightforward..
Not sure if I'll get into using Meteor, but I'm definitely very glad I have a head start on React..! Truly a technology worth mastering.
Meteor is awesome! Really happy to see these latest changes - I'm excited to get started with ES6 and also get away from Blaze and start using React. As soon as they release SQL support, Meteor is really going to take off.
For those of you on the fence about using meteor, I highly highly recommend it. It's silky smooth and really easy to get a basic webapp up and running (check out https://github.com/themeteorchef/base for a great starter repo that I use all the time)
I've worked with Meteor on and off for the past few months and it's very fun and fast for development. It's very exciting to see how quickly Meteor is moving ahead. I'm eagerly awaiting the official release of Galaxy as production deployment is a bit involved with different options to piece together for Mongo and Node hosting.
My biggest concerns are the lack of official support for server-side rendering, routing and relational db. Although, many of the common concerns you'll see in the HN comments are on the development roadmap[1].
139 comments
[ 3.0 ms ] story [ 187 ms ] threadThey just keep on delivering on out-of-the-box functionality, compatibility with 3rd party libs, and more importantly - on a very solid architecture for real-time transport by guys who really know what they're doing.
Kudos everyone.
The platform is not just for playing around anymore, it has matured really well. See the case studies[1] - I, for example, love Hansoft X[2].
I think I would feel frustrated to have to go back to any other framework. Meteor is what web-development should be like. I'm not sure if Meteor is going to be THE platform everyone is going to use, but it definitely is completely changing the game and I suspect web-developers will be adopting the Meteor ethos.
[1] https://www.meteor.com/case-studies/build-apps-with-meteor [2] https://hansoftx.com/
I don't think either that Meteor is going to become de facto platform for all web development, but it's definitely going to be one of the main ones along with Angular, React and Rails.
It's interesting also that people always talk about Rails but don't mention JSP and .NET, which I think are actually a lot more popular last time I looked around. I guess it depends on who you ask.
I feel like JavaScript is in a sweet spot right now because it has the inherent advantage of being the _only_ language you can run inside a browser, so you can do things with it that would be very hard or complicated in other languages.
And, though I know this has been said before, it bears repeating: most developers who deal with data on a regular basis are best advised to go ahead and get comfortable with SQL. So far, it is BY FAR the best solution to the great majority of data-storage-and-retrieval use cases. I'm no expert, tis true, but I don't see JSON objects replacing SQL any time soon.
So, yes: as soon as Meteor includes official support for one of the SQL platforms, I'm all over it. It seems very promising, for those of us not locked in a death-rattle of foaming, red-faced JavaScript hatred.
I wish I had a more educated answer (guess?), since this is all just anecdata.
Actually, they have: https://reactioncommerce.com/
Meteor has been perfect for me. It works, I can easily integrate with it via the Mongo back-end, and the prototyping is super-fast. For the kinds of apps that I build (very industry specific apps for retail) I don't really have to worry about scaling to thousands of users, which means that Meteor isn't just a toy in my world. And even if I did have to scale, everything about the Meteor framework indicates that scaling Meteor is no different than scaling any other Node app.
When Postgres support comes, (its in the works) I'll be using this thing for everything.
I don't want to be the first person attacking a completely new class of scaling problems using a proprietary tech stack that I may or may not have the ability to control.
The other piece is the meteor stack is designed to be hosted by meteor. Sure, you can, in theory, run everything yourself - but I haven't seen good case studies of that. What do you do when your app blows up and suddenly the hosting costs of meteor is too much of an overhead?
I use Digital Ocean with MUP and it works great with minimal efforts.
What kind of load does that app you host on digital ocean have?
Edit: I'm not at all suggesting that isn't possible to self host a meteor app, I am saying that I don't know what the "beaten path" is for other companies/apps/products that have self hosted a meteor app to a significant scale.
As the lead developer of Sandstorm.io, I have deployed Meteor:
* As the Sandstorm front-end, where Sandstorm is designed to be installed by end users on their own machines.
* As apps that run on Sandstorm, and are designed to be extremely fine-grained (each app instance handling a tiny amount of data, e.g. a single document).
* As oasis.sandstorm.io, a highly-scalable centralized Sandstorm host.
* As apps.sandstorm.io, a fairly mundane use case (whereas Sandstorm is, comparatively, highly unusual).
I would argue that Meteor is not at all designed for Meteor hosting. Rather, Meteor is designed such that anyone wanting to build a PaaS around it will have a much easier time doing so than they will with just about any other environment. On Sandstorm, we find Meteor apps much easier to package than anything else, because the Meteor tools will output a self-contained app bundle that operates in a consistent fashion for all apps -- thus allowing us to write a common packaging tool that works with all Meteor apps. Other stacks are comparatively much more fiddly.
I would expect Meteor's hosting will turn out to be the best way to run Meteor apps primarily because they have kick-ass engineers there who will build an awesome product (disclosure: I know several of them), not because they've biased the framework in their favor.
What does that mean exactly? I admit, I only kind of know what sandstorm does from it's marketing page (looks like it offers VM's in a more user friendly way with an emphasis on security)
In what way does Meteor allow you to produce quicker or more efficiently than if you went with any standard linux stack?
Try installing Wekan, which is a Meteor-based app.
The thing that makes Meteor easier for us is, as I said, the meteor tools have a command "meteor build" which gathers all of the app's code and package dependencies and puts them into a self-contained directory tree with a start script that is executed the same way regardless of the app. This makes it easy for us to build a tool which turns any Meteor app into a Sandstorm package because the input is in a well-defined, self-contained format.
We are, of course, building tools for other stacks as well. It just takes more work.
I think inevitably the meteor team will bring this into core, or something similar, and we will be able to have our mix of atmosphere and non libraries.
Iron-Router was the lead for a while.
I don't think these should necessarily be in core, but here is my list of pretty much always-installed modules:
stevezhu:lodash iron:router meteorhacks:npm meteorhacks:async aldeed:collection2 aldeed:autoform aldeed:tabular xolvio:cucumber yogiben:admin
Can meteor apps be isomorphic -- in the sense that they render plain HTML on the server during first load, and then do the javascript loading thereafter?
I work on several client websites, and passable SEO is a requirement.
I know there's some hackery you can do to get single page apps to be indexed, but I prefer when it "just works" out of the box.
I have some react apps that use this model, and they index perfectly.
You need to use React though, but that's a win in my book since React makes developing Meteor apps so much easier.
There are already some community projects working on this functionality: https://atmospherejs.com/reactrouter/react-router-ssr
source?
With React you can use the same component code used on the client side to generate HTML on the server side and send that down the wire for first page load. The browser doesn't have to sit there waiting for entire libraries to load and then start building <div>s.
More info: https://kadira.io/blog/meteor/meteor-ssr-support-using-flow-...
Over the years, Rails has evolved a lot of ways to do server-side rendering while sharing as much as possible between runs. React isn't there yet, but there's no reason that it can't do the same given enough time.
Until then, in many ways, as a user of a site with a modern JS-enabled browser, I'm providing my own CPU power to render dynamic content, thereby subsidizing the site's cost of supporting older/non-JS browsers with SSR at negligible cost to myself (though I suppose everyone's utility function handles occasional flickering differently). I, for one, don't see any problem with this arrangement.
More and more companies are using React now in the startup space, and it's one of the most popular services on StackShare: http://stackshare.io/meteor
React integration is a first-class citizen: http://sergiotapia.me/2015/09/18/react-and-meteor-match-made...
No weird hacks, lib includes and other nonsense you shouldn't really care about. And you can manage subscriptions to publications directly in your react components. It's magnificent.
If you were on the fence, now is a good time to jump in. It's easy to get started and you'll see that what took months in ASP.Net, and weeks in Rails, takes days or hours in Meteor. (No hyberbole)
https://github.com/ccorcos/meteor-any-db
I'm happy to wait until then!
[edit] Here's a little hello world tutorial I wrote a few months ago with Couchbase Lite and React Native. https://gist.github.com/jchris/3c32524577deff3d69aa
I'd highly recommend this new project for Meteor+React+Webpack:
https://github.com/thereactivestack/meteor-webpack-react-kic...
The only thing that I really disliked in Meteor was the reload/refresh for larger projects. This is typically a problem with anything Node related and refresh/reload times were around 10 seconds at its worst.
With the Webpack+React+Webpack, you get hot loading of only the module that has changed. Since much of the logic is on the client, your server code stays slim. Refresh times went from around 10 seconds to faster-than-I-can-notice.
Now if only there was a way to get hot module reloading working on the server...
I believe they were incremental builds. Whatever happens by default when you make a change to a file.
Still 5s is far from ideal considering the development experience with webpack and React hot loader.
On first glance seems like writing in React is way more verbose and cumbersome than the Blaze equivalent. What are the benefits of going the React route?
https://github.com/xolvio/Letterpress/tree/master/app/tests/...
ES6 modules will change this approach somewhat, FYI
It suggests that there isn't really that much work to do to make a basic SQL integration story that people can use. At this point when this makes it into core is a matter of prioritization and not stretching ourselves too thin.
Been looking to supplement or replace Angular's $resource with something a little higher-level on CRUD-heavy applications. Is Meteor a reasonable choice, or am I misunderstanding it's core value proposition?
There are a few things that keep me off using Meteor.
Non MongoDB DB support
First class routing, recently the community seems to be moving away from iron router to flow router, but most of the community packages are using iron router. From my readings, they dont seem to be easily interoperable.
Interop with blaze (default view). With support for React, how do the existing community packages built with blaze be used with React
Edit:
>Meteor 1.2 will be the first step in making that seamless development experience: we're adding support for all its features except for modules
Oops. Didn't see that. This is a bit of a bummer. It'd be great to use ES2015 modules in Meteor packages. I hope there is plans to support them in the near future
>Eventually, Meteor wants to transition to ES2015 modules for everything
https://github.com/meteor/meteor/blob/303052be68128ce9026bc2...
I'm really curious about how people compare this with native dev especially right now most startups chose native approach.
The decision to be incompatible with the vast number of Node/npm modules is what originally turned me off from Meteor, and I hope it's resolved.
I just don't understand why Meteor decided to be incompatible with the vast majority of server-side JavaScript in the wild.
https://github.com/sandstorm-io/sandstorm/blob/master/shell/...
As someone who has been building on Meteor for a while and using many npm modules, I've never actually heard of "meteorhacks:npm", and to be honest I'm confused what it's for...
https://github.com/meteor/meteor/blob/devel/History.md#v060-...
Say in MongoDB you are storing documents in a collection such as { property: "" }, and decide you want to change that to { property2: "" }. Does that mean you have to script a change to every document to convert these objects?
And yes, you have to script a change to every document.
In MongoDB you have to manually walk all your objects and migrate them.
`Collection.rename('property', 'property2')`
my syntax may be slightly off since i mostly use mongo thru a ruby orm but the basic idea is the same.
we handle these things by having a tasks we run each deployment (named after the deployment version) with the necessary db changes.
It seems like if I want to define a component in a separate file, I'll have to assign it to a global variable if I'm going to compose it in another file.
Thankfully MDG plan to address this issue soon.
Is there a fix in the works for this?
The plus side of all this is that React seems like it's becoming the ubiquitous "V in MVC". This is great news, since this means designers should soon feel at east working with JSX, regardless of which platform the company uses. It also should mean that using Meteor for developing mobile apps using React Native should be straightforward..
Not sure if I'll get into using Meteor, but I'm definitely very glad I have a head start on React..! Truly a technology worth mastering.
For those of you on the fence about using meteor, I highly highly recommend it. It's silky smooth and really easy to get a basic webapp up and running (check out https://github.com/themeteorchef/base for a great starter repo that I use all the time)
My biggest concerns are the lack of official support for server-side rendering, routing and relational db. Although, many of the common concerns you'll see in the HN comments are on the development roadmap[1].
[1] https://trello.com/b/hjBDflxp/meteor-roadmap
http://meteorpad.com/ (JSFiddle-type thing for Meteor)