9 ms·

Why Meteor

81 points by sgdesign 12y ago

imslavko 12y ago
Note that this is posted on the community wiki site hosted by one of the community members. The application running wiki is open-source: https://github.com/meteorpedia/wiki https://github.com/meteorpedia/wiki
- btipling 12y ago
  Yep, I wrote most of it way back in the day and then someone else took up the reigns, I don't think it's been updated in a long time. It's definitely not 0.9.4 compatible at this point. I'm working on an alternative template engine for Meteor now based on django. Currently in a big branch that's moving slow since I'm pretty busy at my regular job. https://github.com/btipling/djanglets https://github.com/btipling/djanglets
  - Tarang 12y ago
    I tried to update it/send a PR but there are a lot of packages in there that are missing so its very difficult to do.
    - deleted 12y ago
      [deleted]
TheAceOfHearts 12y ago
Every time I see a framework like this I ask myself: if I outgrew this, how difficult would it be to migrate away from it? I'd love to hear if anyone has used meteor for something read and if they've had to deal with migrating to something else: how they've done it, and what issues they encountered. For example, I love angular, but migrating away from angular after using it for one year would doubtless be a very painful process.
- vqc 12y ago
  What would be the opposite of angular, i.e. easy to migrate away from? Backbone? (Because it is less opinionated than Angular?)
- joshkpeterson 12y ago
  This seems like a low priority consideration. Personally I would try to choose a framework that will last you longer than a year!
- swartkrans 12y ago
  Meteor is a totally different way to write web applications. Between the merging of the concept of front-end and back, the distributed data protocol it uses, the live templates, there's nothing really else out there like it and no, migrating away from it will not be easy, but if you're a transient nomad with frameworks I'm not sure you should really use any framework.
- KaoruAoiShiho 12y ago
  I moved from meteor to an angular+pusher solution. I rewrote the entire thing in about 3 weeks. Almost nothing was reusable. The app is http://anonquest.com/ http://anonquest.com/ It's a realtime story writing community. Be happy to answer questions.
  - general_failure 12y ago
    Angular 2 changes everything
- kyllo 12y ago
  That's because it's a higher-level abstraction than other web frameworks. Ripping out a layer and dropping down to a lower level of abstraction is always going to be a lot of work.
- goblin89 12y ago
  > For example, I love angular, but migrating away from angular after using it for one year would doubtless be a very painful process. I wish AngularJS’s dependency injection/forced modularity and HTML augmentation/templating were somehow independent and not requiring each other. > if I outgrew this, how difficult would it be to migrate away from it? I'm becoming successful at fighting my urge to migrate my projects away from things I outgrow. I reason that changed preferences alone should not constitute a reason to rewrite an existing and working solution. And in case costs of adapting existing solution are higher than costs of rewriting it from scratch, then this is probably due to some unfortunate design decisions or obscure libraries/frameworks used, so these are the things to avoid.
drewblaisdell 12y ago
From the Tinder clone blog post linked in the first paragraph: The days of natively developing apps in Java and Objective-C have an apparent end in sight. I love Node.js and Javascript. I wish this was true, but I can't bring myself to believe it yet.
- BuckRogers 12y ago
  It's not. And, native apps are likely going to make even more ground. I realize this runs against popular opinion, that webapps are some sort of inevitable future to replace native apps almost in their entirety, but we will see.
  - sgdesign 12y ago
    They can replace some native apps. With Meteor, you can now use the same basic building blocks to build your web app, iOS app, and Android app. Maybe you won't reach the same quality on iOS and Android as you would with native apps, but for smaller teams this can be a huge time saver, especially in the early stages of a project. So in a lot of cases it's not so much "web app" vs "native app", as "web app" vs "no app".
  - notastartup 12y ago
    You make a very good contrarian view and I agree. I'm just realizing that we may not be innovating as we think we'd like. Basically, we found a way to force the browser to act like native desktop apps but without the security and power of native apps. In the process, generating a great amount of technical barrier and debt. Businesses will still use a java swing desktop app if they paid millions for it in the 90s. We'll still work on desktop IDE's to code our stuff. Another discussion here would be how "mobile" is going to replace desktop apps. This is simply not true. Lot of important work goes on with a mouse and keyboard behind a monitor. I just don't buy reinventing the wheel. Sure it works for activities centered around the mobile phone mainly communication applications and social apps but i don't see how it can cause disruption. I have a feeling one of these days, we'll see a major correction in how we perceive our point in time as being the best possible state and we'll see more or less the return of old ideas, the true and tested technologies get more attention they truly deserve.
woah 12y ago
I tried some stuff with Meteor a while back. I was very excited about the concept and really felt on board with the 'new way to write apps' stuff. It is pretty cool, but I was trying to implement a site where people could post stories and have an author badge appear on the page. This requires joins. Mongo doesn't have joins, and Meteor doesn't even have fake joins, like Mongoose's 'populate'. There has been a lot written in the Meteor community about faking joins, as it is a persistent problem. First, I tried template helpers, but these are impossible to put into a nested template. I looked at 5 different open source packages for serverside fake joins, but ended up doing a clientside solution (to get a feel for the 'basic' way to do things). This solution involved several functions on the clientside router, that would be called several times, with different data available each time. It is a convoluted thing to do, no matter the method. Another thing I tried to do was purely clientside databinding, to populate the author badge in real time as the user fills a form. It's trivial to bind data to the database and have that update in realtime, but I wanted to hold off saving anything until the user hit the save button. Again, a simple task got weird. I ended up using an un-synced database collection, then saving to an identical, but synced collection. I'm not writing off Meteor completely, but I ended up moving away from it. Node.js and a solid frontend framework have slightly more boilerplate, but are generally very flexible for whatever it is you want to do. In retrospect, one of the best things about Meteor is the one-line auth setup. This is usually a big pain, and it was nice to have it be so easy.
- swartkrans 12y ago
  > It is pretty cool, but I was trying to implement a site where people could post stories and have an author badge appear on the page. Meteorpedia, the site in the OP accomplishes this without joins. It has authors for pages. You just have to set up your schema in a way that's different from normalized SQL.
- notastartup 12y ago
  Along with my team, we built an enterprise app with meteor.js. Huge waste of resources. I almost find that the single biggest barrier to fully investing in is Mongodb. The queries are hideous. But Meteor is heavily invested in Mongodb and I'm afraid this is what will kill it.
andremendes 12y ago
*By using browser storage instead of hijackable session cookies, CSRF attacks are impossible.* Cool, but it makes way harder to scale up without websockets support for load balancing, since it uses SockJS, which requires sticky sessions.
- swartkrans 12y ago
  It's totally possible to load balance websockets. You turn the web sockets into a dumb proxy that talks to your service. You could have a bunch of SockJS servers, with people connecting to different ones communicate with each other over the actual service. If you were building chat rooms you could assign rooms to specific servers, or you could tailor your service such that it works across a distributed system.
  - STRML 12y ago
    We do something similar on BitMEX with SockJS. As long as you're not using AWS's ELB, load-balancing websockets is as easy as anything else. We use HAProxy to proxy the websocket connections as TCP, and round-robin the connections. If a server drops out, the websocket connection is disconnected and a reconnection occurs to an available server.
  - jkarneges 12y ago
    I think he means that if you're using a browser that doesn't support WebSockets, then SockJS's HTTP-based fallbacks will require sticky routing. If the browser does support WebSockets, then this is not a concern.
    - swartkrans 12y ago
      I give 0 fucks about browsers that don't support web sockets.
  - andremendes 12y ago
    It's possible but what I meant (and failed to make clear) is that we can't actually avoid using cookies and scale up, since websockets connections aren't widely allowed on devices, calling for SockJS use and therefore, cookies adoption.
leke 12y ago
The appealing parts of Meteor is a built in security against common web insecurities. The unappealing part of Meteor is having to learn Mongo. Ok, this part is just me being too comfortable with SQL relational table databases, and being too lazy to take the time to learn the alternatives.
- weego 12y ago
  The most unappealing part about any framework that claims to get you 90% there is that the 10% left is always loads of painful bullshit trying to wedge what you need into a, usually overly opinionated, overly rigid "the framework way" pattern. Don't get me wrong, these things are fantastic for MVP/prototyping but nothing that claims to be one size fits all comes without hidden debt.
  - notastartup 12y ago
    I agree with you 100%. This is why I began just vouching for micro-frameworks. Even that comes with hidden debt in the form of plugins or modules written by it's communities but it's a step above the 'write a shopping cart website in 5 minutes' type of framework. I'm very happy with Flask because it complete gets out of the way, it's up to you to deal with pesistence, models. You choose your own sins type of approach.
- BugBrother 12y ago
  I quite like MongoDB, it is worth learning. The main Mongo problem imho, is when you have feature creep -- if you find out later that you must have joins. Relational databases are more flexible with changing requirements.
vuldin 12y ago
What if I just wanted to use Meteor for the same reason as what I currently use something like Firebase for? I'd like to combine this tool with React/Flux for the single purpose of server-side database functionality... not the entire kitchen sink. The closest thing I've found to showing how this could be done is Pete Hunt's react-meteor-preso project: https://github.com/petehunt/react-meteor-preso https://github.com/petehunt/react-meteor-preso. This doesn't include Flex functionality, but it looks like a good start. It'd be awesome to have some more examples of this.
- pscanf 12y ago
  Take a look at https://github.com/mondora/asteroid https://github.com/mondora/asteroid (I'm the main developer behind it). It exactly lets you use meteor as a self-hosted firebase.
  - vuldin 12y ago
    This is exactly what I was looking for, now to see if it is as good as it sounds. Thanks! I'll be watching and trying it out.
davedx 12y ago
This "production ready" "specially for beginners" marketing about Meteor really needs to stop. They completely changed the API from under my feet, that is NOT production ready (nor for beginners, I would argue). Stay away from Meteor until they hit 1.0, unless you're ready for pain.
- codesuela 12y ago
  version 1.0 is just around the corner though (there is an RC)
- primigenus 12y ago
  Could you elaborate on specifically which changes you weren't happy with? Just curious to hear what made things harder for you.
lingoberry 12y ago
I'm using Meteor and React for a side project, and compared to a previous project where I used Backbone and node.js it really is a 10x productivity boost. Since this is a side project I can spend at most an hour a day on, it really is the difference between being able to finish or not.
shubhamjain 12y ago
I just don't get this meteor.js fad. Its not even a production ready framework and yet I am seeing webapps being designed using it, meetups being held about it and blogs being written about it as if it is a breakthrough in programming web. I feel people should cool down and think it through if its architecture is even worth having or not.
- notastartup 12y ago
  same with node.js I fail to understand why someone would want to deal with javascript callback chains on the server side to build simple websites. Even some clients are convinced that somehow their application will run faster. Even front-end frameworks like Backbone.js doesn't make sense to me. I still find using jQuery more than adequate.
  - vertex-four 12y ago
    node.js is useful for some specific things - specifically, doing real-time "plumbing" between data sources and sinks. There's a huge amount of libraries and support for doing that, that doesn't really exist in other communities.
  - general_failure 12y ago
    So what do you use to build simple websites on the backend? There are bad programmers and bad programming practices for every language. If you see code that has 5 levels of nested callback chains, it's only because people don't know how to write code. Have you see chromium code? It's filled with callback in c++. All this is nothing new.
    - notastartup 12y ago
      Interesting, so what do you use to avoid nested callback chains? Use a workaround library? This just seems like brute force. I don't think you are required to use asynchronous callbacks in C++ to do anything, while in Node.js you are almost guaranteed to doing this. Why would you write a CRUD app using Node.js when you can accomplish this in multitude of other well established methods? LAMP, Java, Python etc. Nothing wrong with experimenting but for real world needs, there's no clear answer as to why you would need Node.js to redo what you used to do.
chestnut-tree 12y ago
The linked site won't display anything with Javascript disabled. Yet, when Javascript is enabled, we don't get a "web app", all we get is a page of text that could easily be coded in HTML and CSS. Presumably, building this site in meteor makes things easier for the developer. Does it make things easy for all users of the site? Look at the source code of the page after it's loaded. ... <body> </body> </html> What would a screen reader user hear? Is this site accessible? Does anyone really care? Do sites like this point to a future where more and more web sites (not web apps) are built with Javascript frameworks? Is this a good thing? And can these sites acommodate all users? (Assuming they want to.)
- krapp 12y ago
  On the one hand, it might be kind of disingenuous for a site about the Meteor framework to not actually be running on that framework - but on the other, I think you're right. While most users in general (not necessarily most users considering Meteor) will have javascript on by default without ad-blockers running (and it won't be an issue) there doesn't appear to be any particular client benefit to rendering a simple site like this from js. >Do sites like this point to a future where more and more web sites (not web apps) are built with Javascript frameworks? The pendulum does seem to be swinging in that direction. But i've seen enough posts on HN about how client-side templating has gone too far and wrecked user experience, and about developers 'rediscovering' how robust simple html/css can be, to suspect that nothing is inevitable. Trends come and go and paradigms fall in and out of fashion.
- toxicFork 12y ago
  I try to approach things differently: why do people disable javascript? Is it because of security? There are ways to disable javascript only from third parties, for example, or disable certain functions (e.g. prevent alerts (natively in Chrome, or browsers extensions). Screen readers should be able to get the current state of the page, and not read from the 'source'. I can see some advantages of using javascript e.g. less load for the server to render things, it just becomes a directory host.
  - skratlo 12y ago
chaostheory 12y ago
I really really want to use this one day, but it really depends on the answer to this perennial question: When is RDBMS support actually coming?
adam74 12y ago
One thing that scares me about meteor is performance and scalability. I'm afraid that if I build an app that takes off, I won't be able to afford the servers to keep the app running.
deleted 12y ago
[deleted]
greggdourg 12y ago
We've been using our Meteor-based, multi-tenant CRM/talent-management app in production for several months now. It's called Exartu and is open source hosted on github. We originally wrote the app using sql and signalR and as we've done with many of company's (Tempworks Software) products, but we switched in no small part for the real-time reactivity offered natively in Meteor and the productivity gains from its packaging system. At one point we used Knockout for all our binding but switched when Meteor's Blaze matured. The speed and simplicity of the templating engine coupled with the fact that js is used both client and server side reduces the learning curve as we add devs to the project. Contrary to many comments here, I've really enjoyed using mongodb and find it fast and eminently suitable for a problem domain like CRM that is constantly in transition. Our biggest problem with Meteor was that as a new platform there were no enterprise level apps to model after. We made the app open source (github->Exartu) in hopes to change that, and we welcome critiques to it.

81 points by sgdesign 12y ago

Note that this is posted on the community wiki site hosted by one of the community members. The application running wiki is open-source: https://github.com/meteorpedia/wiki https://github.com/meteorpedia/wiki

btipling 12y ago
Yep, I wrote most of it way back in the day and then someone else took up the reigns, I don't think it's been updated in a long time. It's definitely not 0.9.4 compatible at this point. I'm working on an alternative template engine for Meteor now based on django. Currently in a big branch that's moving slow since I'm pretty busy at my regular job. https://github.com/btipling/djanglets https://github.com/btipling/djanglets
- Tarang 12y ago
  I tried to update it/send a PR but there are a lot of packages in there that are missing so its very difficult to do.
  - deleted 12y ago
    [deleted]

TheAceOfHearts 12y ago

Every time I see a framework like this I ask myself: if I outgrew this, how difficult would it be to migrate away from it? I'd love to hear if anyone has used meteor for something read and if they've had to deal with migrating to something else: how they've done it, and what issues they encountered. For example, I love angular, but migrating away from angular after using it for one year would doubtless be a very painful process.

vqc 12y ago
What would be the opposite of angular, i.e. easy to migrate away from? Backbone? (Because it is less opinionated than Angular?)
joshkpeterson 12y ago
This seems like a low priority consideration. Personally I would try to choose a framework that will last you longer than a year!
swartkrans 12y ago
Meteor is a totally different way to write web applications. Between the merging of the concept of front-end and back, the distributed data protocol it uses, the live templates, there's nothing really else out there like it and no, migrating away from it will not be easy, but if you're a transient nomad with frameworks I'm not sure you should really use any framework.
KaoruAoiShiho 12y ago
I moved from meteor to an angular+pusher solution. I rewrote the entire thing in about 3 weeks. Almost nothing was reusable. The app is http://anonquest.com/ http://anonquest.com/ It's a realtime story writing community. Be happy to answer questions.
- general_failure 12y ago
  Angular 2 changes everything
kyllo 12y ago
That's because it's a higher-level abstraction than other web frameworks. Ripping out a layer and dropping down to a lower level of abstraction is always going to be a lot of work.
goblin89 12y ago
> For example, I love angular, but migrating away from angular after using it for one year would doubtless be a very painful process. I wish AngularJS’s dependency injection/forced modularity and HTML augmentation/templating were somehow independent and not requiring each other. > if I outgrew this, how difficult would it be to migrate away from it? I'm becoming successful at fighting my urge to migrate my projects away from things I outgrow. I reason that changed preferences alone should not constitute a reason to rewrite an existing and working solution. And in case costs of adapting existing solution are higher than costs of rewriting it from scratch, then this is probably due to some unfortunate design decisions or obscure libraries/frameworks used, so these are the things to avoid.

drewblaisdell 12y ago

From the Tinder clone blog post linked in the first paragraph: The days of natively developing apps in Java and Objective-C have an apparent end in sight. I love Node.js and Javascript. I wish this was true, but I can't bring myself to believe it yet.

BuckRogers 12y ago
It's not. And, native apps are likely going to make even more ground. I realize this runs against popular opinion, that webapps are some sort of inevitable future to replace native apps almost in their entirety, but we will see.
- sgdesign 12y ago
  They can replace some native apps. With Meteor, you can now use the same basic building blocks to build your web app, iOS app, and Android app. Maybe you won't reach the same quality on iOS and Android as you would with native apps, but for smaller teams this can be a huge time saver, especially in the early stages of a project. So in a lot of cases it's not so much "web app" vs "native app", as "web app" vs "no app".
- notastartup 12y ago
  You make a very good contrarian view and I agree. I'm just realizing that we may not be innovating as we think we'd like. Basically, we found a way to force the browser to act like native desktop apps but without the security and power of native apps. In the process, generating a great amount of technical barrier and debt. Businesses will still use a java swing desktop app if they paid millions for it in the 90s. We'll still work on desktop IDE's to code our stuff. Another discussion here would be how "mobile" is going to replace desktop apps. This is simply not true. Lot of important work goes on with a mouse and keyboard behind a monitor. I just don't buy reinventing the wheel. Sure it works for activities centered around the mobile phone mainly communication applications and social apps but i don't see how it can cause disruption. I have a feeling one of these days, we'll see a major correction in how we perceive our point in time as being the best possible state and we'll see more or less the return of old ideas, the true and tested technologies get more attention they truly deserve.

woah 12y ago

I tried some stuff with Meteor a while back. I was very excited about the concept and really felt on board with the 'new way to write apps' stuff. It is pretty cool, but I was trying to implement a site where people could post stories and have an author badge appear on the page. This requires joins. Mongo doesn't have joins, and Meteor doesn't even have fake joins, like Mongoose's 'populate'. There has been a lot written in the Meteor community about faking joins, as it is a persistent problem. First, I tried template helpers, but these are impossible to put into a nested template. I looked at 5 different open source packages for serverside fake joins, but ended up doing a clientside solution (to get a feel for the 'basic' way to do things). This solution involved several functions on the clientside router, that would be called several times, with different data available each time. It is a convoluted thing to do, no matter the method. Another thing I tried to do was purely clientside databinding, to populate the author badge in real time as the user fills a form. It's trivial to bind data to the database and have that update in realtime, but I wanted to hold off saving anything until the user hit the save button. Again, a simple task got weird. I ended up using an un-synced database collection, then saving to an identical, but synced collection. I'm not writing off Meteor completely, but I ended up moving away from it. Node.js and a solid frontend framework have slightly more boilerplate, but are generally very flexible for whatever it is you want to do. In retrospect, one of the best things about Meteor is the one-line auth setup. This is usually a big pain, and it was nice to have it be so easy.

swartkrans 12y ago
> It is pretty cool, but I was trying to implement a site where people could post stories and have an author badge appear on the page. Meteorpedia, the site in the OP accomplishes this without joins. It has authors for pages. You just have to set up your schema in a way that's different from normalized SQL.
notastartup 12y ago
Along with my team, we built an enterprise app with meteor.js. Huge waste of resources. I almost find that the single biggest barrier to fully investing in is Mongodb. The queries are hideous. But Meteor is heavily invested in Mongodb and I'm afraid this is what will kill it.

andremendes 12y ago

*By using browser storage instead of hijackable session cookies, CSRF attacks are impossible.* Cool, but it makes way harder to scale up without websockets support for load balancing, since it uses SockJS, which requires sticky sessions.

swartkrans 12y ago
It's totally possible to load balance websockets. You turn the web sockets into a dumb proxy that talks to your service. You could have a bunch of SockJS servers, with people connecting to different ones communicate with each other over the actual service. If you were building chat rooms you could assign rooms to specific servers, or you could tailor your service such that it works across a distributed system.
- STRML 12y ago
  We do something similar on BitMEX with SockJS. As long as you're not using AWS's ELB, load-balancing websockets is as easy as anything else. We use HAProxy to proxy the websocket connections as TCP, and round-robin the connections. If a server drops out, the websocket connection is disconnected and a reconnection occurs to an available server.
- jkarneges 12y ago
  I think he means that if you're using a browser that doesn't support WebSockets, then SockJS's HTTP-based fallbacks will require sticky routing. If the browser does support WebSockets, then this is not a concern.
  - swartkrans 12y ago
    I give 0 fucks about browsers that don't support web sockets.
- andremendes 12y ago
  It's possible but what I meant (and failed to make clear) is that we can't actually avoid using cookies and scale up, since websockets connections aren't widely allowed on devices, calling for SockJS use and therefore, cookies adoption.

leke 12y ago

The appealing parts of Meteor is a built in security against common web insecurities. The unappealing part of Meteor is having to learn Mongo. Ok, this part is just me being too comfortable with SQL relational table databases, and being too lazy to take the time to learn the alternatives.

weego 12y ago
The most unappealing part about any framework that claims to get you 90% there is that the 10% left is always loads of painful bullshit trying to wedge what you need into a, usually overly opinionated, overly rigid "the framework way" pattern. Don't get me wrong, these things are fantastic for MVP/prototyping but nothing that claims to be one size fits all comes without hidden debt.
- notastartup 12y ago
  I agree with you 100%. This is why I began just vouching for micro-frameworks. Even that comes with hidden debt in the form of plugins or modules written by it's communities but it's a step above the 'write a shopping cart website in 5 minutes' type of framework. I'm very happy with Flask because it complete gets out of the way, it's up to you to deal with pesistence, models. You choose your own sins type of approach.
BugBrother 12y ago
I quite like MongoDB, it is worth learning. The main Mongo problem imho, is when you have feature creep -- if you find out later that you must have joins. Relational databases are more flexible with changing requirements.

vuldin 12y ago

What if I just wanted to use Meteor for the same reason as what I currently use something like Firebase for? I'd like to combine this tool with React/Flux for the single purpose of server-side database functionality... not the entire kitchen sink. The closest thing I've found to showing how this could be done is Pete Hunt's react-meteor-preso project: https://github.com/petehunt/react-meteor-preso https://github.com/petehunt/react-meteor-preso. This doesn't include Flex functionality, but it looks like a good start. It'd be awesome to have some more examples of this.

pscanf 12y ago
Take a look at https://github.com/mondora/asteroid https://github.com/mondora/asteroid (I'm the main developer behind it). It exactly lets you use meteor as a self-hosted firebase.
- vuldin 12y ago
  This is exactly what I was looking for, now to see if it is as good as it sounds. Thanks! I'll be watching and trying it out.

davedx 12y ago

This "production ready" "specially for beginners" marketing about Meteor really needs to stop. They completely changed the API from under my feet, that is NOT production ready (nor for beginners, I would argue). Stay away from Meteor until they hit 1.0, unless you're ready for pain.

codesuela 12y ago
version 1.0 is just around the corner though (there is an RC)
primigenus 12y ago
Could you elaborate on specifically which changes you weren't happy with? Just curious to hear what made things harder for you.

lingoberry 12y ago

I'm using Meteor and React for a side project, and compared to a previous project where I used Backbone and node.js it really is a 10x productivity boost. Since this is a side project I can spend at most an hour a day on, it really is the difference between being able to finish or not.

shubhamjain 12y ago

I just don't get this meteor.js fad. Its not even a production ready framework and yet I am seeing webapps being designed using it, meetups being held about it and blogs being written about it as if it is a breakthrough in programming web. I feel people should cool down and think it through if its architecture is even worth having or not.

notastartup 12y ago
same with node.js I fail to understand why someone would want to deal with javascript callback chains on the server side to build simple websites. Even some clients are convinced that somehow their application will run faster. Even front-end frameworks like Backbone.js doesn't make sense to me. I still find using jQuery more than adequate.
- vertex-four 12y ago
  node.js is useful for some specific things - specifically, doing real-time "plumbing" between data sources and sinks. There's a huge amount of libraries and support for doing that, that doesn't really exist in other communities.
- general_failure 12y ago
  So what do you use to build simple websites on the backend? There are bad programmers and bad programming practices for every language. If you see code that has 5 levels of nested callback chains, it's only because people don't know how to write code. Have you see chromium code? It's filled with callback in c++. All this is nothing new.
  - notastartup 12y ago
    Interesting, so what do you use to avoid nested callback chains? Use a workaround library? This just seems like brute force. I don't think you are required to use asynchronous callbacks in C++ to do anything, while in Node.js you are almost guaranteed to doing this. Why would you write a CRUD app using Node.js when you can accomplish this in multitude of other well established methods? LAMP, Java, Python etc. Nothing wrong with experimenting but for real world needs, there's no clear answer as to why you would need Node.js to redo what you used to do.

chestnut-tree 12y ago

The linked site won't display anything with Javascript disabled. Yet, when Javascript is enabled, we don't get a "web app", all we get is a page of text that could easily be coded in HTML and CSS. Presumably, building this site in meteor makes things easier for the developer. Does it make things easy for all users of the site? Look at the source code of the page after it's loaded. ... <body> </body> </html> What would a screen reader user hear? Is this site accessible? Does anyone really care? Do sites like this point to a future where more and more web sites (not web apps) are built with Javascript frameworks? Is this a good thing? And can these sites acommodate all users? (Assuming they want to.)

krapp 12y ago
On the one hand, it might be kind of disingenuous for a site about the Meteor framework to not actually be running on that framework - but on the other, I think you're right. While most users in general (not necessarily most users considering Meteor) will have javascript on by default without ad-blockers running (and it won't be an issue) there doesn't appear to be any particular client benefit to rendering a simple site like this from js. >Do sites like this point to a future where more and more web sites (not web apps) are built with Javascript frameworks? The pendulum does seem to be swinging in that direction. But i've seen enough posts on HN about how client-side templating has gone too far and wrecked user experience, and about developers 'rediscovering' how robust simple html/css can be, to suspect that nothing is inevitable. Trends come and go and paradigms fall in and out of fashion.
toxicFork 12y ago
I try to approach things differently: why do people disable javascript? Is it because of security? There are ways to disable javascript only from third parties, for example, or disable certain functions (e.g. prevent alerts (natively in Chrome, or browsers extensions). Screen readers should be able to get the current state of the page, and not read from the 'source'. I can see some advantages of using javascript e.g. less load for the server to render things, it just becomes a directory host.
- skratlo 12y ago

chaostheory 12y ago

I really really want to use this one day, but it really depends on the answer to this perennial question: When is RDBMS support actually coming?

adam74 12y ago

One thing that scares me about meteor is performance and scalability. I'm afraid that if I build an app that takes off, I won't be able to afford the servers to keep the app running.

deleted 12y ago

[deleted]

greggdourg 12y ago

We've been using our Meteor-based, multi-tenant CRM/talent-management app in production for several months now. It's called Exartu and is open source hosted on github. We originally wrote the app using sql and signalR and as we've done with many of company's (Tempworks Software) products, but we switched in no small part for the real-time reactivity offered natively in Meteor and the productivity gains from its packaging system. At one point we used Knockout for all our binding but switched when Meteor's Blaze matured. The speed and simplicity of the templating engine coupled with the fact that js is used both client and server side reduces the learning curve as we add devs to the project. Contrary to many comments here, I've really enjoyed using mongodb and find it fast and eminently suitable for a problem domain like CRM that is constantly in transition. Our biggest problem with Meteor was that as a new platform there were no enterprise level apps to model after. We made the app open source (github->Exartu) in hopes to change that, and we welcome critiques to it.