Yes…at the moment heading more to being Tomcat, rather than Sun 
React.js has a shitload of advantage over Blaze:
- Simple component that you can reuse (Blaze is not even close at being good at that once you want just a little bit of composition)
- Communication between your components is so easy and effective (with Blaze communicating between templates is aweful)
- You don’t need a special template language. It is javascript and HTML.
- Your business logic is wrap with the HTML which makes sense once you really give it a shot. It forces you to make small component that do a really good job at one thing only.
- Each component manage their states instead of using an aweful Session variables
Just to name a few
2 Likes
UPD this is not a replay to @XTA; I can’t remove replay mark.
All this discussion pushed me to these thoughts:
1. NPM vs Meteor Package System
Problem:
We have two separate worlds: NPM and Meteor; there is no no-hacky way to use npm packages.
How we solve this problem at the moment:
We use meteorhacks:npm package or webpack or npm-packages which are wrapped for meteor or we wrap npm-packages manually.
Bright future I see, step 1:
Meteor natively supports NPM packages and do it in elegant and super-easy way. If you want to use non-Meteor-specific package, you install it via NPM, if you want Meteor-psecific package, you install it via Meteor. Just like nowadays but easier and smoother. So we still have two worlds, but they are not separated anymore.
Bright future I see, step 2:
This is a several-years-later future. NPM is improved and has very good support for isomorphic code. There is no need to keep Meteor-specific packages in Atmosphere. NPM now allows you to write Meteor-specific packages. All existed Meteor packages can be converted to NPM. Now we have single JS world where Meteor is just a part of it.
2. Meteor build tool
Problems:
Sharing variables via global namespace, no way to control file load order, no commonjs/es6 modules support; there is no way to adjust build process.
How we solve these problems at the moment:
We use packages that allow us to use es6 modules (universe:modules/rocket:module/whatever); we use webpack to control build process and use es6 modules.
Bright feature I see:
Meteor natively supports modules and allows us easily integrate with Webpack (or any other build-tool solution), though, maybe with some limitations. So we have a choice: write no configuration (then Meteor will build project as it does now) or write some configuration and adjust build process.
3 Likes
+1 Agreed. However I hope MDG can innovate fast enough to keep up. The differences IMHO are:
- Relay works with any DB or backend system
- Meteor is a lot easier to get going than Relay
- GraphQL is arguably more elegant for the consumer (front end dev)
- Relay sends more effecient payloads than Meteor (in my limited tests)
I’m afraid that someone will seize the opportunity to create a framework to abstract away a lot of Relay’s complexity for greenfield apps.
This means that the main differentiater is fibers… and stable async/await is getting closer by the day.
1 Like
That’s a great list. We’re on it :]
The most exciting thing for me about this thread is that I haven’t seen anything that we haven’t thought of yet inside the company, which leads me to believe we all (people in the thread, and developers at MDG) have a good handle on the state of the universe right now.
Personally, I think we’ll need to kick things up a notch in terms of development velocity of the framework to keep up with all of these new options in the ecosystem, but I think we have learned so much in the last 4 years of working on Meteor and talking to people who use it to build real apps that we can do it.
17 Likes
This is good to hear 
I think it might be similar to the case of a freelance developer working heads down for weeks thinking all is well and the client is freaking out because they haven’t heard any news and assume they’re being billed for little/no work… when in fact a few check in emails solves the issue.
1 Like
Yeah. I think there are tradeoffs though. For example, it could cause more harm than good if we post all of our new ideas as soon as they come to mind because it would end up with a very fragmented and unstable outlook. It’s definitely about striking a balance, and I completely agree that we should be communicating more than we are.
As soon as we have something concrete to share and discuss, we’ll make sure to make it as public as possible. We’ve been experimenting with stuff like that, but we need to do more of it, and I’m personally disappointed that we haven’t done a better job but very optimistic for the future.
One aspect of things is that we have been working very hard on Galaxy which has taken a little focus off of the framework in the last couple of months, but will be very important to make the whole ecosystem more complete and legitimate. The best thing that can happen to Meteor is to have a strong base of successful businesses built on top of that, and Galaxy is the last significant missing piece of that puzzle.
My goal is that the next few things we announce on the framework side can all be squarely in the realm of “yes! that’s exactly what I needed!” and not something that’s like “wait why are they doing this”.
13 Likes
Why don’t you think of NPM as a great idea? Meteor in JavaScript world is like Ruby on Rails in Ruby world. Ruby has Gems. JavaScript has NPM.
Rails, my friend… has gems that are well - for Rails. And Node.js has NPM (not the entire JS world evolves around Node…). I like packages that will work with Meteor anywhere. And if I need a NPM, there is https://github.com/meteorhacks/npm
You can write NPM package which will work only for Meteor and only Meteor developers will use it.
Yep. It’s a religion. All your base are belong to us. Don’t worry. We won’t ask tithes or offerings every week. We do regular exorcisms.
Meteor is very great for quick start and newbies, but it becomes hard when you write big applications…
Big applications always become hard. Migrations, backward compatibility, deprecated API, naming things, changing things that break things, build tools. Maybe it is not Meteor, but the methodology you are accustomed to. Empty the cup, empty the cup.
I just want meteor to be the part of that all-rest-javascript-world.
I just want a drone that fetches my coffee and plays the StarGate theme when flying.
I think Meteor has a very good package Manager. I know MDG has invested a lot to make a such a good package manager. It’s far more effective than NPM is few ways.
Master Jedi speaks.
I don’t really understand all this hype on React. ERb in the Rails world is not that different from Blaze…
Blasphemy. Erb is dynamic templating. Blaze is reactive dynamic templating. Biggie.
But on its side Rails had applications like Twitter and Github since the beginning. That’s the point.
I still believe that Git had the most major influence for GitHub success. And Twitter because three billion people felt the need to announce their bowel movements from the beginning. Meteor is the cool party at hackathons and in secret batcaves.
Yeah. I think there are tradeoffs though. For example, it could cause more harm than good if we post all of our new ideas as soon as they come to mind because it would end up with a very fragmented and unstable outlook. It’s definitely about striking a balance, and I completely agree that we should be communicating more than we are.
Love.
One aspect of things is that we have been working very hard on Galaxy which has taken a little focus off of the framework in the last couple of months, but will be very important to make the whole ecosystem more complete and legitimate. The best thing that can happen to Meteor is to have a strong base of successful businesses built on top of that, and Galaxy is the last significant missing piece of that puzzle.
Love.
4 Likes
Lots of really great discussion happening on this thread!
I just want to chime in with my two cents, as the person who designed and implemented most of the new compiler API.
For what it’s worth: I mostly agree with you! I’d love to get the Meteor platform to a place where we don’t need our own custom build and packaging system.
The goal of the 1.2 batch build plugin API is to make an incremental and mostly backwards-compatible improvement to the Meteor build system. A large number of bug reports and feature requests over the years for things relating to CSS preprocessing and other build-time operations were not fixable because the design of the pre-1.2 build system did way too much before you ran meteor publish and not nearly enough in the context of an individual app.
The goal of the 1.2 build APIs is to simplify the package and build system by making “publish this package” a lot closer to “put the source files in a tarball”, and “build this app” be where the real processing happens. While it may seem like the point of the change is “look, here are new APIs you can use”… the real important part is that published packages contain source files instead of overly processed files.
But just because this is the incremental improvement we’re making now doesn’t mean we’re not considering more overarching changes later
16 Likes
We’re using React and need a clear answer to the question: Why use Meteor/Galaxy rather than Firebase? I understand that they are not the same, but my point is that Firebase offers a commercial, scalable and simple solution to our problems.
I’m not sure if you have experience with Firebase but there are two very big problems with building any application to scale in firebase IMO.
- It is a RAW document database. It does not offer any semblance of query helpers and async methods for getting documents makes it very hard to retrieve 2 or more documents easily.
- The cascading security rules very quickly get out of control as you try to figure out where to keep what data because you are not only constrained by denormalisation but you can’t have sensitive data as a child of public data since security rules cascade. So scripting rules complexity outgrows db complexity.
Having done a simple proof of concept project with angular+firebase, I would NOT recommend even building out a MVP with it.
I absolutely love Firebase - but you have to know about it’s expected use-cases. Building a real-time fitness tracking service – great. Building a secure, PCI-compliant easy-to-query solution – yea, not so much. I was trying to build a big app on it in the past, and the security rules are very hard to write as mentioned above, I needed advanced querying which was/is unavailable, and adding multitenancy is a p.i.t.a. because of the dbms constraints.
2 Likes
This thread got me thinking about opinionated frameworks vs open ones, especially with respect to how it affects package authors and users.
We have more choice than ever at each layer of the stack now. Iron Router vs FlowRouter. Blaze vs React or Angular.
An open philosophy means ever increasing choice, and we like freedom of choice.
But Atmosphere packages will need to limit what they support, making it harder to find one that fits your customized stack and harder to publish ones that work for most people.
Which do you prefer? Just for fun, here’s a poll:
@pauldowman how do you expect us to participate in a survey that requires
- having a facebook account
- joining a closed group
- waiting for approval
- remembering that there was a survey somewhere
7 Likes
I know, Facebook doesn’t make it easy, but it’s as open as a Facebook group can be, anyone can approve you and it doesn’t usually take long. I know many people won’t bother. But it’s the easiest place for me to post a quick unscientific poll and have a conversation around it.
2 Likes
I think this is a great point. It’s more important now to make packages de-coupled and view independent (and DB independent when SQL comes).
Take FlowRouter for example. It’s very decoupled and doesn’t concern itself with the view. However the author provides blaze layout and react layout to use with it.
Reaktor takes these two packages and makes a react specific implementation with very little code. Think about how much work would be saved if Iron Router packages would have abstracted away the iron router part. They could have updated for FlowRouter in one line. This could be used with autoform and react/blaze/angular/etc…
1 Like
Haha, that’s hilarious.
Theoretically your idea is good. Practically BIG NO.
You just waste your time. And after you waste much time, most of them aren’t work, especially for newbie.
Then you visit atmospherejs.com, searching packages. Install it. Following instructions and it’s work a minute. And you yell “damn it, why don’t I use meteor packages sooner”
I love meteor, MDG, and community
I’m releasing a new version of AnyDb soon. Using it in production 
8 Likes
Any work with RethinkDB yet? I think that’s what I’m looking forward to most.
2 Likes