[deleted]
Why Meteor will kill Ruby on Rails
241–250 of 336 posts
Re: Why Meteor will kill Ruby on Rails
#242"When a client asks us to build an app, they are really asking for a fully interactive web app that utilizes javascript to get rich client interfaces." Or maybe they really are just asking you for an app, but you'd rather build a fully interactive web app that utilizes javascript to get rich client interfaces.
No, the client that spawned this blog post was specifically asked for heavy google maps integration. We haven't had one client asking for just a server side app in years. I've been doing this for 8-9 years, I have a good idea on how to talk with my clients :)
I'd love to see what your client actually wanted. Is the site launched/public yet?
Because there's a subset of map-based sites for which pure, out-of-the-box Google Maps is the best solution, but I'd estimate it at no more than 30%. (StreetView and consistent street-level addressing are the two main points in its favour.)
For the other 70%, you will build something better by working with the raw map data (which usually means PostGIS) and using custom cartography (which could mean a lot of things, but let's say TileMill+OpenStreetMap).
This greatly swings the balance back towards Ruby or Python. FWIW I don't generally use Rails, preferring a custom Rack+DataMapper stack, but the same point holds. The amount of smart geo stuff you can do in one line of code with a PostGIS-friendly ORM is astonishing.
More broadly, your article says "technology A is better than technology B because C". That's cool. And here I am, posting a comment that says technology D (custom geo) is better than technology E (GMaps) because F. No doubt there are also arguments G, H, and so on. Your C is essentially a productivity argument - do the same thing faster. That's important, yes, but deeply personal (I find it difficult to believe I'd ever be as productive in JS as Ruby, and I'm not entirely a JS n00b). But if F, G, and H enable you to do actual new stuff, they're the arguments I'll listen to.
Re: Why Meteor will kill Ruby on Rails
#243Earlier quoted context omitted.
I'd love to see some examples of these apps, are you able to please share?
Sure: http://www.shinglecentral.com/ http://assistant.io/ http://lister.io/ Are just a few from the last 1.5 months.
cough in the UK shingles is the name of a very uncomfortable medical condition... :D
Re: Why Meteor will kill Ruby on Rails
#244What is the big difference between Meteor and let's say Sailsjs?
I've never heard of Meteor before but it looks promising. I will try it when I get home :)
Re: Why Meteor will kill Ruby on Rails
#245Earlier quoted context omitted.
That's all true, but I'm also beginning to wonder how much you actually need those frameworks to build MVPs quickly. I used to do the bulk of my prototyping with Python + Django + JQuery + Postgres or AppEngine Datastore. Of late, I've switched a lot of it to just straight HTML + Javascript + a JSON feed from backends. If I need server-side computation, I'll build a quick Go or webapp2 app on AppEngine. I work just a…
> and doesn't require that you download 90k of JS each time you want to refresh. That's what caching headers are for. You can effectively cache your "big" JS libs indefinitely on the client, as you'll change the URL and therefore require a fresh download when the lib gets updated. This isn't to say that cold cache performance isn't also important, but even a slow DSL connection should be fine with a once-off jQuery d…
I ran some experiments on this when I first joined Google. With JQuery loaded off ajax.googleapis.com, running my tests on google.com, cache hit rates were roughly 87%. This is with a CDN that caches everything indefinitely and the most visited site on the web at the time.
There's an extremely long tail of people who browse the web only occasionally, or have just one favorite site they go to, or who are running on devices with small caches, or who just cleared their cache because they wanted to look at porn. The hit rates are probably even worse now with the shift to mobile, because mobile devices have tiny caches. In recent prototyping experience using Chrome ADB to check on network traffic, files are gone from cache after only a half dozen or so other pageviews.
You can't assume "caching will take care of it" if the site downloads several hundred K of JS. Caching is effective at making an already-lean site even faster, and you get even more bang for your buck because more pages can fit in cache when the pages are small.
Anyway, I was thinking mostly about developer experience when I wrote that comment (this thread is about MVPs), and also mostly about mobile development, where the bulk of my time is spent lately. JQuery is a noticeable drag when loading a page over a cell network, even if you just want to try out some ideas. It's not just network latency, either; on mobile devices, you can burn significant time (and battery) just parsing and executing all that JS.
Re: Why Meteor will kill Ruby on Rails
#246Let'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…
I missed out the first time around because the Rails community was full of fanboys and nothing turns me off a community more than zealot-like behaviour.
I don't want to miss out again.
Re: Why Meteor will kill Ruby on Rails
#247Earlier quoted context omitted.
http://docs.meteor.com/#spiderable Could this could be used if the browser does not support JS?
Yes, and you can control a list of user agents that it activates for.
Assuming that google-bot has its own user agent isn't the excuse for not generating the HTML for the people who want to read the site.
Re: Why Meteor will kill Ruby on Rails
#248I don't think so. Javascript frameworks are for real time applications, while RoR (and the other "classic" web frameworks) are simpler to set and to use for the classic dynamic HTML applications, and I don't think real time apps will overwhelm classic HTML apps.
Re: Why Meteor will kill Ruby on Rails
#249How 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".
The author came to this Ruby on Rails dichotomy for the very same reason other frameworks/languages are doing so:
1) To cash in on Rails's good rep and outstanding efforts in the field in the past 10 years or so.
2) Because the author knows that people are fiddle and that new fashions are made and destroyed every other day, so why not scare people a little if that can help Meteor get off the ground, eh?
3) Because shitting on Rails is trendy these days and it's always very easy to precisely target the relative weaknesses of a framework whilst pretending to ignore its strengths. Anybody with half a brain can play that game.
That being said, it doesn't diminish Meteor's merits in any way and I really hope its community thrives and grows in the next few years. The first few years are always the best ones :)
Re: Why Meteor will kill Ruby on Rails
#250> Let's be real, Javascript is the #1 language on Github and for good reason - it runs everywhere. Cancer is #1 disease in the world, but that doesn't mean I want it.
Good analogy. And the funniest part is when people say it should spread from client ("body") to server ("brain").