everyjs.com
everyjs.com copied to clipboard
tomdale
Remove gratuitous use of JavaScript
Wow, Sam, this is really great work! I (and I'm sure others) are impressed by your JavaScript kung fu.
As the maintainer, I'd like to keep the site itself in SproutCore, as it helps me test drive it and ferret out bugs.
Maybe we can work together to figure out what problems you have with the extra JavaScript. Was it preventing you from using it on a certain device or platform? How long was the load time for you?
Without removing SproutCore, I'd like to get to the bottom of your problem. Also, keep in mind that I'm planning on adding additional features in the next few weeks and months that will take more advantage of SproutCore. Again, this was very much a "scratch your own itch" project for me, and I don't think using SC violates any of the stated "House Rules."
Thanks again!
@bry4n, Are you sure the load times are not related to the fact that TypeKit fonts won't load on domains other than everyjs.com?
Just for fun, try loading both versions in Mobile Safari on iOS. Now imagine you’re doing that over a Mobile connection.
@tomdale I’ve used Charles to look at both the amount of data and response time of both versions, ignoring TypeKit. In that case http://sstephenson.github.com/everyjs.com/ loads twice as fast as http://www.everyjs.com (1.39s vs. 2.91s).
Hey Tom,
I suppose my problem with the site is its claim of promoting the best tool for the job. The meaning of "best," of course, is subjective, but you gain absolutely nothing by rendering the page content in JavaScript, and lose a lot -- search engine indexability, for one. (I won't get into all the issues others have reported.) So I thought I'd demonstrate how much simpler it'd be to just use basic HTML instead, with a few annotations for sorting and filtering.
In my opinion, for a site like this, annotated HTML is the best tool for the job.
-1. This is a js website for js frameworks. Let Tom demo SproutCore and add features if he wants to (though it should be clearer on the website). SC use will rapidly become more appropriate then.
@sikachu - whoops, it must've gotten lost when I was cleaning out the IE conditional comment soup.
+1. "The right tool for the job" as a tagline falls flat on its face when the site requires 250k of JavaScript and spends over half a second in JavaScript (I profiled it :P) before rendering anything. Caused a noticable delay, plus it's not search engine crawlable, didn't work on my Android +++. The Android problem I think was fixed, but it's still way overkill to pull sproutcore in here IMO. If these upcoming features requires more stuff, add it incrementally.
This pull request is now publicized on Hacker News, so cue dozens of unrelated people commenting on it and cluttering it (like me!). The non-Javascript version loaded significantly faster in my browser, FWIW, with no obvious delay before displaying content.
@cjohansen In all fairness, http://www.everyjs.com loads 159.49 KB JavaScript combined, not 250 KB:
Ah, I actually glanced too quickly at Firebug and reported the uncompressed size. 150k is still waaaay too much js for such a simple site.
Who cares if it is a little bit slower. Let @tomdale play around with SC he will be the main maintainer so let him pick the technology. You wouldn't fork Rails and replace the ruby with java just because ruby is slower.
Everyone is getting their panties in a twist for no good reason. It is merely a pull request, it is not like anyone is holding a gun to @tomdale to have him accept this pull request.
Personally I prefer the non-javascript one due to the speed at which it loads, and I prefer to have a page have progressive enhancement rather than the other way around, but I can see the use of JavaScript libraries to do more client side processing.
Wow, this is really great feedback. I appreciate everyone taking the time to give their input.
Maybe it would be fun to provide the data and have everyone implement everyjs.com using their favorite JavaScript framework? Then I could provide a menu on the page for users to switch between the different implementations.
What do you guys think?
@tomdale: at the end of the day, use whatever you want!
That being said .. anything that breaks progressive enhancement, in my book, should be avoided without good reason! (and yes - scratching an itch on a pet project is a good reason)
@tomdale, the multi-js idea is a great one (and also helpful for gauging actual sustained interest in this issue)!
If you really want to try out SproutCore, you should try the new 2.0 developer preview. It more suited for websites, it's lighter and faster.
But I agree with the rest, you don't really need it. Vanilla HTML with a dip of JS should suffice.
Maybe it would be fun to provide the data and have everyone implement everyjs.com using their favorite JavaScript framework? Then I could provide a menu on the page for users to switch between the different implementations.
it's an awesome idea!
Why not rewrite the use of tables at the same time? You shouldn't remove the html5shiv. It's there for the html5, that you aren't using. Other than that, neat :)
A big problem is that JavaScript is required to load content. Plenty of people browse the web noscript. In these HTML5 days, noscript is the new ad block. I suppose this is a fundamental problem with the sproutcore framework. Not using progressive enhancement is bad practice for presenting content on the web. Even if you plan to add more fancy features later. Defining the boundary between content providing sites and rich applications is a difficult task though.
@jdalton Thanks for the feedback -- I've incorporated some of your suggestions.
I'm afraid we disagree on the appropriate use of HTML, though. I most emphatically believe it's better for this data to live in HTML.