It might take some time, but I have to agree after working in Meteor for a few months, the developer experience is much better than trying to do Rails/Backbone Rails/Ember or Rails/Angular.
It's not quite there yet but it's getting better by the day. There are still some things like UI animations that are possible in Meteor but aren't quite as easy as they are in client side Javascript frameworks.
It makes me feel a little better though that they are trying to be transparent about the flaws by publishing their roadmap:
It's the framework I'm most excited about and watching closely. I still think Rails has a place in the back-end (e.g. API) but Meteor is showing a lot of promise.
All of the sporks I have used have tines that are too short for proper spaghetti-twirling. Also, their bowls are always so shallow that it makes soup a chore to consume. What kind do you use?
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 invent the first or the last usable asynchronous web framework.)
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.
The performance is the same as if you wrote the javascript by hand. The only potential performance issue is when the compiler generates really poor javascript for some particular bit of code, where a person would have written less poor javascript if doing it by hand.
Is the inability to get HTML without being a javascript engine going to be a problem for major adoption? (I know there are hacks around using phantomjs to generate HTML for non-JS clients -- is that a viable solution for serious sites?)
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.
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.
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.
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.
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.
No, I'm referring to the languages themselves. JS does a very few things better than Java, but it is simply chock full of bizarre type coercion rules, strange semantics, and other "hall of mirrors" gotchas which make it much harder to learn and work with than other dynamic languages. And yes, Java has some of these too, but they occupy a much smaller share of the language base, and are often a side-effect of useful features (such as signed integer types) which JS doesn't provide.
We're stuck with JS because it's "the language that runs in every browser," but that's no reason to grant it praise that it hasn't earned such as "easy to use."
Fragmentation will create headaches regardless of which language is running in the browser.
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".
Give this whole Meteor thing some more time to sink in.
Your still in the honeymoon phase. I know this because you list context switching. Anyone that moves to Node(or meteor) and lists context switching as a reason, is not long for this world... of switching to node.
I'm not going to convince you here, but just proceed with caution. It would be like me convincing my friend after he's dated a girl for a year that she's a total ass. Not going to happen.
They're both web frameworks with a heavy focus on RAD. It's hard to see how much more similar they could be before they started to become indistinguishable.
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 :)
"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 :)
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.
So, now you agree with what carsongross originally asked? The client does just want an app and you believe you know better and foist a broken javascript app on them?
We've got a pretty good google maps integration in our rails app & I've found sticking with plain old rails for CRUD and using fancy-pants javascript in high-value places to work out well.
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.
The hyperbole of your blog post really annoys me. The urge to generate traffic lessens the quality of the overall discussion here on hn and within the larger programming community.
As an author with every post and submission you make a conscious decision about what is important to you. Do you want to enlighten your readers or do you want to gain notoriety at the expense of your audience?
Ask yourself, do you want to be the Daily Mail or Le Monde?
I can't read the site (there's nothing in HTML) but is this a framework that doesn't produce pages viewable without JavaScript? If it is against HTML, my vote is against it.
I'm against this too. Why do we want Javascript engines serving simple text pages instead of HTML? What about accessibility? Look at the source code of the linked article. What would a screenreader user encounter if they visited this page?
Pardon the pun, but that old chestnut? Contemporary screen-readers implementing WAI-ARIA (http://www.w3.org/WAI/intro/aria) work with javascript web applications.
Ever tried the above site with the screen readers? The sites produced with Meteor? I claim it would be easier for most of the programmers to generate HTML representation than to implement support for that. HTML is basics. Everybody can test it: just turn off JavaScript.
"Contemporary screen-readers implementing WAI-ARIA...work with javascript web applications."
This isn't a web application though (in terms of interactivity), it's a plain text page. Why do we want Javascript to serve plain text pages like this?
Also, on the WAI-ARIA site, the expectation seems to be that Javascript is used for dynamic content or widgets (for which there are Aria-roles), but that HTML is used for text content (correct me if I'm wrong about this).
Again, if you look at the source code of this page, I can't see how it would be accessible.
While I was reading this post, the page automatically reloaded to something that said "oops, this page can't be found", and then a few seconds later loaded back to the original. This is while I was simply reading the text, not interacting with the page at all.
Somehow, through the magic of JavaScript and Websockets, they managed break passively reading static content.
It's not static and it's not readable HTML when accessed without JavaScript. If I understand, that's the feature of the framework that is being praised.
I don't think that's completely fair. Meteor to me, is more cased for building realtime applications. Should a blog be a realtime application? Probably not, can it? Sure.
Not only that but, but the page compensated.
It's also kind of neat, that the author has indeed written a realtime blog. For fun: they could magically fix typos while you're reading.
sorry that was a deploy to fix the "oops, this page can't be found" that was flashing before the page loads. When we deploy Meteor, it hot fixes the client (i.e. restarts the app in your browser)
My skepticism here is due to the use of an "app in my browser" to display a static blog post.
A blog post is fairly simple static content. My browser is an app that does fine at displaying it. By making the page an app that dynamically updates upon server changes, you actually substantially damaged my experience, as I was interrupted in the middle of reading the page.
I'm not opposed to apps which dynamically update data in real time from the server, when that's appropriate. A static blog post does not appear to be such a case.
The irony here is that this was on an article titled "Why Meteor will kill Ruby on Rails", an overstated claim describing how a framework build around updates from the ground up is so much stronger than one based on delivering static content. The actual behavior of the page seemed to speak more loudly than the content.
It takes maybe a day working with your Capistrano script to implement zero downtime deploys in Rails if you're running Unicorn, Puma, or Passenger Enterprise...
The fact that its hosted at Modulus (the guys behind Demeteorizer, which allows you to host meteor apps on Node.js services) would indicate that its almost certainly a Meteor app to me.
I DO think that Meteor is fucking awesome, due to the sheer speed you can crank out commonly requested features (you can add a Google/Facebook/Github Oauth login widget with one line of code), but it sure as hell doesn't seem to scale well these days.
Did not read TFA, but my immediate thought on seeing this headline is "No, it won't". Why? Because software never really seems to die. Look at the billions of lines of COBOL or PL/I or FORTRAN still in use around the world. Look at the fact that (a few) people still use OS/2, which is about as dead as software ever really gets.
Rails may well find it's popularity and prestige diminished, but I doubt it'll "die" anytime in any of our lifetimes.
100% agree here. Way to many Rails developers around for it to die. Also as cool as Meteor is, and it's pretty cool. There is a huge continent of developers that will resist javascript for as long as possible, because even though it is ubiquitous, let's be honesty, it does suck in a number of ways. Ruby / Python / Go / etc.. are all so much nicer languages from a developer happiness perspective. Ultimately javascript will become more and more prevalent for sure, and Meteor along with it, but only because all the browsers decided to support it, NOT because of developer happiness.
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.
Meteor is not (and rails probably isn't either) the right tool for a simple blog like that. jekyll or something like that is.
The fact that you used an inappropriate tool for a blog and then say on the blog how you use that tool for all your clients casts a shadow on your professionalism I feel.
Is this blog also running on Meteor? I can't get it to load so that's not instilling confidence. Maybe it's their host, https://modulus.io/ that's having problems?
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 though. I guess its a generational thing.
They were right when they said that about rails though. Rails was a fad. It was not good. It codifies industry worst practices into a framework that can most charitably be described as "writing PHP in ruby".
I'm not going to sing the praises of Rails. I think it is a pretty good framework, but it is one hell of a hype machine. As software gets older and more stable, people get bored and reinvent the wheel again, especially web developers that will stop at nothing until everything is written in Javascript.
Rails was a fad. Meteor is a fad. Keep your nose out of hype.
Fads are good. Being able to run everywhere is also good, but frameworks eventually need to give way to new ideas. Not everyone wants to program in COBOL on .NET forever.
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.
Then evaluate things on their merits and ignore the fanboys. There are plenty of people in this world looking for silver bullets, that someone excitedly claims to have found one is no reason to believe them.
When Meteor was released couple months ago on "Show: HN" or something, I recalled unit-testing is not part of the release. Wonder if that's still the case?
Maybe it's common not to have good unit-tests? (integration/functional-test does not count as unit-test).
Sure, there are plenty easy-to-install-but-not-necessary-to-use-properly tools out there as well. Not to knock off your argument but would love to see stronger emphasis on proper automation test (QUnit does not count as "proper") over the JavaScript community in overall.
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 new tools that make the first weeks a little smoother, and after that it's business as usually for entire life cycle of the application.
Except of course you now have to deal with a tool that still has years to go before it's really mature and stable, and any advantage you gained in the first few weeks is completely lost.
This has nothing to do with software development, this is just about fashion.
Can you point to some example that are a bit more complex in nature? My issue (that I identified with the backbone tutorials and re affirmed with the Angular tutorials) is that simple apps are easy to do with x, y or z. But if the new one or that one is going to replace the old one there should be 37 signals level complexity type apps out there. While I can't speak for Meteor, I don't see anything running on angular that's at that level.
Caveats: I glossed over the fact that angular is not a full stack, I have seen a few angular videos where teams have demoed and presented on complex angular apps.
podio.com is a pretty large enterprise app based on a Rails+Backbone stack. Their approach is to have multiple Backbone Apps (dashboard, contacts, tasks, calendar) for different modules. So if you switch modules you have page refresh and from there its a Backbone App...i like that approach and their app is pretty awesome.
There is when the client doesn't want to pay for the extra work for the 0.1% of tinfoil hat-wearing people who turn off JavaScript.
"You need to spend an extra 30,000 to get this to work for the 3 crypto-anarchist wannabes who live in your state".
I don't think the client is going to want to pay for that kind of interop.
EDIT: I don't mean to be snarky but you absolutely HAVE to make these kinds of trade offs when working for people. And you have to absolutely discuss them with clients.
When a client asks for 'hey I want it fast like facebook and some of those cool animations I see wasitcalled haych-tee-em-ell five or something right? also it has to work on iphones because my wife has one', there is a hell of a lot of discussion there about tradeoffs. If the project you are building for them is speculative then even more so shit ain't gonna work for some people because they just aren't going to want to spend the money.
The last small job I did, I got a late requirement of "this actually has to work in IE7, 8 and 9", and stupid me, not hammering this down contractually the interop from the get go it ended up taking up nearly 20% of the budget in the end to get this working retroactively, and this was a small project.
It shouldn't be extra work. It's actually less work because it encourages you to play to the browser's strengths and to separate your concerns. It keeps rendering speed high, it makes it easy to debug issues because you can switch off JS to see if the problem is with the underlying HTML/CSS. If one JS component fails it doesn't take down the rest of the site, and so on.
Your website should work in IE7. It's a legitimate browser with real users. This doesn't mean it needs to behave exactly the same way as IE10, but a visitor to my site using lynx should get some level of use out of it.
Again, this helps you massively in the long run because the browser scene changes all the time. If you work hard to make your site work across the browsers you know about, it's more likely to work on the browsers you don't know about, or the ones that haven't been invented yet. (It took the iPhone to take Safari from a browser that nobody cared about to the browser everyone cared about pretty much over night.)
This depends entirely on what the customer is asking for, and how they're asking for it to be done, and whether or not they even care about fancy tricks or plain websites/web apps.
Non trivial example: client wants drag and drop uploads. What browsers support this functionality? Oh we can't do that in browser X Y and Z. Is that a problem? Oh, it turns out it is because manager A promised this to the CEO and she runs IE7 due to corporate IT policies. Crap. OK trade-off time, what should we do? Drag and drop for chrome that my boss runs or just stick to old school uploads? Use some plugin from jquery.com? OK let's do that. Now we have apparent 'automatic fallback' via the plugin but... boss wants it to display the image for confirmation in newer browsers, shit... Does the plugin support this? Yes? No? Let's say no now you're looking for another off the shelf or a roll your own.
Now you can say what you want about 'it should just work bler bler it's easy' but if you extract this attitude out to all areas of a software project you end up with the inmates running the asylum pretty much overnight. Like it or not, but the team or individual you are working with all have varied skill sets and you have to make work with what you have. The trick isn't 'just make it work with javascript off', it's 'deliverer something in the timeframe and on budget with the resources available' and those are different every time you embark on something.
it's "broken" in similar ways, showing markup like ${{product_price}}, but clearly includes enough static-content and context to allow be to choose whether I want to click my "allow scripts" button.
If somebody sent me a link to Shingle Central with no explanation, I'm highly likely to go "whatever" and move on t the next work-distraction-link…
We have that in America too caused by the varicella-zoster virus (aka chickenpox). That's not the first thing I thought of though - I thought it was going to be a site to help you find a roofing company. The "hang out your shingle" definition was the last thing I would've thought of.
Making repeated prototypes (in est, experiments), quickly, is how you approach entrepreneurialism in any sort of scientific manner. Nothing needs to scale, or work at the edge-cases, until it has product-market fit; and you might need to write twelve or twenty or two-hundred different apps until you find one that works out that way.
That's what makes these frameworks popular with HN: startup founders are not in the business of executing on a known business model (which might be viably accomplished even through a waterfall process and code written in C); rather, we're in the business of searching for a business model by building MVP after MVP, as quickly as we can.
MVPs don't need to be able to be evolved into stable, well-engineered products. They just need to prove product-market fit. Once you've got your traction, your proof, your intent-to-buy, you can use that to get the loans or capital, to hire the talent, to build the Well-Engineered Version. Until then, "engineering" is not even a consideration.
I am sitting at a Meteor unconf today and we are talking about scalability of Meteor... There are some very interesting pieces coming out in the next month to really push the envelope on handling a lot of users at once.
I would agree, we are in the business of building MVPs every day so it is much more interesting to us, I bet.
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 as fast if not faster, and there is far less that can go wrong. I'm not constrained by the idioms of the framework in development (this is a major problem with MVPs - all Rails/Django apps seem to end up looking like a bunch of forms over a database, even if that's not the best interface for users), and if one of the approaches works, I have an easier time productionizing.
For my most recent prototype, I started with JQuery (as usual) and then quickly end up removing it when I found that everything I used to use it for is now built into the browser. $ = querySelectorAll; .on = addEventListener; .addClass = .classList; .animate = CSS3; .ajax = iframes. And all of the browser native stuff runs significantly faster, and doesn't require that you download 90k of JS each time you want to refresh.
It's not 2006 any more. You can pretty much prototype in Webkit only, most of the things you need are built into the platform, there are easy minimalist libraries that will let you setup a JSON feed out of AppEngine with barely any code, and JS on the client can do pretty much everything. At least until you start caring about latency, but by then you're out of MVP range.
is there any small library ala "notjquery.js" that is a drop in replacement for jquery but that calls the browser native stuff directly ? serious question ?
You probably want something like Zepto.js. I'd also look into Lo-dash, which is a better, more functional-friendly version of Underscore.js that provides a ton of useful helper functions.
Be warned: Zepto doesn't claim to support any version of IE, so if you need IE support you'll want to fall back to jquery (yepnope works. Conditional HTML won't in IE10+).
jQuery does exactly that, with polyfills for browsers without the native implementation. jQuery 2.x does away with many of the polyfills since older IE versions aren't supported.
If you want an even smaller jQuery, you can build your own[0] without the modules you don't need.
> 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 download.
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.
I was pretty much in the same boat as you regarding all the other choices, but when i saw this I thought: "Seriously?"
I remember when AJAX came out: I was finishing my iframe-based custom-rolled 'AJAX'. It was such a hack, I can't even believe someone would consider it in 2013.
1. You can do progressive rendering with an iframe. With an XHR you don't get the 'loaded' callback until the entire response has arrived, and so you can't start working with and manipulating the data until it's all there. With an iframe you can put successive chunks in <script> tags and they will start executing as soon as the closing tag for the script is found. Or if you want to transport the data as HTML, you can put a 0-length animation on each element that forms a response chunk, and listen for the animationend event to get notified as soon as it's ready in the DOM.
2. You can measure and manipulate elements while they're still in the iframe. For example, if you're animating the rest of your layout, you can measure the size of the elements that you just loaded inside a hidden iframe, adjust transitions on the main page to make space for them, and then pop the elements from the iframe into their proper places in the final layout. With an XHR, the only way to measure the element is to place it into the DOM and force a layout, which is much slower, particularly on mobile devices.
3. Iframes form a layout boundary, so when the browser lays out elements in them it stops the layout process at the iframe. This eliminates the need to do a CPU-intensive layout of the whole page when you pop in your XHR content.
Regarding the first objection, you could just send your responses as a series of websocket messages, rather than repeated AJAX request/response pairs.
The other two objections I'm not so clear on--maybe because I don't often dynamically construct views by retrieving "presentation" from the server. In what I've seen as "idiomatic HTML5 client-side development", all the views are shipped as templates with the initial code-blob that starts up the client; from then on, the client just speaks pure data-related JSON to the backend's plain HTML-unaware API. Does this practice not scale to Google levels? :)
Yeah, websockets are fairly useful if your data is JSON blobs or other byte data, but awkward if you just want to ship some more HTML for display. They're best used in long-running client applications.
As for sending JSON with rich clients vs. rendering HTML on the server; that depends a lot on the intended usage pattern of the app. For apps that you expect will be open for hours at a time, like e-mail or social networking, the former pattern is better - and indeed, GMail and G+ both speak JSON (well, a modified version that gives better latency) to rich client JS. For apps that you open quickly, perform your task, and then close (Search is the canonical example), it's far better to render all your HTML on the server and just ship that down to the browser. There is a large cost to downloading and executing all that JS, and you lose many, many customers if your app is slow.
There are strategic reasons why, if I were founding a startup today, I'd prefer to play in markets where the latter case held, unless I was writing enterprise software. Consumer markets where people spend hours with an app open are rare, and Google/Facebook generally want to own that space. I would rather not compete with them. On mobile, the open-for-hours apps are generally moving to native, where you can interact with the platform's notification API. The sweet spot for long-running webapps is enterprise and intranet applications, which has many fruitful markets, but many technologists shy away from it because there are frequently many arbitrary and difficult requirements.
> well, a modified version that gives better latency
Any more details on this (that you're allowed to talk about)? Low-latency JSON-alike communication is something I'd be highly interested in.
Personally, I've investigated BERT.js for this use-case, but it didn't work quite right (likely since the available client library was written to construct binary messages using String.charCodeAt, rather than just writing directly to an ArrayBuffer.) I kind of gave up when I realized I might be--especially on mobile--spending long enough on the pure-JS encoding/decoding processes (versus the browser's native JSON implementation) to lose any gains I'd get from the network. If you know otherwise, I'd like to hear about it.
that's all correct, but then you ruined it with the .ajax= iframes nonsense and the total waste of time removing jquery. optimizing for the right things is important, but doing the wrong ones is just wasting your time.
One of my big surprises moving to Google was how much iframes are still used, but even beyond that is the very pragmatic approach of looking for exactly what a technology gives you and what it costs you in return. There's basically a 1:1 correspondence between the API of an iframe and the API of an XHR:
xhr.open = iframe.src
xhr.onreadystatechange = iframe.onload
xhr.response = iframe.contentDocument
Many devs don't like working with iframes because it doesn't fit their mental model of how a request should work (possibly because iframes were initially introduced with a visual extent), but that's a problem with their mental models, not with iframes. You can always wrap the API if you don't like it, anyway - pretty much all the major frameworks do, since raw XHRs are a bit clumsy to use.
Let’s say you decide one day you want to build a table. This table is going to be made using wood, nails and a hammer. All things being equal, let’s say you build this table with hammer A that has a utility of 10. You build a second table with hammer B and it has a utility of 15. You, the carpenter, have now created two tables, table A and table B, respective to their hammers. The tables are identical, but the utility is different. Now let’s say your utility as a carpenter is 5 (we’ll call this carpenter ‘ME’). The value of the tables is now: Table A – 50 and Table B – 75. Now, my carpenter friend (we’ll call this carpenter ’FR’) has a utility of 4 and he builds the same tables using the same respective hammers. He now has two tables at the following values: Table A – 40 and Table B – 60. So we can build a simple comparative matrix now. Table B built by FR has a higher utility than Table A built by ME but it was built by a less skilled carpenter! We therefore logically assume the hammer is the key driver for the overall utility, not because it has a higher multiplier, but because we believe we have better ability over assessing what the utility of the hammer is. We then therefore place much more importance on it.
What is utility measure of? This analogy is way too simplified to be of real importance. There are more tools that go into building a scalable, maintainable table.
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?
Derby (http://derbyjs.com/) ostensibly does everything that Meteor does, but seems to be flying a bit under the radar. I'd be interested to hear comments from anyone that has had experience building apps in both Derby and Meteor.
I've used both and actually prefer Derby. They don't toss out Node (which the Meteor team did), thus making it easy to leverage the growing Node ecosystem. Also, I'm constantly left scratching my head as to why the Meteor team chose to make backend code synchronous.
That being said, Meteor simply has a lot more developer talent (and money) behind it. Hence it's improving at a much faster rate than Derby.
335 comments
[ 4.0 ms ] story [ 274 ms ] threadIt makes me feel a little better though that they are trying to be transparent about the flaws by publishing their roadmap:
https://trello.com/b/hjBDflxp/meteor-roadmap
Similarly, anal sex is the best kind because it works on all genital configurations. /snark
Many a plate of school lunch spaghettis has been eaten with a spork.
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 invent the first or the last usable asynchronous web framework.)
I also believe there are some current projects that compile Python and Ruby into JS, but I'm not sure how mature they are.
Decaf: http://trydecaf.org/ Opal: http://opalrb.org/
A quick google search gave me Pyjs. http://pyjs.org/
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.
Who knows 5-10 years down the line...
Enterprises use Java or .Net.
I'm thinking maybe the drama wasn't a requirement for this to happen. Perhaps Meteor devs could experiment with that idea.
I'd love to hear how you're better acquainted with 'nikatwork's feelings on JavaScript than he is.
Ruby is the worst language ever, because I do not know how to use it.
https://github.com/orefalo/meteor-typescript-compiler
http://www.typescriptlang.org/
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.
LOL @ Java being described as "hard to work with" in comparison to JavaScript. Major indicator of JS developer Stockholm Syndrome right there.
We're stuck with JS because it's "the language that runs in every browser," but that's no reason to grant it praise that it hasn't earned such as "easy to use."
Fragmentation will create headaches regardless of which language is running in the browser.
This makes about as much sense to me as "Why Flask will kill Zend".
Your still in the honeymoon phase. I know this because you list context switching. Anyone that moves to Node(or meteor) and lists context switching as a reason, is not long for this world... of switching to node.
I'm not going to convince you here, but just proceed with caution. It would be like me convincing my friend after he's dated a girl for a year that she's a total ass. Not going to happen.
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 :)
I hate to be negative but that's not how to win my confidence.
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.
I've been doing this for 8-9 years, I have a good idea on how to talk with my clients :)
We've got a pretty good google maps integration in our rails app & I've found sticking with plain old rails for CRUD and using fancy-pants javascript in high-value places to work out well.
Your milage, and billing rates, may vary.
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.
As an author with every post and submission you make a conscious decision about what is important to you. Do you want to enlighten your readers or do you want to gain notoriety at the expense of your audience?
Ask yourself, do you want to be the Daily Mail or Le Monde?
This isn't a web application though (in terms of interactivity), it's a plain text page. Why do we want Javascript to serve plain text pages like this?
Also, on the WAI-ARIA site, the expectation seems to be that Javascript is used for dynamic content or widgets (for which there are Aria-roles), but that HTML is used for text content (correct me if I'm wrong about this).
Again, if you look at the source code of this page, I can't see how it would be accessible.
Could this could be used if the browser does not support JS?
Somehow, through the magic of JavaScript and Websockets, they managed break passively reading static content.
Not only that but, but the page compensated.
It's also kind of neat, that the author has indeed written a realtime blog. For fun: they could magically fix typos while you're reading.
A blog post is fairly simple static content. My browser is an app that does fine at displaying it. By making the page an app that dynamically updates upon server changes, you actually substantially damaged my experience, as I was interrupted in the middle of reading the page.
I'm not opposed to apps which dynamically update data in real time from the server, when that's appropriate. A static blog post does not appear to be such a case.
The irony here is that this was on an article titled "Why Meteor will kill Ruby on Rails", an overstated claim describing how a framework build around updates from the ground up is so much stronger than one based on delivering static content. The actual behavior of the page seemed to speak more loudly than the content.
It's difficult to implement the same functionality with Rails, where the default is to be down while deploying.
I DO think that Meteor is fucking awesome, due to the sheer speed you can crank out commonly requested features (you can add a Google/Facebook/Github Oauth login widget with one line of code), but it sure as hell doesn't seem to scale well these days.
Rails may well find it's popularity and prestige diminished, but I doubt it'll "die" anytime in any of our lifetimes.
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.
Meteor is not (and rails probably isn't either) the right tool for a simple blog like that. jekyll or something like that is.
The fact that you used an inappropriate tool for a blog and then say on the blog how you use that tool for all your clients casts a shadow on your professionalism I feel.
Rails was a fad. Meteor is a fad. Keep your nose out of hype.
I don't want to miss out again.
Maybe it's common not to have good unit-tests? (integration/functional-test does not count as unit-test).
Blog try to refresh after HN traffic killed the backend.
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 new tools that make the first weeks a little smoother, and after that it's business as usually for entire life cycle of the application.
Except of course you now have to deal with a tool that still has years to go before it's really mature and stable, and any advantage you gained in the first few weeks is completely lost.
This has nothing to do with software development, this is just about fashion.
http://www.shinglecentral.com/ http://assistant.io/ http://lister.io/
Are just a few from the last 1.5 months.
> Uncaught Error: Must set options.password > 62afa287c8fae43c43f745c9f43dbcd4b875e531.js:14
> Uncaught TypeError: #<Object> is not a function
When trying to add attendees,nice UI though.
Caveats: I glossed over the fact that angular is not a full stack, I have seen a few angular videos where teams have demoed and presented on complex angular apps.
https://dl.dropboxusercontent.com/u/7633426/shinglecentral.p... https://dl.dropboxusercontent.com/u/7633426/assistantio.png https://dl.dropboxusercontent.com/u/7633426/listerio.png
If you want to use a javascript tool you´ll have to add an exception for this tool.
"You need to spend an extra 30,000 to get this to work for the 3 crypto-anarchist wannabes who live in your state".
I don't think the client is going to want to pay for that kind of interop.
EDIT: I don't mean to be snarky but you absolutely HAVE to make these kinds of trade offs when working for people. And you have to absolutely discuss them with clients.
When a client asks for 'hey I want it fast like facebook and some of those cool animations I see wasitcalled haych-tee-em-ell five or something right? also it has to work on iphones because my wife has one', there is a hell of a lot of discussion there about tradeoffs. If the project you are building for them is speculative then even more so shit ain't gonna work for some people because they just aren't going to want to spend the money.
The last small job I did, I got a late requirement of "this actually has to work in IE7, 8 and 9", and stupid me, not hammering this down contractually the interop from the get go it ended up taking up nearly 20% of the budget in the end to get this working retroactively, and this was a small project.
Your website should work in IE7. It's a legitimate browser with real users. This doesn't mean it needs to behave exactly the same way as IE10, but a visitor to my site using lynx should get some level of use out of it.
Again, this helps you massively in the long run because the browser scene changes all the time. If you work hard to make your site work across the browsers you know about, it's more likely to work on the browsers you don't know about, or the ones that haven't been invented yet. (It took the iPhone to take Safari from a browser that nobody cared about to the browser everyone cared about pretty much over night.)
Non trivial example: client wants drag and drop uploads. What browsers support this functionality? Oh we can't do that in browser X Y and Z. Is that a problem? Oh, it turns out it is because manager A promised this to the CEO and she runs IE7 due to corporate IT policies. Crap. OK trade-off time, what should we do? Drag and drop for chrome that my boss runs or just stick to old school uploads? Use some plugin from jquery.com? OK let's do that. Now we have apparent 'automatic fallback' via the plugin but... boss wants it to display the image for confirmation in newer browsers, shit... Does the plugin support this? Yes? No? Let's say no now you're looking for another off the shelf or a roll your own.
Now you can say what you want about 'it should just work bler bler it's easy' but if you extract this attitude out to all areas of a software project you end up with the inmates running the asylum pretty much overnight. Like it or not, but the team or individual you are working with all have varied skill sets and you have to make work with what you have. The trick isn't 'just make it work with javascript off', it's 'deliverer something in the timeframe and on budget with the resources available' and those are different every time you embark on something.
Screw you buddy.
Compare the above screenshots with this one:
https://dl.dropboxusercontent.com/u/7633426/BundleHunt.png
it's "broken" in similar ways, showing markup like ${{product_price}}, but clearly includes enough static-content and context to allow be to choose whether I want to click my "allow scripts" button.
If somebody sent me a link to Shingle Central with no explanation, I'm highly likely to go "whatever" and move on t the next work-distraction-link…
your domain is literally "shingle" central
what? I don't even
That's what makes these frameworks popular with HN: startup founders are not in the business of executing on a known business model (which might be viably accomplished even through a waterfall process and code written in C); rather, we're in the business of searching for a business model by building MVP after MVP, as quickly as we can.
MVPs don't need to be able to be evolved into stable, well-engineered products. They just need to prove product-market fit. Once you've got your traction, your proof, your intent-to-buy, you can use that to get the loans or capital, to hire the talent, to build the Well-Engineered Version. Until then, "engineering" is not even a consideration.
I would agree, we are in the business of building MVPs every day so it is much more interesting to us, I bet.
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 as fast if not faster, and there is far less that can go wrong. I'm not constrained by the idioms of the framework in development (this is a major problem with MVPs - all Rails/Django apps seem to end up looking like a bunch of forms over a database, even if that's not the best interface for users), and if one of the approaches works, I have an easier time productionizing.
For my most recent prototype, I started with JQuery (as usual) and then quickly end up removing it when I found that everything I used to use it for is now built into the browser. $ = querySelectorAll; .on = addEventListener; .addClass = .classList; .animate = CSS3; .ajax = iframes. And all of the browser native stuff runs significantly faster, and doesn't require that you download 90k of JS each time you want to refresh.
It's not 2006 any more. You can pretty much prototype in Webkit only, most of the things you need are built into the platform, there are easy minimalist libraries that will let you setup a JSON feed out of AppEngine with barely any code, and JS on the client can do pretty much everything. At least until you start caring about latency, but by then you're out of MVP range.
Be warned: Zepto doesn't claim to support any version of IE, so if you need IE support you'll want to fall back to jquery (yepnope works. Conditional HTML won't in IE10+).
If you want an even smaller jQuery, you can build your own[0] without the modules you don't need.
[0] https://github.com/jquery/jquery#how-to-build-your-own-jquer...
wait...what?
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 download.
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.
I remember when AJAX came out: I was finishing my iframe-based custom-rolled 'AJAX'. It was such a hack, I can't even believe someone would consider it in 2013.
Why not XMLHttpRequest?
1. You can do progressive rendering with an iframe. With an XHR you don't get the 'loaded' callback until the entire response has arrived, and so you can't start working with and manipulating the data until it's all there. With an iframe you can put successive chunks in <script> tags and they will start executing as soon as the closing tag for the script is found. Or if you want to transport the data as HTML, you can put a 0-length animation on each element that forms a response chunk, and listen for the animationend event to get notified as soon as it's ready in the DOM.
2. You can measure and manipulate elements while they're still in the iframe. For example, if you're animating the rest of your layout, you can measure the size of the elements that you just loaded inside a hidden iframe, adjust transitions on the main page to make space for them, and then pop the elements from the iframe into their proper places in the final layout. With an XHR, the only way to measure the element is to place it into the DOM and force a layout, which is much slower, particularly on mobile devices.
3. Iframes form a layout boundary, so when the browser lays out elements in them it stops the layout process at the iframe. This eliminates the need to do a CPU-intensive layout of the whole page when you pop in your XHR content.
The other two objections I'm not so clear on--maybe because I don't often dynamically construct views by retrieving "presentation" from the server. In what I've seen as "idiomatic HTML5 client-side development", all the views are shipped as templates with the initial code-blob that starts up the client; from then on, the client just speaks pure data-related JSON to the backend's plain HTML-unaware API. Does this practice not scale to Google levels? :)
As for sending JSON with rich clients vs. rendering HTML on the server; that depends a lot on the intended usage pattern of the app. For apps that you expect will be open for hours at a time, like e-mail or social networking, the former pattern is better - and indeed, GMail and G+ both speak JSON (well, a modified version that gives better latency) to rich client JS. For apps that you open quickly, perform your task, and then close (Search is the canonical example), it's far better to render all your HTML on the server and just ship that down to the browser. There is a large cost to downloading and executing all that JS, and you lose many, many customers if your app is slow.
There are strategic reasons why, if I were founding a startup today, I'd prefer to play in markets where the latter case held, unless I was writing enterprise software. Consumer markets where people spend hours with an app open are rare, and Google/Facebook generally want to own that space. I would rather not compete with them. On mobile, the open-for-hours apps are generally moving to native, where you can interact with the platform's notification API. The sweet spot for long-running webapps is enterprise and intranet applications, which has many fruitful markets, but many technologists shy away from it because there are frequently many arbitrary and difficult requirements.
Any more details on this (that you're allowed to talk about)? Low-latency JSON-alike communication is something I'd be highly interested in.
Personally, I've investigated BERT.js for this use-case, but it didn't work quite right (likely since the available client library was written to construct binary messages using String.charCodeAt, rather than just writing directly to an ArrayBuffer.) I kind of gave up when I realized I might be--especially on mobile--spending long enough on the pure-JS encoding/decoding processes (versus the browser's native JSON implementation) to lose any gains I'd get from the network. If you know otherwise, I'd like to hear about it.
https://news.ycombinator.com/item?id=6649195
One of my big surprises moving to Google was how much iframes are still used, but even beyond that is the very pragmatic approach of looking for exactly what a technology gives you and what it costs you in return. There's basically a 1:1 correspondence between the API of an iframe and the API of an XHR:
xhr.open = iframe.src
xhr.onreadystatechange = iframe.onload
xhr.response = iframe.contentDocument
Many devs don't like working with iframes because it doesn't fit their mental model of how a request should work (possibly because iframes were initially introduced with a visual extent), but that's a problem with their mental models, not with iframes. You can always wrap the API if you don't like it, anyway - pretty much all the major frameworks do, since raw XHRs are a bit clumsy to use.
Let’s say you decide one day you want to build a table. This table is going to be made using wood, nails and a hammer. All things being equal, let’s say you build this table with hammer A that has a utility of 10. You build a second table with hammer B and it has a utility of 15. You, the carpenter, have now created two tables, table A and table B, respective to their hammers. The tables are identical, but the utility is different. Now let’s say your utility as a carpenter is 5 (we’ll call this carpenter ‘ME’). The value of the tables is now: Table A – 50 and Table B – 75. Now, my carpenter friend (we’ll call this carpenter ’FR’) has a utility of 4 and he builds the same tables using the same respective hammers. He now has two tables at the following values: Table A – 40 and Table B – 60. So we can build a simple comparative matrix now. Table B built by FR has a higher utility than Table A built by ME but it was built by a less skilled carpenter! We therefore logically assume the hammer is the key driver for the overall utility, not because it has a higher multiplier, but because we believe we have better ability over assessing what the utility of the hammer is. We then therefore place much more importance on it.
http://www.techdisruptive.com/2012/06/29/the-cyclical-nature...
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?
That being said, Meteor simply has a lot more developer talent (and money) behind it. Hence it's improving at a much faster rate than Derby.
They do have this YouTube tutorial though, where they run through how they made the multiplayer story game:
http://www.youtube.com/watch?v=V0DOGXmaT3g
Code is on Github here:
https://github.com/codeparty/multiplayernotepad
Demo (currently unavailable):
https://stories.derbyjs.com