UPDATE: This was probably really stupid of me to do right now, but I've been wanting to change my GitHub name for awhile... and just did... so if anyone would like to checkout the repo you can find it now at https://github.com/kulte/ratchet-signup
I think it really comes down to a matter of preference. This looks interesting to me, and it caught my eye when I saw it on Hacker News much in the same way Meteor did when it came out. For me personally, it just passed the initial smell test really well.
In terms of some concrete attributes which I like, I think it probably is the best framework I've seen in terms of the general aesthetic. I have high hopes that it will allow me to create most of the view elements I'd need to prototype in an incredibly short period of time. I haven't used jQuery mobile for some time now (> 1 year) yet it seems like there are more CSS classes in Ratchet that mimic the iOS look and feel well enough that one could develop a full iOS app prototype in a day or less. If I remember correctly from using jQuery mobile, there was a bit more code to write, and the general look just didn't feel as good to me.
Thanks for mentioning Kendo, hadn't heard of it, just checked it out though... kinda pricey :) I think it's pretty awesome that someone developed a free, open-source mobile UI prototyping framework.
The awesomeness in my opinion is that a) this took me literally five minutes which means that I had to write absolutely none of my own CSS classes for mobile prototyping, the wonderful guys who developed Ratchet did that for me already! Also, Ratchet is not an MVC framework, it's a front-end iPhone targeted mobile prototyping framework. It allows you to prototype a mobile UI with HTML/CSS/JS faster than prototyping in native Objective-C. At first glance, I honestly think these guys are being humble by calling it a prototyping framework. I could see myself using this for mobile web versions of my apps, although that does presuppose that everything "works" pretty closely to the level one would expect it to reading the docs on their homepage. Check out the link I posted in another comment, you might be confusing Ratchet with something else.
If what you mean is there a CDN for the Ratchet javascript, I don't think so. If you go to the website http://maker.github.com/ratchet/ there is a download link, but my repo just augments what you get in the download folder... like I said, 5 minutes :)
EDIT: I see what you mean now, no I didn't put up a hosted link since I just developed the one screen during a 5 min break. That's a decent idea though, maybe I'll make a full demo application (maybe I'll make it a Todo list, no one has ever used that for a demo app before) and put it up on Heroku.
I also recommend for node Guillermo Rauch's Smashing Node.js. Also Javascript the Good Parts by Crockford is the cononical language resource for Javascript, once you've reached your inevitable local maximum in just having knowledge of node.js and not much Javascript per se.
I agree that having a job and doing a startup is not giving either of those things a fair chance at succeeding. But also if I had to add one thing, I'd say that most entrepreneurs simply give up too fast. This might have represented a true test against how badly you actually want to have your own business (non lifestyle business that is) and maybe your decision is the truest manifestation of your real desires, but I think that if you know that what you really want is to change the world with a "let's blow this out of the water" type of business, then less than 3 years is simply too soon to give up in my opinion.
A few observations. One, you haven't written that many pages, in fact you've written very, very few pages save for the preface and the like. This isn't an issue on its own, except theres no Table of Contents so it's hard for me to see where you are going to take it from here, or in other words what your vision is. The obvious result of this is that it's pretty hard to provide feedback. The flip side is of course, that you've demonstrated enough desire and initiative within yourself to endeavor to start the book, so unless you have a serious reason to stop, maybe forge ahead and try to finish what you started.
One other thing that I just want to put in your head, I'm not sure if I'm even going so far as to suggest it, is the possibility of flexing scope to write perhaps a 50 page e-book, not dissimilar to the Sacha Greif ebook (http://sachagreif.com/ebook/) but for getting from zero to the next book on Rails for absolute beginners. The benefit of this would be that you could probably spend about 20 hours writing it (I'm pulling this number out of my ass, so I could be waaay off about this time estimate) and therefore you've risked a much shorter amount of time, which I'm assuming is your main concern.
First off, let me state that I in no way wish to diminish the accomplishments of the authors of RailwayJS in making these comments. I think they've built an inevitable framework given that Rails was (and likely still is) the most popular open source web framework (at least as far as the HN/startup crowd goes) and of course why not give developers the same abstractions they have with their old favorite when a new thing comes along. But here's a constructive observation:
Node.js isn't a framework. AND it's not a programming language. Node is ostensibly a set of libraries and a runtime environment. I've been to a few Node meetups over the past few years, and inevitably people (not just newbies btw) will ask "what will be the Rails for Node?" But I think making this analogy is wrong. It's wrong for two main reasons, the first of which is that it implicitly compares Node.js to Ruby, which is a category mistake. More importantly though I'd argue, it's wrong because making the Rails for Node analogy deprives the developer (you!) of the opportunity to allow an emergent programming paradigm to change the way you think about programming! So how should Node do that? My fantasy for how Node.js will evolve in the next few years is that it will be a series of node packages which can be easily dropped in and out of my programs. I believe that the goal of the third-party node package development community should be to encourage this modularity, because I think it is the right abstraction for what Node.js actually is, and not necessarily what some people might wish it was. It's easy enough to set up EventMachine in Rails and then you can use your familiar stack, but I'd encourage anyone looking to use Node.js to fully embrace it and use it as an opportunity to explore new workflows, and not just try to fit your old stack into an event loop.
In the past few weeks, I don't know why, but I took a prominent note of how easy application development has become. The fact is that someone probably could learn how to write a web application in Ruby on Rails in three months without much hinderance. Production quality, probably not, but a REST API persisting to a database and implementing some business logic, absolutely.
It scares me a little (a really little) in that this trend is ostensibly a precursor, or leading indicator if you will, to the increasing commoditization of our profession. But here is the thing. There are steps that we can actively take to mitigate the complacency that recent technology has afforded to us. This is likely where I agree with the author the most. If your skill set is narrower than you wish it to be, engage problems in a different domain, and acquire the knowledge to do so beforehand. Meanwhile, if you're one of the people, like me, who feel beyond fortunate to wake up everyday doing something that you love, then continue to do that, stay hungry to learn new things all the time, and hope that that will be enough. That's pretty much all you can do.
An even quicker introduction to the final specification of WebSockets: http://socket.io.
P.S. I'm aware that a) this doesn't help anyone not using Node.js on their server (it's not even part of my production stack at work (yet!), even though I'm bringing it to light here) and b) it's more than just WebSockets, for instance it will gracefully degrade on legacy browsers.
I just can't miss an opportunity to sing its praises because it has so many benefits over the simple implementation.
I don't even think that was the point. I think the geographic comparison is more a novelty than anything, and I don't even think the author takes a viewpoint in writing his article. I clicked the link because I'm at an Excelerate Labs company now in Chicago, and I'm sure other Chicago Hacker News-ers will click on the link too, but I don't think there was really any point to the article. So un-succinctly put, I don't think you're missing anything.
As both a programmer and a poker player I have strong opinions on the subject. In turn:
"Math is useful
I see a lot of people around telling “I don’t need math”. In poker (and in programming) you need a lot of math, even for simple operations."
I think the importance of math is overstated in poker. When you look at a hand you must determine your chance of your hand improving, which is a straightforward mathematical exercise. You must also determine your opponents chances of improving his hand, which is also a straightforward mathematical exercise, but is complicated by the fact that you can't see the cards your opponent has. So once you have pegged your opponent for a certain hand based on his or her behavior earlier in the hand as well as any previous knowledge you have of the player, if applicable, then again straightforward math. Finally, professional/skilled poker players always calculate the odds the pot gives them versus the odds that either their hand will improve or the odds that in the specific situation they can expect to win the pot, and they further must consider what odds they are offerring to their opponent by their actions. Weighing those factors pretty much completes the degree to which mathematics plays a role in no-limit Texas Hold'em.
"Be fast and precise
In online poker you can’t think hours for your next move. If you are a programmer you should be fast-thinking and precise. Fast and no errors."
While this resonates much more for me in vis a vis poker, I think this is borderline idiotic in the sense of programming. In poker you must act fast because it is forced upon you in the context, you have no choice. Think of it like using Javascript before Douglas Crockford came along and enlightened you to the good parts of the language, the only reason to use it was because you had no choice! But in programming, to say that you have to be "fast and [make] no errors" is stupid insofar that it's an obvious goal of which stating serves no purpose. It's like when I tried to explain to a non-programmer friend of mine the concept introduced by Jason Fried of "getting good at making money". He thought it was the stupidest thing he'd ever heard, like as if someone saying "I'm going to work hard to improve my skill at making money" is going to in any way have a causal relationship with the actualization. I probably didn't do Jason justice in setting the right context for my friend, nevertheless I think this phrase exhibits the same logical fallacy.
"If you want to try poker there are a lot of free poker games on facebook, iPhone, etc… Don’t waste your money. The fun is the same."
You'll never get good if you're money is not on the line. Now, I'm not saying that one should get in over their head, or even wager large amounts of money, especially when learning to play poker. However, you will simply not see the real scenarios and wrestle with the real hands that make you a great poker player, unless you and your opponents are playing for money. My impression of free poker games is that they mimic televised poker. Televised poker is for entertainment, not education, so the hands that are shown are epic bluffs, balls-to-the-wall all-in wagers, and other 5%-ish hands that provide the greatest level of excitement to viewers. I'd do the same thing if I was a TV producer, but it's not real poker. My point in this tangent is to illustrate that 95% of winning and loosing in poker comes down to average-plus hands beating average-minus hands. And while no hands are trivial in poker, playing an average-x hand against an opponent who holds the counterpart is ridiculously challenging. You will not have the motivation to really wrestle to find the answer without your money on the line, and getting good at finding out how to induce small mistakes in your opponent is basically synonymous with becoming a good no-limit Texas Hold'em player.
And finally, a gaping omission in my mind:
Poker is great for programmers (and maybe more accurately entrepreneurs) because it is a game where the perfect amount of information is available such that a skilled player, in the long run, can expect to have a positive ROI when playing against players of lesser skill. No-limit Texas Hold'em in particular, is the epitome of this. At the height of its popularity when big no-limit tournaments were attracting deep-pocketed beginners, a skilled player could expect his tournament entry fee to be worth 5 to even 10x its value in terms of expected value each time. The concept of imperfect information is resonant in entrepreneurship I think for sure, and as for it's benefits with programmers, I believe the best way to think about it is that poker in beneficial because it ostensibly uses the same cognition as design patterns in software engineering. You have a problem to solve with a variety of factors, and you apply patterns to solve those problems based on your knowledge and the past experience of others who have blazed the trail before you.
Investors shouldn't like acqui-hires unless it is an agreed upon goal in the first place. In fact, I guess that investors wouldn't appreciate any misunderstanding of goals on any level, and it seems to be an oft-cited reason for entrepreneurs losing their jobs at the behest of venture capitalists. But if I had $1 million to invest into a business, and from my experience I had a reasonable expectation that a company I'm investing in could be acqui-hired for $50 million, and we agreed upon that from the outset, then I could see myself making that deal and being happy when the result came to fruition.
One observation. I posit that in certain situations, when from the outset a startup sets out to attract a microsegment which is the subset of an existing market that is owned by a major competitor, and furthermore has the explicit goal of being acquired for somewhere between $5 to $50 million by one of those major competitors, that this is valid. Being that in select situations this is a valid undertaking, it must follow from this that the actualization of this explicit goal represents success, and not failure, neither on the part of the founding team nor in terms of product development. Perhaps the dollar amount I cited here is what the OP would consider to be a "buy-out offer [that] is spectacular", but to the extent that it isn't, it's ostensibly wise to consider the opposing viewpoint.
If you made this as a 'Farmville' style game, I think if I called it 'Startupville' that name would convey ostensibly everything that I would like to see in a game like this, I guarantee you that you'd at least be able to monetize me through advertising. This might be out of scope for what you are suggesting though, but I'd definitely be interested in seeing it done. I've had this idea for a long time, but I always manage to convince myself that I'm just weird and that my tastes for games don't reflect an addressable market of who's size would make it worth my time.
The article starts of by saying that a lot is at stake when a company rolls out a new logo. I'd like to point out the Microsoft has, either intentionally or unintentionally, been piloting this logo-style in their products for the past few years, which is ostensibly a lower-risk proposition. Rolling out their parent brand logo to conform to this arguably successful re-branding that their individual software products have underwent over the past three or so years seems like a reasonably sound decision. Furthermore, if Microsoft has intentionally been piloting this new brand on parts of their business that are subordinate to the brand as a whole, then I'd have to say bravo for likely reducing a huge business risk in the making of a relatively permanent, long-term decision.
If you're just going to send plain HTML over the wire, why are you going to even bother thinking at the level of abstraction that most developers (well, at least me) tend to think of when "developing an API"? I'll give you that it's a loose notion, but there's another issue. If you're building a non-trivial web application, how does sending HTML as a media type help you to decouple your data from the DOM? I believe the answer is that it doesn't. You could make the argument that decoupling becomes less of a necessity when you are providing more "fine-grained" access by controlling exactly what HTML is generated from the server at each endpoint. I say it could be argued, but I wouldn't argue it.
I've done customer development on things along these lines and I basically have the following to share with the class:
Any app that is at its core assisting people to hack their current behavior is inherently asking people to change their behavior beyond that point at which it would be reasonable given the difficulty of such a task to attempt this feat.