Hacker News Reader

Comment by debergalis | Hacker News Reader

[meteor dev] Please come help us with this! We have six engineers at Meteor and dozens more contributors in the community working on the platform every day. The plan to 1.0, including REST, is at http://roadmap.meteor.com/.

Here's the guiding principle behind Meteor. There should be a dramatically faster, more accessible way to write applications. Improving that developer experience means rethinking some things: autopublish and minimongo, so you can jump right into a new app's UX in the first five minutes; one-line authentication (http://meteor.com/authcast); synchronous APIs that are more comfortable for a lot of developers; dirt-simple reactive templates; hot code push.

Focusing on that kernel of development experience means some other things -- REST, routing, form building -- need more time to fully bake, with hacks like __meteor_bootstrap__ and phantom for apps that need them now. We think that's a good tradeoff pre 1.0.

View on HN

I was excited using meteor but was sadly disappointing after a couple days of "banging my head on every simple things I tried". As far as I'm concerned, Meteor is a big "Screw everything that exist, it sucks. We're better and we've got the time and money to re-build all the life from scratch".

So, in a way, that's great! An mental orgasm for any nerds out there. But in the real life when shit needs to get done, I'm still using everything else that sucks.

Now, before people start saying I don't know what I'm talking about, here are a few examples: - It does NOT use npm (!) -> Basically, you can't use anything without first converting it to Meteor. - It does NOT use Express (Or connect) as its base -> Basically, the standard in the Node community. That means I can't just plug-in the 20 or so awesome plugins built explicitly to be used by any kinds of node application that support connect.js - The current Asynchronous (following node's philosophy) wasn't good enough for them; so the re-created a whole new Mongo version acting synchronously.

But most importantly, it's just extremely annoying to hack with it. It's like a big black box.. you're not very sure what it does and you hope it works. But when it's not working, you can't just hack it your way or read the source. It's a little bit like Django or Rails (but in worst) as you can use SQLAlchemy in Django, or you can use different template engines, but then no project from the django community will work with your app.

The good news is, the meteor team is working hard. Maybe in a couple years it will be stable enough and iterated fast enough to provide a platform where it will be fun hacking and building web apps. But for now, I sadly prefer to stay in the "Everything else sucks" world and hack my way in the node jungle.

(For those interested, I have also tried Derby. As said in the article, it's not yet fully stable and the documentation is really Meh. But I think it's going to be big really soon and I'll be more than happy to give it another fair try. So far, I'm sticking to a basic express (Or locomotive.js which is nice.) I'm also using Angular.js on the front-end. It's something amazing as I feel very productive and it saves a tremendous amount of time.. but at other moment, I just bang my head against the table as I want to do something simple and it's just impossible so I need to use all kind of hacks to do what I'd have done in a couple lines in Vanilla Javascript. Oh well. Hard to be a hipster web developer trying all new technologies :-))

What blocks you from digging into the source? I want to make that easier for you.

Nearly all of the Meteor code is broken out into various packages. They implement components like publish/subscribe, client-side data caching and snapshotting, reliable remote method invocation, live page updates, and hot code push. They're the building blocks for a rich client application.

Now, we have some work to do on better separating those components so that you can pick and choose the parts you want, like using livedata (publish/subscribe) with Angular, or using Spark (our reactive page update engine) with a legacy REST endpoint instead of livedata. Those combinations are technically possible today, but not particularly accessible. They should be.

(That is one of the two front-burner project we have going today. The other is scaling.)

What blocks me from digging into the source is mostly that even if there are separated components, I still need to understand all the aspects of Meteor. I can't just open the file and change it. Will it screw up the deploy system? Will all the data-binding continue to work as expected? Maybe yes, maybe no. Unless I totally understand the system, I can't really know.

You say "like using livedata (publish/subscribe) with Angular", but that's the problem I'm talking about. You need to tweak the system to make it work with Angular. But what about the hundreds of other smaller angular-like libraries? Or tomorrow's most popular one? I can't just <script src="it">, I'll need to create a meteor package and make sure it works good with all the rest of the system (Which unless I'm a Meteor expert, I have no way of knowing).

That could actually be a good blog article, "How to use MooTools, django template system and MySQL with Meteor". I.e. Going through what's needed to be tweaked to make it work. Compared to say, express, I could tell you use the mysql node library, normally include mootools in your html files and use mustache (Or whatever library already exist to mimic Django's libraries).

There should be a dramatically faster, more accessible way to write applications.

You do realize this is the holy grail of software development? The thing we've been seeking since, oh, at least the mid 1950s.[1] Pretty ambitious to think you'll crack the nut, at least more than momentarily.

[1] http://en.wikipedia.org/wiki/FLOW-MATIC

Is it not a rule that a novel application will break the paradigm that other applications follow and hence leak out of the abstractions that allow the traditional application to be written quickly?

Copying is dramatically faster than doing something new.

I'm keeping my eye on Meteor. As it stands I don't feel that anything in the Node ecosystem compares to the daily ease-of-use I find in my Rails environment (and I know Rails isn't exactly a peach). I like that you guys seem to be trying to do some things different, the fact that you're not using NPM could also be considered a boon rather than a defect. I'm not sure I how much I like NPM, but I'm arguably not a Node expect.

Meteor is one of the most exciting things I've seen recently. Will gladly help, what things you need most and how one get started? and do you accept people that like TypeScript, Java, Scala and come from the enterprise world? :)

Yeah, absolutely. See http://roadmap.meteor.com/ for the high-level view and http://github.com/meteor/meteor/issues for some starting points on building out code. Another good option is building Atmosphere packages at http://atmosphere.meteor.com/.

Reply on news.ycombinator.com