polotek

I don't think you've taken the time to ask how it might be different from even the other evented systems that have come before. When something that looks similar to what has come before seems to get undo attention, you should perhaps ask if you're missing something.

All languages, platforms, frameworks etc have strengths and weaknesses. There are lots of factors that contribute to a certain solution being "really good" for a problem as opposed to "serviceable but not great". Engineers look for great solutions to problems. They don't stick with ones that are sub-par just to avoid explaining to nay-sayers why they decided to switch.

But it's not such an edge case in javascript where asynchronous programming is the norm and stacks get thrown away all the time. In fact it's exactly the scenario that people will immediately try to solve with blocks, but they will fail.

function getMyData(input) { asyncDataCall(input, {|data| return data; // fail }); }

I think you're inventing specific requirements to win a debate. So essentially "I can imagine a scenario that would hard for you to accomplish". Are you saying there is no scenario you can fathom that's difficult to accomplish in ruby? If that's that's the case, you should probably be lobbying to replace javascript with ruby. Not to spend lots of time and effort and pain to turn javascript into ruby.

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.

Left a comment there, might as well leave it here too.

An interesting debate (minus the personal attack stuff). But I think the problem is that both sides are trying to warp and narrow the playing field to suit themselves. The truth is there are plenty of projects that will never need all the machinery of SproutCore. And there are plenty of projects that start out too small and then struggle to grow more complex. Choosing your tools is hard. It should be hard and it should be taken seriously. Neither side should be trying to convince people that it’s an easy decision.

- "This is why you should always just start with SproutCore". - "This is why you should just start small and integrate micro-frameworks as needed".

Both bogus arguments really.

I’m also quite sure that neither side really wants to disparage the other side. They just want to make sure their own side isn’t being disparaged or misrepresented. This is what most internet arguments are made of unfortunately :)

What would be more awesome IMO is if we started talking about when it’s a good idea to take either approach. Let’s hear some use cases. And let’s stop using Twitter as an example. There is only 1 Twitter and their requirements are not going to be representative of the web dev community at large.

I respectfully abstain from the vote.

They are still trying to pull it off and hopefully the resources of google will help them. The problem vark faces is that they have to build up a large and active community of people willing to answer questions.

I was an early user and I still make myself available for questions all the time. But I'd say probably 3 out of 5 times I get a question, I just don't have the time to respond with anything useful. And after a certain amount of time, you're past the "real-time" threshold so there's no point in responding.

But when vark works, it really works and it is awesome.

I think this is my underlying problem with keyboards. I have very wide shoulders. I"ve had the most luck with the microsoft natural, but I find myself wanting to increase the split angle all the time.

Also having an ergo keyboard with low soft keys like the Mac would be awesome.