51–60 of 336 posts
I watch some videos on Meteor website a while ago and I was really impressed. Stuff that's pain in the ass in Rails, you can do it quite easily on Meteor. One aspect that prohibits me from making the jump though is Ruby's third party gem ecosystem. Ruby has so many tried and proven gems for everything you can think of. Is there a website like rubygems.org in Meteor world?
It depends on your definition of kill. 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…
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. Who knows 5-10 years down the line...
How exactly did the author come to this Meteor and Rails dichotomy? What do they have alike besides being web application frameworks, of which there are endless? This makes about as much sense to me as "Why Flask will kill Zend".
Why do people put so much effort in comparing tool A to tool B when either of those tools only cover 5% of all the work that goes into any serious application, and the time saved by any advantage tool A has over tool B is pretty much negligible? I mean cool, so Meteor is maybe better for prototyping. Because that's all we're talking about here, prototypes and ultra-simple websites. It's always the same story, a shiny…
Earlier quoted context omitted.
Try it before you knock it, I would bet money you would enjoy it.
I already hate writing Javascript for the frontend. If I had to write it on the backend, too, I'd probably go insane. Coffeescript makes things a bit better, but only to an extent (plus it has a few odd quirks of its own). I'd much prefer if some day the reverse was possible: writing Python or Ruby on the backend AND the frontend. I imagine something like that would render Node rather useless. (And no, they did not i…
Earlier quoted context omitted.
Insert mis-attributed Henry Ford quote about customers wanting faster horses
If you're going to make a bold prediction about Meteor killing Rails be prepared for some heat - your responses to that heat may progress or regress the argument.
Let's all hop on the next hip web trend, guys! Rails has become so boring and mature. There are many languages better than Javascript for server-side programs, but monoculture is so much cooler. One size fits all and you'll like it.
This is what Java guys said about Rails. "Hipness" is absolutely unrelated to whether something is actually good or not. I firmly believe that Meteor is a super fast way to build a certain kind of web app that just so happens to be very popular in businesses: CRUD apps where users can see other user's changes to data in real time. I will admit that older users are actually creeped out by other people seeing them type…
Earlier quoted context omitted.
I already hate writing Javascript for the frontend. If I had to write it on the backend, too, I'd probably go insane. Coffeescript makes things a bit better, but only to an extent (plus it has a few odd quirks of its own). I'd much prefer if some day the reverse was possible: writing Python or Ruby on the backend AND the frontend. I imagine something like that would render Node rather useless. (And no, they did not i…
It is already happening. Not specifically with python or ruby (although possibly, I don't follow them), but several languages have "compile to javascript" options now. Just like we treat CSS as purely for the machine generated from the SASS which is for people, we treat javascript as purely for the machine generated from the haskell which is for people.
I also believe there are some current projects that compile Python and Ruby into JS, but I'm not sure how mature they are.
Why will a blog load anything over websocket? Link bait title and a blog that doesn't load.
I can think of one reason, although it's not necessarily a good one, or the only way to do it. Once the connection is established, the server could push down all required resources for the page, rather than wait for the browser to request them one by one.