Create a web app from scratch in under 5 minutes with Meteor and Mailgun

http://blog.mailgun.net/post/41958103075/create-a-web-app-from-scratch-in-under-5-minutes-with

by twakefield • 13 years ago

150 105 13 years ago

blog.mailgun.net

SebdL• 13 years ago

Good job to Vianney... our French Meteor Earlyvangelist!

acemtp4• 13 years ago

Thanks

islon• 13 years ago

"French Meteor Evangelist" is one of the coolest titles I ever heard. Makes a great business card.

acemtp4• 13 years ago

Good idea! Let's dok it so I'll not forget :)

alecocq• 13 years ago

Great article from Vianney , easy to read, easy to understand

erkin_unlu• 13 years ago

two questions: is it easy to get started? is it easy to customize according to my needs in advanced later stages?

acemtp4• 13 years ago

Get started to Meteor? I never create web app so quickly! For the customization, it depends what are your needs. Meteor is clearly cool to make collaborative web app;

If it's about Mailgun, you can get started for free without any configuration and if you want to send more than 300 emails/day later, you can create a mailgun account and easily integrate your own SMTP credentials into the app using the steps outlined in the blog.

seivan• 13 years ago

Anyone who says "5 minutes implementation" to me, get's a nice and sound "GO FUCK YOURSELF"

EDIT: Usually it's the business monkey, UX snake oil guys and product leeches that say "Hey, that will only take like 5 minutes, right?"

fatbird• 13 years ago

Don't "from scratch" and "with Meteor and Mailgun" contradict each other?

alexandros• 13 years ago

“If you wish to make an apple pie from scratch, you must first invent the universe.”

― Carl Sagan, Cosmos

cuttooth• 13 years ago

It's basically the same thing as Rails people saying "you can make a blog in five minutes!", because you really can't.

(This isn't a knock against Rails, it's just that five minutes barely gives you time to open the documentation and start to actually get an idea of how a library/framework is designed.)

friendly_chap• 13 years ago

5 minutes _once you know it_

ehutch79• 13 years ago

Why is this getting downvoted so much? Just the language I hope. because there is a point there.

Everytime I see a meteor post, I get the feeling the article is telling me I'd be a fool to use anything else.

Assuming that's so, can we start talking about things like PCI compliant meteor apps. And what the security landscape looks like since you can interact with the data store via your browser's javascript console.

patrickleet2• 13 years ago

The data store on the client side isn't the whole data store, it's the things you've published and subscribed to, which can change easily based on authentication, your userId, or however else you program it.

Meteor has an "insecure" mode that is active by default where everything is published. Don't use that in production.

JPKab3• 13 years ago

"And what the security landscape looks like since you can interact with the data store via your browser's javascript console."

By default, Meteor is in a "development" mode where all the security is off while you get the app doing what you want on localhost. The security is implemented later by turning off the autopublish feature and using authentication at the pub/sub level in the "model" component of the MVVM stack. At this point, when you try to do what they do in the demo, and change data from the browser console, it will make the change in the client for a split second, but that change is rejected at the model level, and the client resyncs with the model and the change is undone in the view.

BTW, I only "learned" (i'm not at all an expert) Meteor a few weeks ago (although I've been following the project since they first announced it 10?? or so months ago.) It's actually pretty straightforward once you get the hang of it. But it is unmistakably a BIG FRAMEWORK in the Rails sense, whereas everyhing else in the Node world is truly modular in the Node fashion, with full transparency into what's going on. For people who like that, check out Derby, and it looks like there is some more stuff in the pipeline with Rendr by the dudes at AirBnB.

sergiosgc2• 13 years ago

I usually read it as: "this is a tool that will provide quick results at the expense of other factors". Usually, the other factors are:

1. Flexibility: The tool has limited scope and has used this limited scope to make decisions for you; or

2. Maintenance: The tool uses code generation. Maintenance cost grows with the amount of code, indifferent to its origin (generated vs manual).

Rails, in particular, suffers from problem 2.

dreamdu5t• 13 years ago

Because people are always looking for the easy way out. And Meteor wants press.

sid63763• 13 years ago

Meteor sounded like a really good concept and I wanted to give it a decent shot. However I could not find a getting started project. The ones I found were very trivial and did not go much into details. I couldnt really find a lot of documentation about how to create an app which used 40-50% of the features which will be used by the majority of the crowd. But I will give it another shot and probably write a polls app (ala Django getting started) in meteor.

javajosh6• 13 years ago

   meteor create --list

Personally, I think the `parties` example is a good one, so you can do:

   meteor create --example parties

Enjoy.

sid63763• 13 years ago

Thanks a lot. Checking the code now.

1qaz2wsx3edc• 13 years ago

The parties examples only uses a static map (lame), they make no use of google maps or leaflets. Try using an infoWindow. You can't, it's not easy. You're productive will be stone walled with the simplest of integration. (This is a limit of constant regions and how meteor handles controlling a piece of the dom). Working with maps or third party libraries is a common task.

So, given that common tasks become stone walled and meteor promises productive. I'm waiting for 1.0, meteor is all too young.

I do love some parts of the pattern. I'm surprised that it hasn't been done before; like years ago.

yarone• 13 years ago

A handful of really great Meteor.js screencasts, here: http://www.eventedmind.com/

sgdesign• 13 years ago

Have you seen Telescope? http://telesc.pe

It's basically an open-source HN clone built with Meteor, it's a good place to get an overview of the various features you need to build a useful app.

jaequery• 13 years ago

whats the difference between mailgun and sendgrid?

sid63763• 13 years ago

Some links for you: http://www.quora.com/Why-are-Mailgun-and-Postmark-so-much-mo...

http://www.sitepoint.com/email-as-a-service-part-2-sendgrid-...

twakefield2• 13 years ago

Full disclosure: I am the OP and work at Mailgun

This is tough for me to answer objectively, but I'll do my best.

Both services offer many of the same features and eliminate the pain of managing your own email server. Both services will achieve better deliverability at scale than managing your own server unless you know what you are doing and most people aren't interested in diving that deep into email.

Mailgun is very focused on serving developers and that guides our product roadmap. Therefore, we don't offer features like WYSYWIG newsletter creation tools. We build everything API first and we strive to make them RESTful, intuitive and well documented. Admittedly, our GUI / control panel is not the strongest part of the product. We also focus a lot on incoming email and we are pretty proud of our inbound email parsing through Routes. Mailgun is owned by Rackspace (acquired in Aug 2012).

Sendgrid is definitely the largest transactional email sender in the market. I recently read they do something like 7 billion emails monthly. They have more tools for non-developers like newsletter creators and support language wrappers that some developers prefer. They also offer inbound through their Parse App. Sendgrid is an independent, private company that has raised $27.4mm in funding according to Crunchbase [1].

My recommendation would be to try both - the docs are all online and both offer free plans to test with.

[1] http://www.crunchbase.com/company/sendgrid

pfraze2• 13 years ago

Mailgun sounds like a really good fit for me. I'm running a couchdb server, and I want to set it up to POST to my DB. Dump straight into my document store, life is good.

I did a quick try at it and ran into a 415 from couchdb, which means mailgun didn't send json. Is there a way to configure a route to do that? If not, I'll have to write a custom _update handler.

lobster_johnson• 13 years ago

Our SendGrid experience has been middling. We have fought a half dozen of bugs -- the week I was implementing it our first app I had seven tickets open in their support system -- with admin screens that time out or don't work, APIs that time out, etc. Everything from the APIs to the admin just feels a bit unfinished and amateurish.

Support has been very lacking. At one point I had waited a long time (a week?) for a ticket response while they said they would investigate, and suddenly they just closed the ticket with no explanation. I felt like I had to fight to get any attention.

That said, its delivery seems reliable.

We have since switched to Mailgun for a lot of stuff, and will be migrating the rest soon. Mailgun has been rock solid from the start, the admin screens are fast, the APIs just make sense, and they were really responsive when we asked about a missing feature. Unlike SendGrid where the delivery log took ages to show results, Mailgun's equivalent page is really snappy. A big time saver when someone complains about not receiving a password or something.

Mailgun is also quite a bit cheaper.

nedludd2• 13 years ago

"Type this code and run it".

Hey, I can teach you the theory of relativity in 30 seconds: type this "e=mc2".

dxbydt• 13 years ago

O'Reilly: Teach yourself xyz in 14 days...

Me: But...but..how does this all work? Why?

Harvard University Press: Why? That's us! Dude check us out !! The 600 page book on the top rung with no cool memes and 1980 typeface. That's us.

bpatrianakos2• 13 years ago

Yeah, I feel the sentiment. When I read this I was like "really? 5 minutes? Are we really learning anything other than how to follow instructions here?". But I'm in a bad mood so I have to admit I'm being unfair. There's a part of me that's getting a little tired of these kinds of posts because they're often disingenuous. You're really not going to learn or build anything of real use in under 5 minutes. It's definitely a cool marketing ploy for both Meteor, who get some exposure, and Mailgun who may get some new paying customers.

But again, I'm being unfair. While what I said before still stands, there is the fact that I doubt anyone expects you to truly learn the framework in 5 minutes. It's just supposed to be an example of how easy it is to get started. And it works I guess. I personally have never gotten much out of the whole "X in Y time" genre of tutorials but I'm sure others do. Because I'm not new to programming I prefer to take my time and build out my own ideas as I follow these things. So while I read them I'm not actually following each step. I'm just understanding how you get from A to B, translating that to other tasks, and using pieces of the articles as I need them to suit my purposes if that makes sense.

rfugger• 13 years ago

Peter Norvig: Teach yourself programming in 10 years.

http://norvig.com/21-days.html

scottmagdalein3• 13 years ago

This isn't a "learn how to be a programmer" tutorial. This is a "look how easy Meteor makes getting something simple built and deployed".

So instead of the theory of relativity, how about using a calculator to do your taxes.

nedludd2• 13 years ago

Fair enough. But this is still not teaching me much about actually writing an app in Meteor. It tells me to type the code in, not how it works or what it all means.

To use the calculator metaphor it would like saying: "enter 75345 + 3455 / 4, there's your taxes!"

don_draper2• 13 years ago

Why does HN not like MongoDB, but does like Meteor. Meteor uses MongoDB if you don't know.

julien_c• 13 years ago

Do you have reference to support the fact that HN would be biased against MongoDB?

don_draper2• 13 years ago

http://www.hnsearch.com/search#request/all&q=mongodb+bro...

nestlequ1k• 13 years ago

MongoDB is pretty popular here. There's just a vocal group of old school RDBMS lovers who like to hate on everything that isn't PostgreSQL.

papsosouid• 13 years ago

That doesn't seem very accurate. Plenty of "how do I shot database?" people are very anti-mongo too. Some of that may well be because they feel mongo gets more mindshare than their preferred nondb, but don't blame postgresql users for that.

JPKab3• 13 years ago

I agree that there's a whole lot of Mongo hate on here, but it falls into two categories:

1) Teams who started with Mongo (which makes sense when your schema is still in flux and you are still feeling out what you want it to finally be) then stuck with it when they should have moved to an RDBMS due to their use case, but never did and then find out that Mongo doesn't support features that any RDBMS from the 90's would.

2) Old school RDBMS people who are, as Steve Yegge would say "software conservatives." They love the way RDBMS's force people to really put thought into their data modeling upfront, and believe that anything that allows people more flexibility is opening the door to increasing amounts of chaos. Plus they hate the thought of returning to the dark ages when databases didn't all use SQL, and everyone had to learn a new query language for a new DB.

FYI: I've heard Meteor is planning on allowing use of other databases. I would particularly be keen on use of RethinkDB. I really like what those guys have been doing so far.

alinajaf2• 13 years ago

I'm not sensing a great deal of love for Meteor on this thread.

eCa• 13 years ago

> $ meteor add email

> This package is automatically configured to send emails (up to 300 per day) through Mailgun

I'm not sure I like having 'email' linked to a specific service. But maybe that's the Meteor way?

patrickleet2• 13 years ago

You can use other things, but if you want to use one instantly with zero configuration, there's this.

ferrantim• 13 years ago

That's correct. Here is a quote from the meteor blog announcing this feature: " But there's more than just an API. We've partnered with Rackspace's Mailgun team so that every app deployed with $ meteor deploy can send email right away, without any annoying configuration process. These automatic accounts are capped at 200 messages a day, but of course you're not tied to them. You can use any SMTP server (your own box, a paid Mailgun account, or anything else) just by setting the $MAIL_URL environment variables, whether you're using our deploy servers or running your own bundles."

kisielk2• 13 years ago

$ curl https://install.meteor.com | sh

I really wish people would stop giving instructions like this. Despite all the focus on web security and sandboxing, we continue to instruct people to run arbitrary code on their user account.

People should at least give any shell script they download from the internet a cursory look to see if it's doing what it should be doing instead of blindly executing the response from an HTTP request.

thisishugo• 13 years ago

At least it's https; I've seen sites on HN recently[1] that suggest you run code pulled over plain http, as if that wasn't an even more horrible security risk than just blindly running a script from the Internet.

[1] http://chocolatey.org/

TazeTSchnitzel• 13 years ago

  @powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('http://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin

Goodness, that looks awful.

bretthoerner• 13 years ago

I don't understand this argument, unless you include things like gem, pip, npm, etc.

`pip install foobar-py` runs a Python setup script, which can do anything bash can. Do you inspect all of those, and comment about their insecurities on HN?

ohazi• 13 years ago

Don't these generally do some sort of cursory signature check?

sergiosgc2• 13 years ago

This method makes you vulnerable to attacks that change the script being run. DNS spoofing, HTTP proxy hacking or hacking of the source server itself.

Good package management systems use digital signatures to ensure that the original package wasn't tampered with. Not that hacking of the central repositories never happened, but it's a major (and thus infrequent) event.

bpatrianakos2• 13 years ago

You're right but this is just kind of a nit-pick. It should be up to the user to decide if they trust the source. The way I see it, it all comes down to the question of do you trust the source. If the source is trustworthy from there you've got to worry about an attacker compromising your trusted source. That happens and it sucks but its life and I for one am not going to stop `gem install`ing and `curl`ing because Rubygems.org was compromised once or some other source was tampered with.

I know my sources, I trust them. If they're compromised and they take me down with them, I'm going to cry a little but it's not like I'm working on a nuclear reactor - I'm making some shit CRUD app. Now as the importance of a codebase increases the kind of attitude like I have should decrease of course.

JPKab3• 13 years ago

"it's not like I'm working on a nuclear reactor - I'm making some shit CRUD app."

Finally, some much needed humility on HN. Refreshing. And true.

alinajaf2• 13 years ago

> "I'm going to cry a little but it's not like I'm working on a nuclear reactor"

Great for you, but you're a developer who presumably works on 'shit CRUD apps' for other people who pay you for the effort.

What happens when a script from a compromised source that you run on your devbox grabs the entire contents of ~/.ssh/ and sends it to the bad guys inbox? Congratulations, all your clients have been thoroughly owned.

hoverkraft• 13 years ago

That being said, you'd be amazed at how many ruby gems are required to run the average nuclear reactor.

spullara2• 13 years ago

It would be great if shasum would let you check against a sha on the command line so you could do something like:

curl https://install.meteor.com | shasum -c 6fa3128600e9bd73a161a625f8503e6614b44b2b | sh

Could be built into curl possibly.

mayanksinghal• 13 years ago

But if the DNS is compromised or if this a MITM attack (in spite of being https) there is no guarantee that the checksum is any more trustworthy.

geoffschmidt2• 13 years ago

Meteor dev here.. We actually think this is more secure, or at least does more to raise awareness about security! We want people to BE AWARE that they're running arbitrary code, secured only by the certificate authorities in their local curl install.

Just about every other way of installing software ends up letting the remote run arbitrary code on your machine. The disadvantage of the other approaches is that you don't think about it, so you feel safer than you are, and you are more likely to make security-compromising mistakes.

- When you download an OS X installer package and run it, it can run arbitrary code during the install. Is that how you installed Postgres or Rails? Hope you downloaded that disk image over http. (The last time you downloaded a disk image, did you check the link to make sure it was https? ... Are you sure you never forget to do that?)

- OK, so let's say you download a tarball instead, and untar it into /usr/local, and put meteor in your path. Then the next thing you do is.. you type 'meteor', letting the tarball run arbitrary code. There's not much security difference between letting the remote code run at install time, and letting it run two seconds later when you actually start the program fo the first time.

- OK, let's say you downloaded a Meteor tarball, checked its SHA1-- wait, how did you get the correct SHA1? Did you get it off our website? (Best case, over https, bringing us back where we started?) Or did you call me on the phone.. using the phone number you got off of Facebook.. secured by https? (Best case, and only if you manually added https to your Facebook URL. Did you remember to do that?)

- No problem, I'll get it out of macports, fink, or homebrew, and hopefully they'll have the correct authoritative hash and validate the download. Well, how do you know you have the real macports? The chain of trust still goes through https and the CA. Arguably this is a little better because presumably many people will notice if the macports download site is hacked, but just as arguably, it's less secure because there's one more potential compromise point (volunteer macport maintainers -- how are they vetted? do they use two factor auth? what if their email account is compromised?)

There's really two separate issues here:

- Do you trust Meteor enough to run our code? If so, you shouldn't care whether you run curl | sh or whether you download a tarball and unpack it, and then run the program in it. If not, you shouldn't do either. They're equally bad.

- Do you trust https and the certificate authorities to protect you from MITM attacks, so that you get the authentic bits from meteor.com and not an imitation? If so, then curl https://foo solves your problem. If not, you are going to have to find something better than the CA's to serve as your root of trust.

Maybe there is an argument for "defense in depth" -- maybe you should fetch the tarball from one server with one CA, and the SHA1 from a second server with a different CA -- sure, in practice that could make a compromise less likely. But that's a bit much to ask of the random OS X user that just wants to come to meteor.com and install the tools.

Your best option is clearly to come to the monthly DevShop events at Meteor HQ in SF. If you come to DevShop to install Meteor, I will personally confirm the SHA1 for you :)

javajosh6• 13 years ago

Good response. This is not directly related, but wouldn't it be nice to have some sort of convention where install scripts declare the access that they need and people could allow it (or not)? Something like the Unix permissions systems, but more fine-grained. E.g. perhaps a chroot jail with symlinks to the places that you want to give the script access. Indeed, the first run of the script could be to generate the symlink commands you'd need to execute before it really executes. If you don't like the permissions it wants, you just exit the jail, kill the parent process, and move on with your life.

qiqing• 13 years ago

Monthly DevShop event link: http://www.meetup.com/Meteor-SFBay/events/103016662/

Meetup group link: http://www.meetup.com/Meteor-SFBay/

grinich• 13 years ago

But then how will he really know it's you, Geoff? ;)

In all seriousness, you should consider posting a response like this in your FAQ/Help and linking at the install tutorial. I'm really sick of this knee-jerk security reaction happening every time someone builds an installer like this.

_pius• 13 years ago

Best response I've seen yet to this particular brand of concern trolling.

bphogan• 13 years ago

This. If you give me a shell script, I can curl it without piping it to a shell first so I can see what it's going to do. Unlike an installer on Windows where I have no clue what's going on.

programminggeek• 13 years ago

I think the safest way would be for you to buy a new 13" Macbook Air, install Meteor, and deliver it to me in person. That way I know its legit.

kisielk2• 13 years ago

All good points, but there's a big difference in trusting my distro's package manager to install packages from their secure repos, verified by certificates I installed with their OS in the first place, and running a shell script from a blog post linked from a news site.

I've never heard of meteor before, and it's likely that many of the people who are reading the article haven't either.

Yes the site is HTTPS, but anyone can buy an SSL certificate for any purpose. It's not even a case of being MITM'd.

Basically we're telling people "read this blog post, run this curl command that runs some random shell script from this server you've never heard of before".

That's a very different from installing packages from your development community's package server, your OS's package repository, or an app store.

I know it's not possible to fully inspect all the code we run, but I'd rather we didn't encourage the habit of entirely disregarding it.

shubber• 13 years ago

Which is all interesting, except the shell script is a wrapper on "download this tarball and unpack it" or "download this rpm/deb and install it." So whatever security concerns existed on those approaches, you only concealed them. Why exactly?

timdorr2• 13 years ago

While I agree that there should be some more transparency with the install process, my problem with this is more practical: because I've installed via a non-standard means, how do I uninstall? How do other packages of software know I have meteor installed as a prerequisite? How do I easily ensure I have the latest version? How do I lock my install to a particular version to avoid breaking changes in new versions?

Whilst the security aspect is a background concern, these functional concerns are far more important to me. Because npm or some other system wasn't used, meteor is now an outlier and doesn't easily fit into most of my development flow. I've now been burdened with an external maintenance process that requires separate tools and workflow to accommodate.

Honestly, that's the biggest turn-off I have about meteor right now. Hopefully that will change before the big 1.0.

patio11• 13 years ago

This is a security red herring that as far as I can see is justified entirely by an aesthetic preference to think of oneself as "able to quickly audit code just by skimming it."

Compare it to alternatives like "gem install NAME_ANY_GEM_HERE", which also executes arbitrary code and which, for the typical Ruby/Rails developer, is totally impenetrable. (If you think otherwise, tell me, when's the last time you did a line-by-line audit of every single dependency prior to installing a gem?)

Even the embedded assumptions like e.g. the Rubygems server is, as of this instance, being operated by Rubygems and not being operated by The Adversary are really, really tenuous.

webreac• 13 years ago

I really like instructions like this because I understand easily what needs to be done. Probably the content of the script will also be easy to read. Of course, I will never do a copy paste of these instructions. I will redirect to a file and read it before executing. And if I have doubts, I launch a VM.

doomslice• 13 years ago

Just curious, how does Meteor deal with concurrency issues where multiple clients are making changes to the same objects? Does last update win? How does this get reflected back to the UI?

Brief example: A grocery list that both my wife and I are editing, deleting, adding, and re-arranging at the same time.

jggonz• 13 years ago

They go into detail on this in their screen casts and online documentation.

pearkes• 13 years ago

I feel like there's a certain point where thoughtfulness trumps speed while building something.

Why is there such a desire to do X in N minutes? How can something unique and truly useful come from 5 shell commands?

gcv• 13 years ago

When I want to make something unique and truly useful, I'd like to get to it. I want to waste as little time as possible on boilerplate and infrastructure.

scottmagdalein3• 13 years ago

Because accepting an email for a newsletter is not unique and should be able to be built in as little time as possible.

readme• 13 years ago

Amazon SES is similarly easy, and it works with any language over SMTP

scribu• 13 years ago

  if(Meteor.isClient) {
    ...
  }


  if(Meteor.isServer) {
    ...
  }

Does the Meteor compiler somehow split those code blocks into separate files, so that it only serves the client code to the browser?

If not, it seems like a pretty bad practice for delivering fast webapps.

Edit: In general, Meteor.isServer seems like a great way for developers to shoot themselves in the foot:

  Dev: Let me just add my $secret in the server-side block...
  Bad guy (viewing source): Oh, what have we here?
  Dev: PWNED :(

javajosh6• 13 years ago

Not sure why you got downvoted; it's a good question. It's not as trivially easy to check as your downvoter might think, as deployed Meteor bundles are minified.

Anyway, the answer is that the entire script is sent to the file and the server. In practice, this isn't a performance issue so much as a security issue - there may be parts of your server code that you don't want clients knowing about.

You can prevent server-side code from getting shipped to the client by placing it in the server subdir.

wavesounds2• 13 years ago

"Does the Meteor compiler somehow split those code blocks into separate files, so that it only serves the client code to the browser?"

Yes.

javajosh6• 13 years ago

Uh, actually, no. And I put together a screencast to prove it.

http://screencast.com/t/RkImuQ9i

orionblastar4• 13 years ago

I tried it, sent email to myself. Never received it. I typed everything correct except I replaced the email with my own email orionblastar@gmail.com there was no error messages as well.

Do I have to install things like sendmail to make it work? If so that needs to be in the documentation.

Yes I did the meteor add email part, I followed every step.

sergeyo• 13 years ago

Hello,

It looks like you haven't actually deployed the code. Once deployed a free Mailgun account is created for you behind the scenes and assigned to your app. To test locally you need to create a Mailgun account and follow instructions from the "Extra optional step" section.

BR, Sergey

orionblastar4• 13 years ago

That is because I don't have a web site to deploy to yet. I wanted to test it on my Ubuntu box on Apache first before deploying. Why do I have to create an account on some other web site just so I can send email on my local Ubuntu machine?

bjourne• 13 years ago

Great tutorial! If only there was an easy way to store the entered addresses in a database? Maybe that could be done in the next 5 minutes? :) I've had a few projects which where basically nothing more than just what was in the article. Meteor's builtin deploy and free Mailgun will fit perfect for cases like that.

acemtp4• 13 years ago

On the server, add something like:

RegUsers = new Meteor.Collection("regUsers");

RegUsers.insert({email:email});

MrBra2• 13 years ago

Aren't we all scared that some time in the future from now, new kids will have new tools that will make programming a totally customizable and super-performing web application as trivial as for example dragging some component here and there, like for us has been working with new generation programming environments, compared to i.e. coding asm? This is a part of the hidden feeling I guess..

Also that then, our present efforts and knowledge will be culturally relevant but totally unnecessary for developing great new generation apps ?

But...... we have what we have now, and we still code because we like it NOW, so we should accept the passing of time (and all evolutions it will bring) and think that we are still doing what we enjoy doing and that we have the luck of making a life out of it, possibly :)

Only moment to be concerned about the future is when they'll invent a time machine..

derringer• 13 years ago

You're likely being down voted because since the invention of programming the field has been continuously becoming "easier" often by leaps and bounds. However, programmers always remain at the edge of the boundary so there is continuously more work for programmers, not less. Every component of what made things "easy" can be improved by making it more flexible, performant etc. and doing this most believe will always require a skilled programmer.

But to play devils advocate, if we were to create true artificial intelligence (I guess it would just be intelligence at that point) then not only would programmers be obsolete, but all of humanity would be obsolete. We'd all just be WALL-E style mouths to feed. This seems difficult to imagine, but we already see it happening in some ways. Unemployment is high almost everywhere and there's no fundamental economic law that every human on the planet can contribute sufficiently to match said human's consumption.

Essentially what this means is we have two pretty rough options. First, all of these people fall under the welfare state. The homeless and hungry all get what they need through governments, NGOs and charities. The other is the Darwinian approach, nature's great equalizer. Both of these options suck pretty hard, but that may be the world we're looking at until our robot overlords turn us into batteries (although it's more likely we'd become pets if anything at all).

lquist• 13 years ago

The great thing about Rails (and Django) was that it was born in the wild. It was built in the process of solving a real world problem, and generalized/abstracted from there. Meteor lacks that type of genesis, and I wonder if that's important.

Create a web app from scratch in under 5 minutes with Meteor and Mailgun

Related Stories