If you mean for new project starts, it might severely diminish it, but I don't think it will flat out end its popularity any more than Rails killed Java.
Also, it depends on what type of project you are talking about. For something at large scale, my guess is meteor won't be any more successful than Rails has been at huge scale (like Twitter).
I do agree that using one language end to end might be an awesome developer experience, but I wish that language wasn't JavaScript. I won't go into great detail as to why, but I would not want to build a large JavaScript app. That sounds incredibly painful and unpleasant to me.
Ruby and Java don't really compete in the same space, it would probably be better to compare Ruby and PHP as those two are the primary competitor with each other. If you wanted to point to a competitor to Java, .Net would probably be the closest match.
I agree, but when Rails came out, there was a whole lot of Ruby on Rails is going to kill Java type posts. I guess this means Meteor is reaching some mindshare.
Yeah, and we saw how well that worked. Java projects sprung up to incorporate the good ideas from Rails, Rails itself picked up a load of developers and evolved into something decent, and the world moved on. Nothing was killed, but all the boats rose.
I'm thinking maybe the drama wasn't a requirement for this to happen. Perhaps Meteor devs could experiment with that idea.
Your feelings towards JavaScript essentially mirror mine, though I've found writing code in TypeScript for Meteor has been a much more pleasant experience and gives me more confidence in the code I write.
Does typescript do type checking at runtime or just compile time? I was really excited about typescript initially, especially for use with Obvious Architecture, but then it looked like it was just compile time, not runtime checking which seems problematic to me.
TypeScript only does enough run-time argument checking to support default argument values.
Full run-time type checking would have overhead. It would also be unnecessary in places where data flows from Typescript function to Typescript function — those places should already be foolproof after the compile-time checks.
Definitely not today when the tools, the best practices, the state of the libraries are still below average and the developers have varying skill sets.
I'm sure 10 years down the line someone will be raving about how the latest NinjaScript based framework is going to be the death of Foo#, and anyone who doesn't think so should go back to their crusty old enterprise Ruby legacy code.
I can go into large detail why calling it incredibly painful and unpleasant is nothing but hyperbole though. Have you tried building a to-do MVC app, at least?
GP is expressing a personal language preference. I also find JS horrific to work with (and I've worked with it a lot). But that doesn't mean you can't or shouldn't enjoy it.
Horrific is really stretching it too though. I know it's Halloween or whatever but let's just discuss it on technical merits before passing misinformation like that.
I would not want to build a large Ruby app. That sounds incredibly painful. What's with all these "=>"??? And I still haven't wrapped my head around how you get the star onto the monkey, and why one would even want to do such a thing.
Ruby is the worst language ever, because I do not know how to use it.
If you mean for new project starts, it might severely diminish it, but I don't think it will flat out end its popularity any more than Rails killed Java.
Also, it depends on what type of project you are talking about. For something at large scale, my guess is meteor won't be any more successful than Rails has been at huge scale (like Twitter).
I do agree that using one language end to end might be an awesome developer experience, but I wish that language wasn't JavaScript. I won't go into great detail as to why, but I would not want to build a large JavaScript app. That sounds incredibly painful and unpleasant to me.