I was neither a web beginner when Rails came out or a javascript beginner when I started working with Backbone, so your use of the word grok is ironically appropriate.
But to answer your question about why I was quicker to jump on board with a full-stack opinionated framework like Rails as opposed to equivalent JS frameworks. The reason is because there's a much larger common footprint of what a website needs to do than what javascript needs to do. Is it a single page app or a full site? How much JS code is there? Is it a lot of CRUD or is a more minimal crafted UI? Is it progressively enhanced or not? What other technologies are in the mix?
All of these affect the needs of a particular site's JS implementation, and even assuming that all JS framework authors are smarter and more knowledgeable than me (which is a dubious assumption btw), they may or may not have taken into account any of the conditions and constraints that are now staring me in the face.
As to leaving crappy legacy stuff behind, well, frameworks don't save you from that. For a simple app written by a beginner there's a good chance I'd prefer maintaining the 10-year-old PHP version to the 5-year-old Ruby version. But even assuming a framework is a good idea, how is the noob to know which one to use? You could just as easily end up with a dead-end Access database as something that can be coerced into stable software.
Comments
I was neither a web beginner when Rails came out or a javascript beginner when I started working with Backbone, so your use of the word grok is ironically appropriate.
But to answer your question about why I was quicker to jump on board with a full-stack opinionated framework like Rails as opposed to equivalent JS frameworks. The reason is because there's a much larger common footprint of what a website needs to do than what javascript needs to do. Is it a single page app or a full site? How much JS code is there? Is it a lot of CRUD or is a more minimal crafted UI? Is it progressively enhanced or not? What other technologies are in the mix?
All of these affect the needs of a particular site's JS implementation, and even assuming that all JS framework authors are smarter and more knowledgeable than me (which is a dubious assumption btw), they may or may not have taken into account any of the conditions and constraints that are now staring me in the face.
As to leaving crappy legacy stuff behind, well, frameworks don't save you from that. For a simple app written by a beginner there's a good chance I'd prefer maintaining the 10-year-old PHP version to the 5-year-old Ruby version. But even assuming a framework is a good idea, how is the noob to know which one to use? You could just as easily end up with a dead-end Access database as something that can be coerced into stable software.