+ 507 additions, - 24,624 deletions | Hacker News Reader

+ 507 additions, - 24,624 deletions

github.com

63 pointsbonzoesc25 comments

It's obvious that a static HTML page will render faster than one dynamically generated from JSON data. But now the site looks massively more annoying to maintain since any change in how the data is presented will need to be made in 30+ places. And even adding a single library will involve HTML coding.

tomdale started a project in a framework he's comfortable in and said he plans to iterate on the site. Who cares if it's a little slow? It's a dick move to copy the source from Firebug and file a pull request.

This pull request doesn't genuinely help the project.

It would also be relatively trivial to convert a Rails app in the first week of development into a Sinatra app, or even a statically generated HTML app. Says nothing about whether it's a very good idea.

tl;dr: code to remove everyjs.com' dependencies on jQuery/Sproutcore. 24,624 deletions comes entirely from the removal of jQuery and Sproutcore. The resulting code/html is only mildly smaller.

The resulting flamewar, however, is far from mild or small.

There are a few vocal people that want everyjs.com to load in a reasonable amount of time in a desktop browser, as well as on their mobile phone arguing against proponents saying that this will not be an issue as sproutcore evolves.

Currently, in the latest chrome on OS X 10.6.7, the site takes a whole second to render and then doesn't even show me any libraries - apparently the json that defines the libraries is empty. I'm leaning towards thinking not using sproutcore for this particular site is a good idea, although it is a great illustration of one of sproutcore's pain points (namely, speed, compression and mobile support).

Can't wait until sproutcore 2.0 is closer to a release candidiate.

Many people use side projects to play with new and interesting technologies. Sure using SproutCore may make the page load slower, but this is something Tom did in his spare time and as community we should be thanking him for his contribution.

Also, I'd like to commend Tom for staying classy in the pull request and not getting into a flame war about the merits SproutCore.

First, I hope this was a good-natured joke; Tom's exploratory project ought not be held to production standards.

That said, this pull request does highlight one DRY opportunity: git submodules [1]. The jQuery+SproutCore integration here could've been two submodule 'links' rather than 24,000 lines of copied .js library code.

As long as the dependencies are on git and the commit 'version' you're linking to doesn't disappear, you're good.

[1] http://book.git-scm.com/5_submodules.html

I've used submodules quite often, but in my deployment setup the checked-out/built version ends up stored, since I keep the deployed tree in its own branch[1].

As long as you link to the version you link to, it won't disappear in your local repo, and you can re-publish that as necessary :)

[1] See https://github.com/bkerley/design-miami-challenge-apr-2011/t... for one using the free http://pages.github.com/ hosting.

I've preferred to use something like Braid[1] than trying to deal with submodules.

[1] https://github.com/evilchelu/braid

This is pretty silly. The site's clearly designed with further extendability in mind; this just means that when the author does want to make it into a full site he'll have to convert it back into JavaScript.

I agree, the best way to accommodate future scope creep is to write bloated code from day one

24k lines removed are from SproutCore and jQuery. I don't think that's bloat.

The issue isn't size, it's technique.

Generating a small static HTML page from a JSON object using a multitude of JS libraries is overkill and degrades poorly. Not to mention all the other issues it causes: http://news.ycombinator.com/item?id=2598273

Annotated HTML is the best tool for the job here.

"designed with further extendability in mind" is very vague. How about implementing only what's necessary? Unless everyjs.com is in fact just the authors' sandbox.

i also recall the author mentioning they wanted to implement sorting and filtering. i imagine sproutcore offers neat possibilities here.

it also means that because the list is JSON, he already has an API of sorts.

when i saw the site i too wondered why it wasn't plain html, but i think the above reasons are legitimate enough.

mostly though, it's just some guys project. who cares if it doesn't load fast enough on your phone?

EDIT: After being schooled on what a dick I am, I'm refactoring this to:

sstephenson: unless your goal is to publicly embarrass tomdale, there must be something more productive for you to do. You presented your commit in such a way that it makes him look bad, and that phrasing in your pull request appears to be intentional.

You call out sstephenson for being an asshole to tomdale, here:

> sstephenson: unless your goal is to publicly embarrass

And then immediately in the next sentence, suggest that tomdale is some kind of dog?

> He's clearly not very competent, what is the point in rubbing his nose in it?

He's not a dog. He's a person with feelings. He's also a fellow HNer:

http://news.ycombinator.com/threads?id=tomdale

You disappoint me justin_vanw.

My goal is to prevent the spread of misinformation by example and help developers understand how to choose the right tool for the job.

I can't believe I'm posting this, but are you genuinely suggesting that contributing a patch to an open-source project is somehow worse than calling the project's author incompetent (your words) on Hacker News?

I didn't say it was worse, I said it was pointless. I would have more accurately reflected my thoughts if I had said "you obviously don't think he is very competent".

I could learn to be more careful about people's feelings regardless. Sorry tom, I don't know you and I shouldn't have commented.

Exactly. There's no reason to crap all over someone's toy project when they're clearly learning, playing and experimenting. The choices sure seem like someone learning the framework, and I bet there's a better way to teach.

While I appreciate the kind words about my programming skill ;), I needed a pet project to test drive SproutCore 2.0, and that's the reason I picked it. I would probably not have done so otherwise given its current limited scope. But again, as features increase, the use of SC will become more valuable.

Sorry if that came off harsh - edited for clarity. Whether or not someone is the best programmer in the world with a certain technology, we're all complete novices in more areas than we can count. I know nothing about SproutCore, so count me among the utter noobs there.

There's no point in jumping down anyone's throat for experimenting with new technologies though. Keep up the classy responses on Github :)

The best kind of pull request: making it simpler, smaller, and faster to load.

Not sure if I would use tables for layout and probably wouldn't remove the html5shiv js that is there because of html5 compat in IE. But thats me.

So everyjs.com uses Sproutcore? I thought that was for desktop-like applications.

Whatever the merits of the debate, I've been put right off Sproutcore.

Reply on news.ycombinator.com