slexaxton

no ur absolutely horrible

I don't believe they had much say in the change. They are still using the money to do what they said they'd do in their campaign, and many people are setting up their registry as their default. As far as I know they just got caught in a situation that was less than ideal (while also getting rid of some financial burden). I think they deserve an applause for running it at high cost to their business for free for years rather than be villainized because they got caught in a situation that they weren't in control of. If you donated, or are worried about what Npm, Inc. is doing (hint: so silly to feel this way) you should set your default registry to theirs (it's already set as your failover, btw).

The cynicism in this thread is so bizarre to me. No one is being evil. There's no secret foul play. Everyone go write modules and share them and be happy.

This is a common confusion. The scalenpm crowdfunding was done by the good folks who ran the npm servers for free (mostly nodejitsu) up until the recent switchover to the new infrastructure with Npm, Inc.

You can still use the nodejitsu registry for free if you'd like[1]. They arent likely to need as much scaling anymore, but there's still a big cost to running those servers. I don't think there was any foul play when it comes to the scalenpm money as I'm fairly sure they were not aware of the intent for Npm, Inc to take over default hosting.

tl;dr the money did not go to the same people, and the people who crowd funded thought they'd still be hosting npm going forward at the time.

[1] http://blog.nodejitsu.com/simple-hosted-private-npm-and-regi...

[Stripe Developer] [edited for clarification]

I appreciate your interest in the security of Stripe, I think we definitely share the same goals here (making everything as secure as possible). However, I think there's some misunderstanding in some posts (and in the blog post):

[...] the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant When Stripe.js is included within the user's browser by a (mandated https, not http) request, it comes directly from Stripe's servers, not from "the server infrastructure owned by the merchant."

Stripe.js isn't served from the merchant. It comes directly from Stripe. Stripe.js helps keep payment card data away from a merchants own servers.

Keeping card data away from someone's machines doesn't mean that they don't need to comply with the Payment Card Industry Data Security Standards, but it does make things quite a bit simpler.

In most cases it means that they're eligible for one of the light-weight self-assessment questionnaires.

PCI compliance, of course, shouldn't be where people stop thinking about security though. You're absolutely right that if the pointer on the merchant's site is changed to a malicious site, that's where the payment data will go. The merchant needs to keep that pointer safe in the same way that if you're redirecting to a hosted payment form or elsewhere, you need to make sure that isn't tampered with either. (A hosted form has the advantage that at least a customer can view the SSL cert but if they don't recognize the domain (or if the domain is obscure anyway), that's not much good.)

Being compliant with the PCI standards is important but it doesn't cover all of the very, very important points of web security.

We do take security very seriously, and if you happen to find a valid security issue with our service, we pay bounties[1] for properly disclosed vulnerabilities.

If you have any other questions, or would like to wax poetic about security or PCI please don't hesitate to send the security team an email at security@stripe.com or to email me personally at alex@stripe.com.

[1] https://stripe.com/help/security#rewards

(Stripe Developer) - tl;dr -- This claims that Stripe.js runs on the merchant's server environment, causing the server to be subject to PCI DSS. In reality, Stripe.js is served from Stripe's servers, and runs only in the browser, and this has always been the case.

Agreed, this is what I did say several times in the article, as well as calling much of it non-scientific. Though I did cite 2 scientific studies, and some non-trivial biology, I meant the article as a personal experience piece more so than a case-study for what everyone should do.

I don't know if I can properly distinguish the difference between programmers being overpaid and the rest of humanity being underpaid.

Even if it were true, it would be against our interest to say that we're an overpaid, entitled class.

Not everything that's true or right has to be in our interest.

Many important parts of checkout are open-sourced via our jQuery.payment plugin [1]. It allows you to build your own checkout flow from component parts. As for open sourcing (capital C) Checkout entirely, we're working hard to provide a high-touch, consistent experience for checking out and we haven't been able to reconcile that with a bunch of small (maybe less thought-out) variations on the same thing floating around. We're always trying to think about ways to make this stuff better, though. We're definitely not against the idea, we just wanna do it right (i.e. allow non-programmers to customize without making things work incorrectly or look bad).

1. https://github.com/stripe/jquery.payment

This varies from project to project based on needs. The checkout stuff uses sprockets-commonjs, browserify and require.js are used in other projects though. The decision is often made based on the backend (is it already ruby/sprockets?), and the needs of the project (would rebuilding the full file on each change be prohibitive). For the most part though, the build system remains transparent to all but one person (me, these days).

Hi, Stripe Developer here.

We have a mostly per-project set of code style and tooling guidelines. Most (if not all) of our larger projects are coffeescript and commonjs based. That's mostly because they all share at least some code. As long as a project is internally consistent and the team agrees with each other, we don't force any specific styles or tools (within reason). We have expertise with the tools we use the most though, so a lot of times the best fit is our own tools.

However, the comparison is a little bit apples and oranges. The JavaScript is optimized for reading, and maximum coherence by outside developers (an example), and the other is a compiled application for execution. The actual _source_ of the checkout project (which is not open-sourced) internally is broken up into neat files and uses modules, etc. It's quite readable for those working on the code, and the output there is generated by a computer and not really intended for humans.

Hope that helps give some insight into our process and reasoning.

Thomas and Amy speak a lot on never accepting outside investment. So this was probably their own money. ("Bootstrapped," if you want)

bentlegen _is_ an expert in third party javascript, and is correct that both domains need to opt in to a `document.domain` even if they would match with only one changing. This is to prevent this exact security exploit.

You don't have to go from IE8 to IE9. You can go from IE8 to _any other browser_, and things will look up.

Most people also apply this to object literals. There are no var statements in this situation.

I don't believe that this is just an oversight because "people say you shouldn't use `with`". It simply cannot be optimized in the way that normal property accessors are. If you look at old IE perf, they're actually pretty close (both really slow).

Brendan's other words included:

> My two cents: be careful not to use ASI as if it gave JS significant newlines.

http://brendaneich.com/2012/04/the-infernal-semicolon/

Doesn't `with` have significant runtime costs? I didn't think people didn't like that one because it was a 'bad pattern' - I thought it was because it was really slow.

EDIT: I went ahead and JSPerf'd it, and it is 13x slower to run the example in the article.

http://jsperf.com/with-perf

A lot of times this doesn't matter, but it's not nothing.

Edit 2: Also people avoid using `with` so their minification tools have a better chance. Another thing that can be overcome, but just pointing out that it's not religious dogma that makes people avoid `with`.

I agree consistency is key, but it _was_ consistent before (in it's use of semicolons), and is still (in it's non-use of semicolons).

Fair enough, I'm not claiming that other, much more difficult work didn't go into the feature updates. What was the reasoning for switching to semicolon-less? Why wasn't that a concern when the project started? (Apologies if I missed it in the notes.) I have no problem with projects doing one or the other, the _switch_ just doesn't fit into my brain correctly. Perhaps your tastes just changed?

Naturally, the semicolons have always been stripped by the minifier. This makes the code no more 'minimalist.'

Not using semicolons seems fine enough. Going through and removing the semicolons that you already used seems like you're just trying to start drama. Why not use that time to do something that effects the code positively or negatively?

27 minute

FTFY

What about shoes proxy support?

What are you referring to? This is a blog post and the talk that she refers to in the first paragraph has full audio/video available here: http://jsconf.eu/2010/speaker/the_jquery_divide_by_rebecca_m...

Hope that helps your hate.

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 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

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.

Actually it makes a ton of sense to asynchronously require javascript files on your production page. If you load them asynchronously and in parallel, you can often get much better performance than one single request (serially).

http://blog.getify.com/2009/11/labjs-why-not-just-concat/

I'm really confused by the notion of the "In the time this article took, they could have built a better one" arguments.

I don't know how long you think it took ( https://github.com/paulirish/w3fools ) but it took a couple of hours of time from a few people over about a week.

I'm not sure the last time you built a website to scale and to the breadth of information that's found on w3schools (valid or not), but it takes a hell of a lot longer than a week.

And just because the creators didn't build a clone of w3schools, doesn't mean they aren't contributing useful information back to the various communities affected by the nonsense published at w3schools. Every single one of them are writing blog posts and submitting to open source projects, hosting podcasts, helping on IRC channels and forums, and building helpful websites to learn exactly the same stuff found on w3schools, except with valid information.

The creators of w3fools have no issue with the other resources that are available that they suggested as alternatives. For more specific beginner data, there are numerous walkthroughs and helpful answers littered across the internet with the correct information in them. Creating yet another site that puts together tutorials isn't what is needed. They want the beginners to be able to have a fair chance at good knowledge. Creating a site to slowly gain google juice over the next two years does nothing to help people today. Until w3schools stops showing up first for every "___ Tutorial" search in existence, the job of making it a notoriously questionable resource will do way more good than building a shadow site would do. If at least you are somewhat aware that you should fact check the things that you learn there.

I find it a little bit troublesome that the group that follows 'hacker' news is so willingly supportive of blatant technical misinformation. You can nitpick about some of the things that are brought up, but as a whole, it's ridiculous that the number one resource for technical information is so wildly out of touch with reality. You can question the method that this was brought up, but you should still have the desire to see good information in the wild.

And finally, yes, there are other out of date websites that have tutorials on them, but they don't show up first in google, and they don't sell certifications based on their misinformation to unknowing people who don't realize that the certifications mean absolutely nothing (and are potentially detrimental). Get mad at whoever you want, but objectively speaking, the site is a disservice to the community, regardless of it's ease. Getting bad information is _always_ easy.

You forgot: http://cdn.thetaylornation.com/taylornation/resources/displa...