Tom indirectly calls Thomas Fuchs (author of Scriptaculous, Zepto, Emile, core committer to Prototype.js, etc.) disingenuous because...
"Of course Mr. Fuchs is able to tell you which JavaScript library will precisely match your requirements -- his job is writing JavaScript libraries!" [Emphasis, and presumed outrage, his.]
Come now. That's simply false, and if you think about it, silly. "He writes open source frameworks for free so he's biased against open source frameworks"? Really? Thomas has never sold a JavaScript framework or written one for hire, and his libraries are MIT-licensed. It's not his "job". Furthermore, Prototype.js and Scriptaculous are not micro-frameworks. So Thomas Fuchs is arguing against major examples of his own work. Yup, must be some kind of evil hidden agenda.
I called Tom out about this misrepresentation on Twitter and he probably changed it by now, but I for one think it's important to know about the history of such things.
Other nitpicks:
Mr. Fuchs has apparently never heard of dependency hell. Very logical argument, that. Way to slyly insinuate he's a bad and inexperienced programmer, without actually introducing any actual facts.
Dustin Diaz has done a great job of putting together many of these micro-frameworks with Ender.js, but as a curator, he has to rely on the original author if he wants to make a change.
Really? How is that a counter-argument?
I'd be very surprised if someone has read Thomas' little essay on micro-frameworks and genuinely come away with the idea that what he really supports is taking a bunch of other people's OSS projects and mushing them together with an integration layer.
The whole point about micro-frameworks is you don't have to make them "go together". You wield them individually like scalpels instead of spinning them en masse like Edward Scissorhands.
There are a LOT of problems with an undertaking like Ender.js, but that's not the fault of micro-frameworks "not being made to work together." It's the fault of doing something that, from the outset, is fairly expected to be more trouble than it's worth - however noble it may be.
One might argue that an integration layer that hooks up a bunch of other micro-frameworks is no better than -- and in a lot of ways, worse, and more complex, and less reliable -- than a monolithic library. So I call "red herring" on the Ender.js argument. It doesn't really support Tom's attack on Thomas' article against monolithic frameworks, because it is one... just made from parts, like Frankenstein.
I could go on, but I'm even boring myself at this point.
What I'd like to know is: Why is the suggestion "You don't need all that code all the time" considered so radical & threatening?
--
And yup, full disclosure: I married Thomas Fuchs, but I used Prototype & Scriptaculous for well over a year before I ever met him.
I have tremendous respect for both you and Thomas and I'm sorry if the anything in my post came off as disrespectful. My point in saying that his "job" was writing JavaScript frameworks (which I have since updated to better characterize his relationship to them) was not that there was anything untoward going on. My point is simply that he is comfortable making the tweaks and modifications necessary to wield the power of multiple disparate libraries. Quite simply, he is a JavaScript hacker of the first order and is more comfortable taking on that job himself than at least 80% of JavaScript developers out there.
I felt like I had to write this post when I read this:
A whopping 100% of sites or apps using these libraries don’t use all the features they provide.
I have been talking to many, many developers who started with a "simple" app that became very popular and soon exceeded its original scope. To deal with this increase in complexity, they start building many of the features not available in microframeworks, but that come standard with so-called "monolithic" frameworks. My point is that many people need that level of sophistication, but there is a widespread misconception that, for whatever reason, picking a "monolithic" tool is never the right choice.
The suggestion that "You don't need all that code all the time" is not the problem. The insinuation in the JS community seems to be "You never need all that code," which I believe to be false.
Again, no outrage on my part. I just think that we need to address the reality of how modern web apps are built.
Hi Tom, it's hard to believe your snarky-sounding italics were intended innocently when you also had such lines as "Mr. Fuchs has apparently never heard of dependency hell." That is clearly meant as a personal jab, one way or another.
That said, it's true what you wrote, that lots of apps grow bigger and need more functionality as they grow. But "need more" is not the same as "use 100% of a library," so that doesn't really refute Thomas' original argument.
You're reacting negatively to insinuations and attitudes that, as far as I can tell, don't exist on a broad scale at all. Most people you meet in the JS community use frameworks and are clearly not anti-framework. It seems to me (based on the tweets from you and @wycats) that you think this whole thing is about Sproutcore. It's not.
Thomas wasn't "insinuating" anything about Sproutcore any more than he was "insinuating" anything about Prototype.js, another monolithic framework.
Mostly agreed, and well articulated. Though, the point I believe that Tom was trying to make about Diaz having to ask Thomas to change things was more valid with the links that were likely stripped from your comment:
While you already argue against something like ender.js being valid, Tom's argument, which preceded your comment (and which seemed confirmed by Thomas' post, imo), was that including emile in Ender.js has actually been a pain because he couldn't get Thomas to answer him, let alone change something for him. I believe the irony that was being pointed out was that Thomas then gave ender a shout-out after ignoring it (from an outside and likely wrong perspective).
I say all of this in more of a objective bystander, rather than someone who wants to interject his own opinion on the actual topic. I don't need that kind of stress.
Full disclosure: I found myself quite attracted to Thomas the few times I met him. I think it's the accent.
The point is that Emile is 50 lines of code and can be wrapped up for any purpose in about 2 minutes (export to some object).
Dustin wanted a different API to call upon, so he had to change some stuff, again relatively easy, because it basically fits on a screen in a text editor.
Let's not forget, all of this is open source, and it's meant for adaptation, forking and to be built upon. (Note that Emile was very much a proof-of-concept, with no emphasis on beatuiful, reusable code; it was written as a teaching tool for a talk on CSS animation I gave two years ago at Fronteers.)
I agree, but I think the point of Tom originally linking it was to show that Dustin had integrated a micro-framework (from you), and couldn't get a response from you (even to say the stuff you mention above) and eventually closed the ticket.
It's not my own commentary, though. I was just clarifying to Amy why the argument that seemed entirely unrelated was at least tangentially related. Personally, I would have just modified it and went on my way :D
Actually Dustin's pull request is a bad example entirely. He wanted to change the whole API of emile. He liked the functionality but it didn't work for how he wanted to integrate it into ender. If an API doesn't work for you, you're kind of screwed, whatever library you're using. You either hack it yourself or you ask the maintainer. If some API of SproutCore wasn't to your liking, then what?
Dustin could've written an adapter around emile to expose the api he wanted to for ender. But that would defeat the purpose of ender which is to cleanly integrate several great micro frameworks. He didn't have to wait for Thomas. He wanted to explicitly. It was a goal of his to keep the dependencies pure.
Dependency hell is a problem with integrating several different frameworks. But I'm not sure this is the best illustration of that.
Slexy, I didn't know about this. Because 5 days ago, I was too sick to do anything but lie on the sofa and moan, and Thomas was taking care of me while holding down the business all by himself. It's unfortunate that Dustin assumed that not hearing from Thomas in just a few days meant that Thomas was angry, ignoring him, or whatever.
But nevertheless, Emile's not only open source, it's MIT-licensed. Dustin can do whatever he wants with it, any time!
Unrelated to the OP, but related to this: I get that it's real life, and people forget that all the time on the internet. You should start feeling better soon. Forealz. I demand it. CFS sounds terrible and we're all rooting for you to figure out a real solution despite shitty doctor luck. Many <3z.
I don't know enough to contribute to this debate, but I found the tone of your comment more distracting than that of the article. (I come from the 'less code is better' camp in lisp http://github.com/akkartik/wart, so I have no axe to grind.)
Comments
Tom indirectly calls Thomas Fuchs (author of Scriptaculous, Zepto, Emile, core committer to Prototype.js, etc.) disingenuous because...
"Of course Mr. Fuchs is able to tell you which JavaScript library will precisely match your requirements -- his job is writing JavaScript libraries!" [Emphasis, and presumed outrage, his.]
Come now. That's simply false, and if you think about it, silly. "He writes open source frameworks for free so he's biased against open source frameworks"? Really? Thomas has never sold a JavaScript framework or written one for hire, and his libraries are MIT-licensed. It's not his "job". Furthermore, Prototype.js and Scriptaculous are not micro-frameworks. So Thomas Fuchs is arguing against major examples of his own work. Yup, must be some kind of evil hidden agenda.
I called Tom out about this misrepresentation on Twitter and he probably changed it by now, but I for one think it's important to know about the history of such things.
Other nitpicks:
Mr. Fuchs has apparently never heard of dependency hell. Very logical argument, that. Way to slyly insinuate he's a bad and inexperienced programmer, without actually introducing any actual facts.
Dustin Diaz has done a great job of putting together many of these micro-frameworks with Ender.js, but as a curator, he has to rely on the original author if he wants to make a change.
Really? How is that a counter-argument?
I'd be very surprised if someone has read Thomas' little essay on micro-frameworks and genuinely come away with the idea that what he really supports is taking a bunch of other people's OSS projects and mushing them together with an integration layer.
The whole point about micro-frameworks is you don't have to make them "go together". You wield them individually like scalpels instead of spinning them en masse like Edward Scissorhands.
There are a LOT of problems with an undertaking like Ender.js, but that's not the fault of micro-frameworks "not being made to work together." It's the fault of doing something that, from the outset, is fairly expected to be more trouble than it's worth - however noble it may be.
One might argue that an integration layer that hooks up a bunch of other micro-frameworks is no better than -- and in a lot of ways, worse, and more complex, and less reliable -- than a monolithic library. So I call "red herring" on the Ender.js argument. It doesn't really support Tom's attack on Thomas' article against monolithic frameworks, because it is one... just made from parts, like Frankenstein.
I could go on, but I'm even boring myself at this point.
What I'd like to know is: Why is the suggestion "You don't need all that code all the time" considered so radical & threatening?
--
And yup, full disclosure: I married Thomas Fuchs, but I used Prototype & Scriptaculous for well over a year before I ever met him.
Hi Amy,
I have tremendous respect for both you and Thomas and I'm sorry if the anything in my post came off as disrespectful. My point in saying that his "job" was writing JavaScript frameworks (which I have since updated to better characterize his relationship to them) was not that there was anything untoward going on. My point is simply that he is comfortable making the tweaks and modifications necessary to wield the power of multiple disparate libraries. Quite simply, he is a JavaScript hacker of the first order and is more comfortable taking on that job himself than at least 80% of JavaScript developers out there.
I felt like I had to write this post when I read this:
A whopping 100% of sites or apps using these libraries don’t use all the features they provide.
I have been talking to many, many developers who started with a "simple" app that became very popular and soon exceeded its original scope. To deal with this increase in complexity, they start building many of the features not available in microframeworks, but that come standard with so-called "monolithic" frameworks. My point is that many people need that level of sophistication, but there is a widespread misconception that, for whatever reason, picking a "monolithic" tool is never the right choice.
The suggestion that "You don't need all that code all the time" is not the problem. The insinuation in the JS community seems to be "You never need all that code," which I believe to be false.
Again, no outrage on my part. I just think that we need to address the reality of how modern web apps are built.
Hi Tom, it's hard to believe your snarky-sounding italics were intended innocently when you also had such lines as "Mr. Fuchs has apparently never heard of dependency hell." That is clearly meant as a personal jab, one way or another.
That said, it's true what you wrote, that lots of apps grow bigger and need more functionality as they grow. But "need more" is not the same as "use 100% of a library," so that doesn't really refute Thomas' original argument.
You're reacting negatively to insinuations and attitudes that, as far as I can tell, don't exist on a broad scale at all. Most people you meet in the JS community use frameworks and are clearly not anti-framework. It seems to me (based on the tweets from you and @wycats) that you think this whole thing is about Sproutcore. It's not.
Thomas wasn't "insinuating" anything about Sproutcore any more than he was "insinuating" anything about Prototype.js, another monolithic framework.
Mostly agreed, and well articulated. Though, the point I believe that Tom was trying to make about Diaz having to ask Thomas to change things was more valid with the links that were likely stripped from your comment:
https://github.com/madrobby/emile/pull/7
While you already argue against something like ender.js being valid, Tom's argument, which preceded your comment (and which seemed confirmed by Thomas' post, imo), was that including emile in Ender.js has actually been a pain because he couldn't get Thomas to answer him, let alone change something for him. I believe the irony that was being pointed out was that Thomas then gave ender a shout-out after ignoring it (from an outside and likely wrong perspective).
I say all of this in more of a objective bystander, rather than someone who wants to interject his own opinion on the actual topic. I don't need that kind of stress.
Full disclosure: I found myself quite attracted to Thomas the few times I met him. I think it's the accent.
The point is that Emile is 50 lines of code and can be wrapped up for any purpose in about 2 minutes (export to some object).
Dustin wanted a different API to call upon, so he had to change some stuff, again relatively easy, because it basically fits on a screen in a text editor.
Let's not forget, all of this is open source, and it's meant for adaptation, forking and to be built upon. (Note that Emile was very much a proof-of-concept, with no emphasis on beatuiful, reusable code; it was written as a teaching tool for a talk on CSS animation I gave two years ago at Fronteers.)
I agree, but I think the point of Tom originally linking it was to show that Dustin had integrated a micro-framework (from you), and couldn't get a response from you (even to say the stuff you mention above) and eventually closed the ticket.
It's not my own commentary, though. I was just clarifying to Amy why the argument that seemed entirely unrelated was at least tangentially related. Personally, I would have just modified it and went on my way :D
Actually Dustin's pull request is a bad example entirely. He wanted to change the whole API of emile. He liked the functionality but it didn't work for how he wanted to integrate it into ender. If an API doesn't work for you, you're kind of screwed, whatever library you're using. You either hack it yourself or you ask the maintainer. If some API of SproutCore wasn't to your liking, then what?
Dustin could've written an adapter around emile to expose the api he wanted to for ender. But that would defeat the purpose of ender which is to cleanly integrate several great micro frameworks. He didn't have to wait for Thomas. He wanted to explicitly. It was a goal of his to keep the dependencies pure.
Dependency hell is a problem with integrating several different frameworks. But I'm not sure this is the best illustration of that.
Slexy, I didn't know about this. Because 5 days ago, I was too sick to do anything but lie on the sofa and moan, and Thomas was taking care of me while holding down the business all by himself. It's unfortunate that Dustin assumed that not hearing from Thomas in just a few days meant that Thomas was angry, ignoring him, or whatever.
But nevertheless, Emile's not only open source, it's MIT-licensed. Dustin can do whatever he wants with it, any time!
Unrelated to the OP, but related to this: I get that it's real life, and people forget that all the time on the internet. You should start feeling better soon. Forealz. I demand it. CFS sounds terrible and we're all rooting for you to figure out a real solution despite shitty doctor luck. Many <3z.
Thank you so much. You really made my day singletear :)
I don't know enough to contribute to this debate, but I found the tone of your comment more distracting than that of the article. (I come from the 'less code is better' camp in lisp http://github.com/akkartik/wart, so I have no axe to grind.)
Fair enough. You must have also hated the original article then ;)