6 ms·

Not using a JS Framework? Congratulations, you've just built your own ad hoc JS Framework. Suddenly, anyone who joins moot will have to invest tons of effort i

by sync 13y ago

Not using a JS Framework? Congratulations, you've just built your own ad hoc JS Framework. Suddenly, anyone who joins moot will have to invest tons of effort in your custom framework instead of being able to hit the ground running.

hadem 13y ago
Whereas had they decided to use Backbone or AngularJS I wouldn't have to invest tons of effort...? Regardless of framework (or lack there of), effort will be needed for those utilizing the API.
mattgreenrocks 13y ago
This sentiment, expressed collectively, commoditizes the entire profession. How can you expect to ask for raises if all devs are basically interchangeable? If we've eradicated all notions of design, and follow prescriptive rules of structuring and solving problems that anybody can Google and follow, then what avenues are left to express technical ability? What differentiates you?
- aaronem 13y ago
  Calmly, Chicken Little, calmly! Perhaps the sky is not falling after all...
  - mattgreenrocks 13y ago
    Nope, it isn't. But clinging to frameworks in lieu of actual program design can hamper your ability to design something that doesn't fit neatly into a predefined box.
    - aaronem 13y ago
      Of course. But no one seems to be suggesting otherwise, that I can see, and for the relatively common case in which one needs quickly to prototype and roll out something which does "fit neatly into a predefined box", a framework is often just the thing.
      - Zelphyr 13y ago
        You touch on the one things that frameworks are actually good for: prototyping. Unfortunately they're never just used for that purpose. The prototype and all the framework cruft is then called "the product" and used as such. And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together.
        scarecrowbob 13y ago
        "And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together." Is it possible that some of us have an idea about what we're doing, but have to do enough different projects that learning a common framework has enough of a benefit to outweigh writing bespoke code for everything? I don't feel the need to write a whole language for every problem I need to solve, and I don't generally think of the language functions I don't use on a given project as "cruft".
        Zelphyr 13y ago
        Who said anything about writing a whole language? Just know the language you're writing in well enough that you can build something better without a framework than you can with.
        aaronem 13y ago
        Well, sure. When I need something like URL routing, or object-relational mapping, or templating, why not reinvent it from scratch every time? Or, failing that, why not handle things like that with a collection of favorite libraries, each of which has its own calling conventions, its own requirements, and its own attitude toward the world? Reconciling all those differences certainly won't take a significant amount of time, and I'm always happy to spend my efforts on tooling instead of on whatever project inspired the need for tooling in the first place. More seriously, I can understand where you might be coming from with the implication that frameworks are a crutch for developers who don't bother to learn, or aren't capable of learning, the language in which the framework is implemented; I've had to clean up the wreckage left behind by Ruby on Rails hacks, too. But what's important to keep in mind is that the Rails dev community is extremely atypical in its extremely low average level of basic programming capability, and the Rails framework is likewise anomalous in the degree to which it forgives such incompetence. These traits, I stress, are not common to frameworks in general or to the developers who employ them, and consequently it is very much a mistake to use the Rails ghetto as a basis for extrapolation to more or less anything else. It's your mistake to make, of course, and if you insist upon it, then I won't go to any further effort on your behalf. But you can't say no one tried to warn you.
    - chongli 13y ago
      Frameworks tend to arise in languages with poor composability. Composable languages favour large numbers of small libraries which can be mixed and matched in many creative ways. Composability favours design.
- cliffbean 13y ago
  This sentiment, expressed collectively and somewhat unsympathetically, portrays the entire profession as prioritizing job security over true excellence.
  - mattgreenrocks 13y ago
    Indeed. But excellence should mean using the right design for a program, not the Good Enough one advocated by today's fashionable framework. I'm more concerned about collective effects (such as negating the need for analysis and design). This is yet another instance of Worse is Better.
    - mooreds 13y ago
      What is worse? What is better? Often shipping something that is 'Good Enough' is better than getting the 'right' (perfect?) design for a program. In the post, it is clear that moot has a set of concerns that a typical business software developer doesn't have. So, pick the right tool for your business situation, which may include a framework, or not. But I have to say, as a developer, the times when I thought I had to start from scratch and been right were far fewer than the times I wanted to start from scratch and been wrong. That may be a testament to my skill, the problems I work on, or both.
  - chongli 13y ago
    Or one could say that it reveals the fatal flaw in our current system of capitalism: Automation is desirable because it increases efficiency and lowers costs. Automation is undesirable because it eliminates jobs and automatons are not consumers.
    - vidarh 13y ago
      That was Marx main argument for the inevitability of a socialist revolution: That capitalism will eventually become efficient enough to on one hand create enough goods to make it possible to totally eradicate poverty, but on the other hand become efficient enough to substantially reduce employment.
- pedalpete 13y ago
  I find the difference to be that each developer is now more productive and can add more function in less time. The profession isn't commoditized, the lower end of the profession gets better, and those with the skills move up a notch and do more and more challenging things. I used to build single-page javascript apps in pure javascript (pre-jQuery), and it was a pain. Once jQuery came along, things were easier. I actually don't think I'd have too much trouble going back and using just jQuery, but I don't think I'd be as productive as I am with backbone, angular or knockout.
  - mattgreenrocks 13y ago
    I want to believe you, but I also see that a significant portion of the industry is still on CRUD, and people still get really excited about CRUD frameworks.
    - porker 13y ago
      And yet I haven't seen a convincing web CRUD framework. Have you? I never did desktop development so don't know about there, but some must have been good.
      - wtracy 13y ago
        Isn't that basically what Rails and Django are? Or are you asking for something client-side?
    - pedalpete 13y ago
      I don't know why you were downvoted. I (think) I agree with you. I'm assuming you mean they are on CRUD as in most projects are what I call 'simple I/O'. Data goes into a database, data comes out of a database, and the job of the developer is just to make that happen. For the most part, that is true, but I don't think you can blame that on the 'industry', that's the 'market'. The majority of the market didn't/doesn't need anything more than that. However, if you have the skills, there are lots of jobs out there in data-analytics, robotics, etc. etc. (depending on where you are) that probably wouldn't have been available if we were ALL neck deep building every CRUD app from scratch. The frameworks make average people right faster and better code. Hell, they help me write better and faster code. I'm no coding genius, but I've built apps in rails, and it is faster than when I was building everything by hand in PHP. I haven't been doing much CRUD lately, seems like Front-End has taken the majority of my time in the last few years, but that's part of the 'craft' of being a developer. I actually find front-end more challenging and rewarding than CRUD (these days) simply because frameworks have made CRUD so easy.
- SkyMarshal 13y ago
  It doesn't commoditize the entire profession, only the 50% of it that is common to every web site or app you ever build. The other 50% is where the artistic license, craftsmanship, business sense, empiricism, and other value-adds of your team comes in.
- al2o3cr 13y ago
  "then what avenues are left to express technical ability" I dunno, maybe actually solving problems for clients instead of playing endless rounds of "my JS is smaller than yours"?
  - mattgreenrocks 13y ago
    This is not about code golf, this is about the widespread automatic use of frameworks in lieu of an analysis/design/build-one-to-throw-away phase.
Chris_Newton 13y ago
Congratulations, you've just built your own ad hoc JS Framework. We used to call that part of software development “design”, and learning basic design skills and becoming familiar with the common strategies and techniques were prerequisites for being a useful developer. Perhaps losing that baseline is an unfortunate side effect of having readily available black box code to do many common jobs in the Internet age and being able to get moderately good results just by joining up those boxes. I don’t think this is a good thing, though. The idea that learning to find your way around a design when you start working on a new project might be considered difficult and not just something everyone routinely does is not a happy one.
- SkyMarshal 13y ago
  In my experience, using a framework and learning design aren't mutually exclusive. Learning a framework often requires studying its source code and grokking how it works, there's simply no better documentation. Granted that may not be quite at the level of designing your own complete framework from scratch, but imho it's the happiest middle ground between personal skill development and standing on the shoulders of giants that FOSS has enabled.
mrottenkolber 13y ago
I don't use any 3rd party code for my current work as of now. So yes I have built my own "toolkit". Maybe a vector rendering library wil be required at some point, but I started off on bare bones to see how far you get. It's not that I am generally against 3rd party code, JavaScript is just a bit special in that case. The quality of JavaScript libraries is just so outright bad that I don't have any use for most of them. I have a personal policy to only include code that satisfies my personal quality standards, if a codebase makes me cringe I will not use it but rather write my own.
codingdave 13y ago
Every non-trivial app will add enough custom code to a framework that new developers have a learning curve.
coldtea 13y ago
>Not using a JS Framework? Congratulations, you've just built your own ad hoc JS Framework. Suddenly, anyone who joins moot will have to invest tons of effort in your custom framework instead of being able to hit the ground running. That's the framework party line. Not necesarilly true. For one, somebody not familiar with, say, Angular would still have to get to know Angular (a huge task in itself) and then your application code too. Why not just have them understand the application code only? Since it's tailored to your application it also omits needless features and workarounds for framework issues.
- jdewald 13y ago
  I've never seen a non-trivial application that is "application code only". Most frameworks weren't built out of thin air, but because of real application needs. Sure they have more than is necessary, but it is often the case in any non-trivial application that you end up writing a bunch of custom common "framework" code which duplicates the work that readily available frameworks (that you avoided using) had. Any new developers then have to learn your new "lightweight templating language", "lightweight database mapper", "lightweight MVC layer", and what have you (which now you have to support even though it's not core to what your application does, but is just a support layer). Though I guess the best part is most of these frameworks being discussed came about because an internal team wasn't happy with what was available and decided to roll their own, which eventually became big enough to release as a standalone unit.
  - coldtea 13y ago
    >Sure they have more than is necessary, but it is often the case in any non-trivial application that you end up writing a bunch of custom common "framework" code which duplicates the work that readily available frameworks (that you avoided using) had. There are trivial apps (no need of framework, small enough), medium apps (can use a framework maybe) and serious non-trivial large apps, apps you bet your company on. The latter are often better to NOT base into a framework. If they do anything novel, and they want to do, they'd hit framework limits. The framework will impose its logic upon your code, whether it fits or not, and you'll have all the baggage of assorted layers it offers you'll feel obliged to use. >Any new developers then have to learn your new "lightweight templating language", "lightweight database mapper", "lightweight MVC layer", and what have you That's totally orthogonal. That you don't use a framework, doesn't mean you can handpick any of the popular template language libs, database mapper libs etc. Instead of being constrained by the set the framework authors chose. That is: libs, instead of frameworks. >Though I guess the best part is most of these frameworks being discussed came about because an internal team wasn't happy with what was available and decided to roll their own, which eventually became big enough to release as a standalone unit. That's not ironic in the slightest though. It reinforces what I said: since those teams evaluated whats available and they didn't fit their needs and rolled their one to solve their particular problems they way they want to solve them, what makes third companies think those "hand-rolled" frameworks are a good fit for THEIR needs? The message to take away, when a company rolls her own framework is not "frameworks are good, I should use theirs", but "they saw it fit to roll their own stuff. Perhaps I should too". After all, if you're a startup your competitive advantage is your code. You shouldn't constrain it to fit anything external. Now, if you are a consultant or web designer delivering cookie cutter projects for a company, or an enterprise developer doing some CRUD, by all means use a framework. Especially if you aren't doing anything very creative or original in the first place.
twerquie 13y ago
What if, instead of needing a framework, we just wrote tiny modules of functionality and composed them into an application? This is how the nodejs guys are doing this via npm and I must say, it's staggering. The core node "framework" has a tiny API, and the heart of it is simply require().
- frik 13y ago
  Yes exactly! Modules like in Node.js or libraries as in PHP are a lot more flexible and IMHO better than frameworks. I coded single page HTML5 apps in JS and Node.js/PHP and avoided any frameworks. A few helper functions are enough and I got a codebase that is easy to read, refactore and the overall code size is small and the execution is fast.
- ianstormtaylor 13y ago
  Exactly. If this kind of thing seems like your cup of tea check out component[1]. [1]: https://github.com/component/component https://github.com/component/component
- ben_mcmahen 13y ago
  This, entirely. You can effectively construct your own framework by combining other pre-established routers, models, and views (plus whatever other modules you might want). You still get many of the benefits of using frameworks (testing, docs), but it's much more flexible and has the potential to be leaner. You still need to establish best practices and a relatively consistent application design, but these are things you'd want to do anyway... even if using Backbone, or whatevs.
rfnslyr 13y ago
It's SO much effort to spend a weekend studying a code base and playing with it. Get over yourself.
jonny_eh 13y ago
On top of that, their new knowledge of said framework is not transferrable to their next job. If someone works on a popular framework, it makes it easier to get the next job.

by sync 13y ago

hadem 13y ago

Whereas had they decided to use Backbone or AngularJS I wouldn't have to invest tons of effort...? Regardless of framework (or lack there of), effort will be needed for those utilizing the API.

mattgreenrocks 13y ago

This sentiment, expressed collectively, commoditizes the entire profession. How can you expect to ask for raises if all devs are basically interchangeable? If we've eradicated all notions of design, and follow prescriptive rules of structuring and solving problems that anybody can Google and follow, then what avenues are left to express technical ability? What differentiates you?

aaronem 13y ago
Calmly, Chicken Little, calmly! Perhaps the sky is not falling after all...
- mattgreenrocks 13y ago
  Nope, it isn't. But clinging to frameworks in lieu of actual program design can hamper your ability to design something that doesn't fit neatly into a predefined box.
  - aaronem 13y ago
    Of course. But no one seems to be suggesting otherwise, that I can see, and for the relatively common case in which one needs quickly to prototype and roll out something which does "fit neatly into a predefined box", a framework is often just the thing.
    - Zelphyr 13y ago
      You touch on the one things that frameworks are actually good for: prototyping. Unfortunately they're never just used for that purpose. The prototype and all the framework cruft is then called "the product" and used as such. And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together.
      - scarecrowbob 13y ago
        "And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together." Is it possible that some of us have an idea about what we're doing, but have to do enough different projects that learning a common framework has enough of a benefit to outweigh writing bespoke code for everything? I don't feel the need to write a whole language for every problem I need to solve, and I don't generally think of the language functions I don't use on a given project as "cruft".
        Zelphyr 13y ago
        Who said anything about writing a whole language? Just know the language you're writing in well enough that you can build something better without a framework than you can with.
        aaronem 13y ago
        Well, sure. When I need something like URL routing, or object-relational mapping, or templating, why not reinvent it from scratch every time? Or, failing that, why not handle things like that with a collection of favorite libraries, each of which has its own calling conventions, its own requirements, and its own attitude toward the world? Reconciling all those differences certainly won't take a significant amount of time, and I'm always happy to spend my efforts on tooling instead of on whatever project inspired the need for tooling in the first place. More seriously, I can understand where you might be coming from with the implication that frameworks are a crutch for developers who don't bother to learn, or aren't capable of learning, the language in which the framework is implemented; I've had to clean up the wreckage left behind by Ruby on Rails hacks, too. But what's important to keep in mind is that the Rails dev community is extremely atypical in its extremely low average level of basic programming capability, and the Rails framework is likewise anomalous in the degree to which it forgives such incompetence. These traits, I stress, are not common to frameworks in general or to the developers who employ them, and consequently it is very much a mistake to use the Rails ghetto as a basis for extrapolation to more or less anything else. It's your mistake to make, of course, and if you insist upon it, then I won't go to any further effort on your behalf. But you can't say no one tried to warn you.
  - chongli 13y ago
    Frameworks tend to arise in languages with poor composability. Composable languages favour large numbers of small libraries which can be mixed and matched in many creative ways. Composability favours design.
cliffbean 13y ago
This sentiment, expressed collectively and somewhat unsympathetically, portrays the entire profession as prioritizing job security over true excellence.
- mattgreenrocks 13y ago
  Indeed. But excellence should mean using the right design for a program, not the Good Enough one advocated by today's fashionable framework. I'm more concerned about collective effects (such as negating the need for analysis and design). This is yet another instance of Worse is Better.
  - mooreds 13y ago
    What is worse? What is better? Often shipping something that is 'Good Enough' is better than getting the 'right' (perfect?) design for a program. In the post, it is clear that moot has a set of concerns that a typical business software developer doesn't have. So, pick the right tool for your business situation, which may include a framework, or not. But I have to say, as a developer, the times when I thought I had to start from scratch and been right were far fewer than the times I wanted to start from scratch and been wrong. That may be a testament to my skill, the problems I work on, or both.
- chongli 13y ago
  Or one could say that it reveals the fatal flaw in our current system of capitalism: Automation is desirable because it increases efficiency and lowers costs. Automation is undesirable because it eliminates jobs and automatons are not consumers.
  - vidarh 13y ago
    That was Marx main argument for the inevitability of a socialist revolution: That capitalism will eventually become efficient enough to on one hand create enough goods to make it possible to totally eradicate poverty, but on the other hand become efficient enough to substantially reduce employment.
pedalpete 13y ago
I find the difference to be that each developer is now more productive and can add more function in less time. The profession isn't commoditized, the lower end of the profession gets better, and those with the skills move up a notch and do more and more challenging things. I used to build single-page javascript apps in pure javascript (pre-jQuery), and it was a pain. Once jQuery came along, things were easier. I actually don't think I'd have too much trouble going back and using just jQuery, but I don't think I'd be as productive as I am with backbone, angular or knockout.
- mattgreenrocks 13y ago
  I want to believe you, but I also see that a significant portion of the industry is still on CRUD, and people still get really excited about CRUD frameworks.
  - porker 13y ago
    And yet I haven't seen a convincing web CRUD framework. Have you? I never did desktop development so don't know about there, but some must have been good.
    - wtracy 13y ago
      Isn't that basically what Rails and Django are? Or are you asking for something client-side?
  - pedalpete 13y ago
    I don't know why you were downvoted. I (think) I agree with you. I'm assuming you mean they are on CRUD as in most projects are what I call 'simple I/O'. Data goes into a database, data comes out of a database, and the job of the developer is just to make that happen. For the most part, that is true, but I don't think you can blame that on the 'industry', that's the 'market'. The majority of the market didn't/doesn't need anything more than that. However, if you have the skills, there are lots of jobs out there in data-analytics, robotics, etc. etc. (depending on where you are) that probably wouldn't have been available if we were ALL neck deep building every CRUD app from scratch. The frameworks make average people right faster and better code. Hell, they help me write better and faster code. I'm no coding genius, but I've built apps in rails, and it is faster than when I was building everything by hand in PHP. I haven't been doing much CRUD lately, seems like Front-End has taken the majority of my time in the last few years, but that's part of the 'craft' of being a developer. I actually find front-end more challenging and rewarding than CRUD (these days) simply because frameworks have made CRUD so easy.
SkyMarshal 13y ago
It doesn't commoditize the entire profession, only the 50% of it that is common to every web site or app you ever build. The other 50% is where the artistic license, craftsmanship, business sense, empiricism, and other value-adds of your team comes in.
al2o3cr 13y ago
"then what avenues are left to express technical ability" I dunno, maybe actually solving problems for clients instead of playing endless rounds of "my JS is smaller than yours"?
- mattgreenrocks 13y ago
  This is not about code golf, this is about the widespread automatic use of frameworks in lieu of an analysis/design/build-one-to-throw-away phase.

Chris_Newton 13y ago

Congratulations, you've just built your own ad hoc JS Framework. We used to call that part of software development “design”, and learning basic design skills and becoming familiar with the common strategies and techniques were prerequisites for being a useful developer. Perhaps losing that baseline is an unfortunate side effect of having readily available black box code to do many common jobs in the Internet age and being able to get moderately good results just by joining up those boxes. I don’t think this is a good thing, though. The idea that learning to find your way around a design when you start working on a new project might be considered difficult and not just something everyone routinely does is not a happy one.

SkyMarshal 13y ago
In my experience, using a framework and learning design aren't mutually exclusive. Learning a framework often requires studying its source code and grokking how it works, there's simply no better documentation. Granted that may not be quite at the level of designing your own complete framework from scratch, but imho it's the happiest middle ground between personal skill development and standing on the shoulders of giants that FOSS has enabled.

mrottenkolber 13y ago

I don't use any 3rd party code for my current work as of now. So yes I have built my own "toolkit". Maybe a vector rendering library wil be required at some point, but I started off on bare bones to see how far you get. It's not that I am generally against 3rd party code, JavaScript is just a bit special in that case. The quality of JavaScript libraries is just so outright bad that I don't have any use for most of them. I have a personal policy to only include code that satisfies my personal quality standards, if a codebase makes me cringe I will not use it but rather write my own.

codingdave 13y ago

Every non-trivial app will add enough custom code to a framework that new developers have a learning curve.

coldtea 13y ago

>Not using a JS Framework? Congratulations, you've just built your own ad hoc JS Framework. Suddenly, anyone who joins moot will have to invest tons of effort in your custom framework instead of being able to hit the ground running. That's the framework party line. Not necesarilly true. For one, somebody not familiar with, say, Angular would still have to get to know Angular (a huge task in itself) and then your application code too. Why not just have them understand the application code only? Since it's tailored to your application it also omits needless features and workarounds for framework issues.

jdewald 13y ago
I've never seen a non-trivial application that is "application code only". Most frameworks weren't built out of thin air, but because of real application needs. Sure they have more than is necessary, but it is often the case in any non-trivial application that you end up writing a bunch of custom common "framework" code which duplicates the work that readily available frameworks (that you avoided using) had. Any new developers then have to learn your new "lightweight templating language", "lightweight database mapper", "lightweight MVC layer", and what have you (which now you have to support even though it's not core to what your application does, but is just a support layer). Though I guess the best part is most of these frameworks being discussed came about because an internal team wasn't happy with what was available and decided to roll their own, which eventually became big enough to release as a standalone unit.
- coldtea 13y ago
  >Sure they have more than is necessary, but it is often the case in any non-trivial application that you end up writing a bunch of custom common "framework" code which duplicates the work that readily available frameworks (that you avoided using) had. There are trivial apps (no need of framework, small enough), medium apps (can use a framework maybe) and serious non-trivial large apps, apps you bet your company on. The latter are often better to NOT base into a framework. If they do anything novel, and they want to do, they'd hit framework limits. The framework will impose its logic upon your code, whether it fits or not, and you'll have all the baggage of assorted layers it offers you'll feel obliged to use. >Any new developers then have to learn your new "lightweight templating language", "lightweight database mapper", "lightweight MVC layer", and what have you That's totally orthogonal. That you don't use a framework, doesn't mean you can handpick any of the popular template language libs, database mapper libs etc. Instead of being constrained by the set the framework authors chose. That is: libs, instead of frameworks. >Though I guess the best part is most of these frameworks being discussed came about because an internal team wasn't happy with what was available and decided to roll their own, which eventually became big enough to release as a standalone unit. That's not ironic in the slightest though. It reinforces what I said: since those teams evaluated whats available and they didn't fit their needs and rolled their one to solve their particular problems they way they want to solve them, what makes third companies think those "hand-rolled" frameworks are a good fit for THEIR needs? The message to take away, when a company rolls her own framework is not "frameworks are good, I should use theirs", but "they saw it fit to roll their own stuff. Perhaps I should too". After all, if you're a startup your competitive advantage is your code. You shouldn't constrain it to fit anything external. Now, if you are a consultant or web designer delivering cookie cutter projects for a company, or an enterprise developer doing some CRUD, by all means use a framework. Especially if you aren't doing anything very creative or original in the first place.

twerquie 13y ago

What if, instead of needing a framework, we just wrote tiny modules of functionality and composed them into an application? This is how the nodejs guys are doing this via npm and I must say, it's staggering. The core node "framework" has a tiny API, and the heart of it is simply require().

frik 13y ago
Yes exactly! Modules like in Node.js or libraries as in PHP are a lot more flexible and IMHO better than frameworks. I coded single page HTML5 apps in JS and Node.js/PHP and avoided any frameworks. A few helper functions are enough and I got a codebase that is easy to read, refactore and the overall code size is small and the execution is fast.
ianstormtaylor 13y ago
Exactly. If this kind of thing seems like your cup of tea check out component[1]. [1]: https://github.com/component/component https://github.com/component/component
ben_mcmahen 13y ago
This, entirely. You can effectively construct your own framework by combining other pre-established routers, models, and views (plus whatever other modules you might want). You still get many of the benefits of using frameworks (testing, docs), but it's much more flexible and has the potential to be leaner. You still need to establish best practices and a relatively consistent application design, but these are things you'd want to do anyway... even if using Backbone, or whatevs.

rfnslyr 13y ago

It's SO much effort to spend a weekend studying a code base and playing with it. Get over yourself.

jonny_eh 13y ago

On top of that, their new knowledge of said framework is not transferrable to their next job. If someone works on a popular framework, it makes it easier to get the next job.