purpleturtle

Right — that's how I interpreted it. There are still two companies that are larger in San Francisco.

"We have quickly become the market leader in San Francisco."

This is an odd statement since I know there are at least two direct competitors who are far larger.

I'm involved in the project if anyone has comments/suggestions.

Author here if anyone has further advice for me to weave into the post.

Video producer here. Would anyone be interested in seeing more YC founder stories told on film?

builtwith doesn't show all js libs. it just whitelists the top 20 i believe. looks like Wapanalyzer might be similar.

alexa is also unrelated to broad js penetration detection.

not sure how ghostery is relevant.

the novelty of libscore is that it detects all js libs (even brand new ones with only 20 sites using it); doesn't use a dumb whitelist filter.

Unlike celebrity culture, popularity in the open source world translates to actual impact on the web. As an author of a popular library, your code plays a direct part in how other developers structure their codebase, and -- depending on the library -- the end user experience.

And, yeah, impact/change/popularity (whatever you want to call it) is certainly a main reason behind releasing and maintaining open source software. Perhaps other dominant reasons include giving users differently opionionated alternatives that better suit their workflow, advancing the technical know-how of a field, and simply experimenting for expressiveness' sake.

Yeah, the submitter (unaffiliated) came up with that slogan on his/her own. Happy to have admins here change the title if they're willing?

Exactly. That's why we removed any mention of a "score" from the copywriting before launching. We realized how vague a score could be. We focus on site counts now, since they're raw/unfiltered data.

npm actually publishes its own top lists.

what's interesting about the work we've done on libscore is that it shows the end result -- whether a lib was actually ultimately used on a site. npm can tell you download stats, but that's where its data ends.

Cleaning a few things up first :) Star the repo and stay tuned for an update.

Search for "React", which is the variable name React exposes itself under. It's also on the trending data page.

Good points :)

The problem was that fuzzy search would have been technically overwhelming to implement due to the size of our data sets (1 million sites * avg. # of leaked global variables). Also, it would have resulted in a lot of confusing matches because of how arbitrary JavaScript variable names are.

Keeping it to one-for-one case sensitive lookups was the only way to clearly express searching behavior and return accurate data every time. The downside is that we force people to read our homepage how-to to learn how to use it :)

One of the creators of Libscore here. I want to sincerely thank Stripe for making this project happen. I am still elated that they were willing to back this crazy idea of mine.

Libscore isn't perfect, but it sufficiently serves its purpose of competitive analysis. I've written more about the intentions of the project, including a thorough analysis of its downsides, here: https://medium.com/@Shapiro/introducing-libscore-com-be93165...

Fear not. Your performance concerns are mostly unwarranted (creator or Velocity here). Here are some articles to consider reading that help debunk this myth:

http://css-tricks.com/myth-busting-css-animations-vs-javascr...

http://davidwalsh.name/css-js-animation

http://www.sitepoint.com/incredibly-fast-ui-animation-using-...

http://www.smashingmagazine.com/2014/09/04/animating-without...

https://developers.google.com/web/fundamentals/look-and-feel...

For what it's worth, Velocity is a fairly new library. I wouldn't have gone down the path of JavaScript-based animation had my research and testing demonstrated that it was appreciably inferior in any way.

Github link: https://github.com/VelocityPlugins/vmd

Direct video link: https://www.youtube.com/watch?v=7IxhIMIdkPs&hd=1.

The ramifications of this plugin are significant for front-end developers. It saves countless hours of dev time by preventing constant IDE <--> browser switching and repeated UI state reconstructing.

One of my favorites is Lean Analytics. Goes over all aspects of product growth metrics.

Similarly, I recently built a real-time animation tester. It accepts the full range of CSS properties:

http://codepen.io/julianshapiro/full/oHaCy/

Useful for understanding the difference between properties and for testing out motion design concepts.

Absolutely. Fantastic suggestion. It's on my to-do list now. Thank you.

It's actually supposed to, but there's a bug. Thanks for pointing this out. Fixing now... Fixed.

I'm about to start using Ember, and I can't wait to dive into liquid-fire. Thank you so much for putting this together, Edward.

As for micro-typographic rules: You'll find that a simple way of accomplishing this is to use Blast's generateValueClass option.

Thanks for the kind words!

Lettering.js has a slightly smaller footprint and aims to be a dead-simple "wrap spans around each letter/word in the HTML element I point you at." Accordingly, it discards your HTML then dumbly splits using spaces as delimiters. Because of this, you have to use Lettering.js in silo'd portions of your page where you don't mind losing HTML and event handlers. Further, its lack of UTF-8/multilingual text parsing means that it's only suitable for English, and only in controlled portions of your page where you already know exactly how text is written out.

Blast, in comparison, tries to be a "set it and forget it" library. Point it at anything, blast it apart, then even reverse what you've done ($el.blast(false);). You can apply it to user-generated text in real-time and not worry about a thing.

Perhaps most important, though, is that Blast.js features a sentence delimiter plus search, which Lettering.js does not.

In case you're unaware: Font Bomb is a (gimmicky) solution for literally "blowing up" text. Blast.js, in comparison, is a robust text parser for real-world typographic manipulation.

It's generally considered bad practice to overwrite existing functions that other code relies on -- you can never be sure that your replacement is 100% compatible.

Yep, I authored an article on CSS vs. JavaScript performance here: http://davidwalsh.name/css-js-animation

GSAP is awesome. They proved to me that Velocity was a worthwhile pursuit.

Exactly right -- Velocity is a jQuery plugin and jQuery UI/CSS transitions replacement whereas Famo.us is a full-fledged app framework built around a physics engine.

As for a performance comparison, their demos have crashed my phone. So I have no idea. Looks like they've also pulled their demos link for now: http://famo.us. It's a pretty awesome concept though. I hope they succeed.

Thanks for the heads up. Julian.com is currently hosted on GoDaddy -- so nothing would surprise me :) Switching to AWS later in the week.

I agree. The issue is the DOM. (For contrast, I've seen highly performant 3D worlds rendered in the browser via WebGL that don't bring my computer to its knees.)

We've been layering on years of HTML/JS additions that aren't allowed to break backwards compatibility. (Google's Blink project is one example of an effort to try to undo some of this.)