You might not need jQuery - <AUTHOR> http://youmightnotneedjquery.com/?hn <comment><USER2> No, please no. If size is an issue for some reason or you want to have no dependencies you can use something like [http://zeptojs.com/](http://zeptojs.com/) and just embed everything in one minified file. If you do things right only the functions you are actually using will get placed in there as well.

Do not reinvent the wheel to solve problems that can't be solved in much cleaner and nicer ways. Managing dependencies can be annoying, but we all bite the bullet for a very good reason, because reusing solid well tested code is a _good_ thing.

<comment><USER3> I believe the point is that many libraries use about 1% of jQuery. That hardly justifies pulling in the entire thing.

A personal anecdote: I recently un-jQueried a little piece of code and ended up with only a couple lines of extra code.

Certain parts of jQuery are _heavenly_ and well worth it, but really basic usage doesn't actually save that much. $("#something") instead of document.getElementById("something") is not really buying you much in the way of cross platform-ness or thoroughly debugged code and is hardly reinventing the wheel.

<comment><USER4> I agree with the overall message- you should be thoughtful with all your dependencies. You should only add complexity when it makes sense.

However, the author goes beyond just selector vs. getElementById().

Does the way the author uses XMLHttpRequest work in other browsers the way it works in IE? I honestly dont even remember anymore.

How about the code for fade? I never even knew the details of this feature. And I'm not sure I want to.

<comment><USER5> IE has been basically standards-compliant for XHR since IE9, and possibly before:

[http://www.w3.org/TR/XMLHttpRequest/#interface- xmlhttpreques...](http://www.w3.org/TR/XMLHttpRequest/#interface- xmlhttprequest)

[http://msdn.microsoft.com/en- us/library/ie/ms535874(v=vs.85)...](http://msdn.microsoft.com/en- us/library/ie/ms535874\(v=vs.85\).aspx)

<comment><USER6> For IE9, don't you need IE-specific code for cross domain requests?

<comment><USER5> Yeah, you need XDomainRequest for CORS requests in IE8 and 9. IE10 is fully standards-compliant.

[http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdoma...](http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest- restrictions-limitations-and-workarounds.aspx)

<comment><USER7> It is very castrated, better to use hidden iframe + window.postMessage for cors in ie8 and ie9.

<comment><USER8> I don't think "castrated" is the word you meant :-) Perhaps "constrained" or "restricted"

<comment><USER9> ...why not?

"to render impotent or deprive of vitality"

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I understand the desire for people to make pages like this (this isn't the first), but the examples are not completely honest with themselves, in my opinion.

One of the biggest benefits jQuery introduces is the concept of treating single selections and multiple selections identically. While using jQuery, I can emit a $(".class").hide() call, which will apply to all elements with the matching class. Simple and elegant.

However, using native JS as the page suggests, I will need to construct a loop within my function, especially if I'm using the DOM supported getElementsByClassName method, returns a pseudo-array of DOM nodes which don't have the style method available on them. You'll notice the examples already assume a selected element and leave much of this heavy lifting out.

Furthermore, jQuery offers the selection simplicities of Sizzle (ie: "#div .container .item). To do the same selection process in vanilla JS, I'll need to nest 2 getElementsByClassName functions in a getElementByID function, and return the concatenated results from each potential .container. That is to say nothing of more complex selectors.

So yes, if you're addressing the absolute simplest form of selection, this works, but otherwise I don't think it's really presenting the situation honestly.

<comment><USER11> You're certainly right. Did you see that the page specifically targets people who make javascript libraries? The page is arguing that when possible, libraries shouldn't depend on jquery, and shows how to do that for a few common idioms.

Since a library is written once and used in many different places, it's worth going to a little more effort to make it more flexible.

<comment><USER12> That sounds more like an argument for picking a canonical version of jQuery that can be cached aggressively, rather than everybody shipping a probably- buggy re-implementation of the 25% of jQuery they need.

</comment></comment></comment><comment><USER13> _The Bad:_

The premise of the examples list seems a bit disingenuous.

Very few of these things take into account the full convenience of jQuery. It's much more than saving a couple lines of code or knowing the native way to accomplish the most basic version of a task. jQuery's real benefit is preserving simplicity as your needs grow more complex.

Right off the bat I feel like the getJSON[1] example is a bit simplistic. Almost anyone using ajax needs to serialize data, handle errors, prevent caching, etc. jQuery has thought about all this[2].

Don't get me wrong -- most of my work has been without jQuery, but that means I know exactly how much work it is.

 _The Good:_

The format is a nice way to show people (who _really don 't know otherwise_) the native JS plumbing.

"The number of people who don't know that jQuery != Javascript is too damn high". So to help combat that, I really appreciate the idea behind this site.

It's great to show side-by-side how jQuery isn't "magic", since many people seem to learn jQuery these days without even knowing the first thing about Javascript, but I just think it should be presented with a slightly different premise.

[1]: [http://youmightnotneedjquery.com/#json](http://youmightnotneedjquery.com/#json) \-- side note, why did they set the handler after the `send`? It seems like that could cause problems if the result was returnable quickly, such as from cache, though I haven't tested it.

[2]: [http://api.jquery.com/jQuery.ajax/#jQuery-ajax- settings](http://api.jquery.com/jQuery.ajax/#jQuery-ajax-settings)

<comment><USER14> That's a great point - this is really awesome as a "learn the essence of what jQuery is doing for you!" and a little annoying as a "you don't need jQuery!".

<comment><USER15> I took the tone as being directed to people publishing plugins that use jQuery for 1% of its functionality, forcing people not using jQuery to either not use that plugin, rewrite the plugin or include jQuery.

Edit: it actually literally says it's for library developers.

</comment></comment></comment><comment><USER16> >post-IE8, browsers are pretty easy to deal with on their own.

False:

\- CSS browser prefixes are automatically inserted by jQuery

\- Many jQuery selectors don't exist in the CSS selector specification

\- Looks really really ugly and that makes it hard to read for you and other coders.

        var pairs = $(".form").not(".old").serialize();

        /* without jQuery */

        var pairs = [].slice.call(document.querySelectorAll(".form"));
        var data = forms.filter(function(ele){
          return /\bold\b/.test(ele.className);
        }).map(function(ele){
          var form = ele.querySelectorAll("select, input, textarea");
          var pairs = [].slice.call(form).map(function(subele){
            // maybe if subele.type === "select"
            // but I got tired of writing this example
            // but that's the point anyway
            return subele.name + ":" + (subele.value || "") + ";";
          });
          return pairs

        }).join("").replace(/;$/, "");

So be kind with your co-workers, use jQuery. Even my 5 year old android can run jQuery without freezing the built-in browser.

<comment><USER17> > Looks really really ugly and that makes it hard to read for you and other > coders.

This point might have been better made if you hadn't intentionally structured it to be as unreadable as possible, and also shoved in a few lines of comments to pad it out and make it look bigger than it needs to be. Not a very honest example at all, considering native JS can be as readable as you want to make it.

> So be kind with your co-workers, use jQuery. Even my 5 year old android can > run jQuery without freezing the built-in browser.

My co-workers can read and write native JS with or without jQuery as it is, why is it being _kind_ to avoid writing in the style of the native language?

<comment><USER18> > Not a very honest example at all, considering native JS can be as readable > as you want to make it.

Can you make an honest version of the example? (genuine interest, no sarcasm)

</comment></comment></comment><comment><USER19> Greenspun's Tenth, updated for 2014: "Any sufficiently complicated website contains an ad-hoc, informally-specified bug-ridden slow implementation of half of jQuery"

I understand the visceral opposition, but once you start writing a fallback to support some browser (something to support IE or FF or Safari or Chrome ...) you might as well use the battle-tested solution (and write your own thing if you find performance to be unacceptable and trace the bottleneck to jQuery)

<comment><AUTHOR> The question at hand is, are fallbacks necessary anymore for the browsers we are targeting today?

<comment><USER3> And the followup is, when do you remove fallbacks from your code? Every time I think I should remove something I end up thinking, "well, it still works just fine, does it really matter if it stays for a little longer?"

<comment><USER5> The cost is in latency and complexity for users of your head browsers. How much do you want to reduce the user experience of your users on modern browsers to support users on old ones?

There isn't a one-size-fits-all answer for this, but you should have some idea of what your traffic breakdown by browser is, and ideally what your cost in conversion rate is for each additional ms of latency (this varies by industry). I don't remember offhand what the cost per byte in latency is, but IIRC we measured something like 1ms per 1K bytes at Google (this would work out to a 1 MBps = 10Mbps connection, which seems around right for typical cable/residential fiber households these days).

<comment><USER3> I'm not sure what you mean about "complexity for users of your head browsers". The idea of the fallback/polyfill is that it doesn't even come into effect for the modern browsers.

As far as latency is concerned, I hear you and that makes sense, but the things I'm talking about are not very big, so the latency gain isn't going to matter much for our purposes.

Yeah, we definitely look at the analytics. But even if it the old browser users are sub 1 percentage point, I see the number and think, "I could take this 5 line polyfill out, but then these 1000 uniques wouldn't work."

And I just don't have the heart...

<comment><USER5> Polyfills are generally a good idea - they cost basically nothing for users of modern browsers, and they go away.

I thought that the issue in this thread is JQuery, which is a layer _on top_ of the modern browser API (probably because the modern browser API didn't exist when it was created, and is in a large part a native implementation of JQuery functionality), and so incurs the cost of all its legacy compatibility support even if you don't need it.

</comment></comment></comment></comment></comment></comment><comment><USER20> So, uh, what will I gain by ditching jQuery?

I will lose a beautiful API with a simple, terse and familiar syntax. I will have to work with an ugly, inconsistent and loquacious API, which has no guarantee of being cross-browser (or accounting for various browser quirks).

And for what? I doubt 81 KB would make much difference to 99.9% of my visitors.

As for performance -- it makes sense to rewrite bottlenecks in pure highly- optimized JS. But to write vanilla JS from scratch, without even knowing whether you'd need that performance boost is a pure waste of time.

UPD: it has been pointed out that this webpage is directed at __developers of JS libraries __. In this case, all these points are valid, but the title, then, seems to be either misleading (as in "link-bait" misleading) or a plain truism.

<comment><USER21> You lose dependency on a monolithic library which creates vertically-stacking dependencies and library conflicts. By ditching it, you gain the ability to construct your app out of loosely-bound components supported by independent developers.

<comment><USER20> Could you elaborate on how jQuery creates vertically-stacking dependencies and library conflicts by itself?

<comment><USER22> Obviously, you cannot have dependency conflicts if you only have a single dependency! We need a slightly more complicated example to understand the problem. Let's say I'm making the new customer checkout page for my startup.

I decide to call an e-mail address verification as a service API, their library uses jquery 1.8

I decide to call an address verification as a service API, their library uses jquery 1.11

I decide to call a credit card validation as a service API, their library uses jquery 2.0

You go to the e-mail address verification company and say "Do you have a version that supports a newer version of jquery" and they say "yes, also we redesigned our library's interface so if you upgrade you'll have to change all your code..."

</comment></comment></comment></comment><comment><USER23> You had me convinced until I scrolled down to read the code examples and realized why I actually do need jQuery. If its between adding yet another collection of utility functions to approximate the functionality jQuery would give me vs just adding jQuery. I'd rather go with jQuery.

<comment><USER24> The first example alone is reason enough to use jQuery - why would I want to use four statements instead one? Why would I want to have to remember to call `send`? Why do I have to remember the last boolean parameter of `open`?

<comment><AUTHOR> Totally valid, but just to say, jQuery's API is just as arbitrary, you just happen to know it better. If you use the native XHR a couple times, you know what open's parameters are.

<comment><USER25> It is just as arbitrary, but I feel jQuery's API is also easier to grok at a glance. Using either a couple times may instill the parameters in your memory, but what about coming back to it after six months?

</comment></comment></comment></comment><comment><USER26> I would like to add a thought about the dispute about the need of using jQuery.

Let's say we know a consultant, let's call him Bob, who works on client projects. He needs to implement new features fast, and does not want to worry about low level stuff. Once he's done with a project, he moves on to another.

Then, we meet a JS-framework developer, let's call her Alice. She has to weight every line of code she writes because her decision can have have a huge impact on thousand of developers using her stuff. She needs to understand a lot of low-level details in order to make good decisions and ship rock solid stuff.

Now, both Bob and Alice have to decide whether they need to include jQuery in their projects or not. Heck, they need to justify their decisions to their teams / managers.

What's Bob going to say? He will start thinking about what will happen if he does not include jQuery to his project. Well, he will have to implement some of the low-level stuff by himself, and later maintain the code. Probably, in a month he's going to be working on another project and will have to copy & paste the same stuff over. And if there was a bug? Is he going to update all the previous projects he is not getting paid for anymore? If he's smart, he's going to say: we'll take jQuery, as it provides a nice, stable, robust and battle-hardened API. We're going to move faster if we use it, as we don't want to reinvent the wheel.

What about Alice? She will probably have to consider introducing a new dependency to her framework. Is it OK to add those additional hundreds of lines of jQuery code to an already large codebase? Is she going to be able to provide a consistent experience between different (and future) versions of jQuery? Is the core of her application going to rely on an external tool, even if it is rock-solid and lose the potential to make low-level optimizations and have full control? Maybe, she's going to say: well, I'm going to identify the elements that need some of jQuery's stuff and implement it by myself. She will be taking the time and effort needed to test it well and be sure that it works across different platforms.

At the end of the day, both will have made the right decision, even if in absolute terms they took the exact opposite action.

Software engineering is about making decisions, in a given context and moment, for a given purpose. As software engineers, we should not generalize about some of the decisions people have to make. There is no one single truth, it all depends on a variety of variables and factors. Let's be Bob and Alice, be smart and make the best decisions for our projects.

<comment><USER15> Right, and this webpage is explicitly targeting Alice.

<comment><USER27> But some of the comments on this page don't seem to get that. I'm seeing too many broad "you should never use jQuery because x" statements.

</comment></comment></comment><comment><USER28> I recently did a project that didn't use jQuery in order to keep my code smaller. It was an embedded 3rd-party widget, so keeping the code as small as possible was a key requirement. The code I wrote supports down to IE7, but IE7 wasn't really the biggest issue.

The real problem with not using jQuery is that all of the collective knowledge we have about browser inconsistencies is encapsulated in jQuery. When you run into this, and Google it, you'll find a million StackOverflow answers telling you to use jQuery, and _if you get lucky_ a blog post from 2007 that actually answers your question. The result is that you end up spending time reverse- engineering jQuery to get your thing working.

To be clear, in my case the tradeoff was worth it (the code for my entire widget including the bits of library I had to write is smaller than jQuery), but it's not a tradeoff I would make unless I had a good reason.

<comment><USER5> [http://caniuse.com/](http://caniuse.com/)

<comment><USER29> Not sure what you're getting at. Feature support doesn't mean there aren't inconsistencies in implementation, and caniuse's documentation on that delta are very much surface-level.

</comment></comment></comment><comment><USER5> Couple improvements to some of the modern-browser code examples:

FadeIn:

      element.style.transition = 'opacity 400ms ease-in-out';
      element.style.opacity = 1;

Each & filter (this also applies to people's complaints about browser methods not working on collections):

      [].forEach.call(document.querySelectorAll(selector), function(el) { ... })

The native versions also usually run several times faster than the JQuery versions, which is the main reason to use them. This meme that you can't build performant, jank-free HTML5 mobile apps? It's largely because of JS libraries and developers that don't know which operations are fast and which are slow.

I'll also plug my colleague's autogenerated index of the HTML5 APIs:

[http://html5index.org/](http://html5index.org/)

<comment><USER30> I've had pretty terrible performance with complicated CSS animations that I managed to clear up with switching to JavaScript and requestAnimationFrame

<comment><USER5> Are you animating the transform/opacity properties and only those? That's the general secret to smooth animations on web - they're GPU accelerated, everything else requires a call into the browser's layout engine on every frame.

</comment></comment></comment><comment><USER31> This be right on a purist level, but on every practical level there is little reason _not_ to use [library of your choice]. If you're loading from the google/jQuery CDN (with suitable fallback, obvs.) you've got a good chance of a cache hit, and even if it misses it's a tiny one-off penalty.

And ultimately, why not? jQuery works, has a wide base of users, etc. Sure your trivial Js might not need jQuery features now, but as you add more dynamic behaviour, at some point you'll wish you had just used it to begin with.

A better message might be: make sure you know what the underlying javascript looks like, because there are a lot of people helpless without jQuery.

PLUG: if you're bored of jQuery, try Dojo. Far more power, in a less intrusive form, IMO.

<comment><USER32> i do Enterprise work & if we have jQuery in a page IBM dismisses our PMRs when we submit issues. So yeah I regularly include some simple cross-browser- normalizing js functions to use with the vendor-approved libs.

Also, jQuery is not trival to use in conjunction with other js libs (Dojo) as namespacing proponents claim. It's not like you just include both & they don't interfere. You have to follow a specific initialization pattern.

<comment><USER31> I don't understand this comment - I'm not suggesting you should use jQuery or nothing, or jQuery _and_ Dojo. My point is the reasons given in the post for not using a DOM library of some sort are not valid.

<comment><USER32> o ok i was taking your comment within the context of the post -- more like "why not allow jQuery as a dependency for an open source lib". sorry for misread

</comment></comment></comment></comment><comment><USER33> It isn't that these rebuttals are unsound, it's the sheer volume of them. A tidal wave of irritation and defensiveness always seems to accompany posts that dare question jQuery.

Unless the headline was changed by the mods, there's no hyperbole or sensationalism here. _You might not need jQuery_. Obviously. But many of these reactions don't belong here, they belong in a post titled _You don 't need jQuery_, which would of course deserve to be downvoted to hell.

Obviously you don't need to pull in jQuery for every little twenty-line gizmo you publish on github. But don't you dare brag about this or you'll offend the sensibilities of those who've invested all their mental energy into learning jQuery and therefore remained ignorant of how browsers actually work.

</comment><comment><USER34> "You might not need jQuery" \-- But you have to cope with ugly syntax, browser compatibility hacks, and disconnected pieces of code. By the time you re- factor all of this, make it user friendly and lower the cognitive load, you're already re-inventing the wheel by building your own jQuery replacement, with the parts that you need.

The beauty of jQuery is working with the DOM as collections. I don't see how it's better to have all these helpers like `nextSibling`, `matches`, or `filter` thrown in the global scope or having to remember is this a real array? jQuery already built solutions for these common problems and exposes a nice API.

If all I need is querying the DOM and I don't have to support IE8 then I may consider using vanilla JavaScript, or building my own simple jQuery-esque library. But you'd start with some structure, and expose your own API. I re- invented the DOM wheel many times, and from my experience, although the code is smaller, I end up going back to jQuery because it covers some edge case or provides something else I need, like AJAX, or nice events, etc.

But building your own DOM library is a good educational challenge. Querying the DOM is all about collections, and if you don't need IE8 then you can use all the ES5 arrays methods, like map and filter. It all boils down to four functions to work with collections: toArray, unique, flatten and query. And four functions to work with the DOM: compose, join, dot, loop. See here for an example [http://jsbin.com/EgIkega/1/edit](http://jsbin.com/EgIkega/1/edit). The article is more about techniques to build your own jQuery-like library; I wouldn't use "el.nextElementSibling || nextElementSibling(el)" when I can use "$(el).next()". C'mon!

Conclusion, you are probably going to use jQuery anyway.

</comment><comment><USER35> Indeed you don't need jQuery. Though, there are standards and there are market/industry standards. jQuery has become a market standard wrapper. If jQuery isn't used, developers will still write a wrapper to ease some of these methods. It is better if that is a common market standard like jQuery than everyone doing it.

The amazing part of jQuery still to this day, beyond the selectors (which can now be replaced yes), is the plugin system. Just like Python, there is a plugin for everything and if you don't like them or there isn't one, developers can easily make one and share it with the world and it just works (tm). It is the most easily pluggable javascript library. It creates a baseplane that developers can be more efficient in. Everybody tries to replace the jQuery selectors, animation etc but they miss that jQuery is a platform and a pluggable one at that. It is responsible for tons of productivity.

</comment><comment><USER36> "You might not need Ruby on Rails. Use C to rewrite tons of shit you need."

Use jQuery please.

Rewriting jQuery methods with vanilla js usually turns out to be a hack job that is buggy and ugly. Just use jQuery.

<comment><USER37> That's a really bad analogy.

People don't use Ruby because C's standard library works differently across different platforms.

This isn't about "rewriting jQuery methods with vanilla js". It's about using the built-in, native, vastly more performant methods that come standard on modern browsers.

<comment><USER38> The analogy is even worse because Ruby changes _way_ faster than C :)

But anyway, writing code in any 'lower' layer is very educational.

</comment></comment></comment><comment><USER39> You can count on one hand the number of jQuery features that _most_ developers incorporate into their projects. E.g.:

\- Setting or getting css attributes \- Querying the DOM \- Manipulating and walking through arrays

Each of these features can be replicated with fewer than 10 lines of code.

</comment><comment><USER40> I don't understand why so many comments here seem to have skipped over the word "might" and the entire introduction. The point isn't stop using jQuery. The point isn't even don't ever use jQuery for plugins. It's simply that if you're only using a couple features of jQuery, _consider_ eliminating the dependency. Why is there so much backlash to that?

</comment><comment><USER41> It's hard to tell if this site is advocating for ditching this type of js library altogether and writing all those replacements inline (ick for some of those) or simply replacing jQuery with a thinner (and narrower) library.

I could be convinced of the latter but not the former.

<comment><USER42> One of the main things we're advocating is to consider not depending on jQuery when building an open-source project.

For Offline, PACE, Odometer, Tether, and many of our other OS projects ([http://github.hubspot.com](http://github.hubspot.com)), we chose not to depend on jQuery because it means our libraries can be smaller and more people can use them.

We're happy and proud to use jQuery when building an application. As many other commenters have noticed, it can be extremely useful at reducing code complexity—and let's just say it: it can make it more enjoyable to write front-end code!

</comment></comment><comment><USER43> > _in truth, post-IE8, browsers are pretty easy to deal with on their own_

I totally agree, but not everyone lives in a post-IE8 world. It's as much as 10% of our traffic on some sites and several big clients use it.

<comment><USER42> That's why it's called You_Might_NotNeedJQuery. ;)

<comment><USER44> If you are developing a library, then your users _Might_ need to support old browsers and _Might_ need jQuery.

<comment><USER45> lots of js libs are for things like webgl that already dictate a recent browser.

<comment><USER46> and I care about wether my site works on Safari or Android 2.3 browsers. Will you fix all the "wont fix" DOM bugs for me?

</comment></comment></comment></comment></comment><comment><USER47> I use jQuery because the DOM API for javascript sucks, and writing jQuery is fun.

You're average web app perhaps doesn't need the latest Ruby/Python/PHP framework, or perhaps it you can write it without the framework. Or perhaps you can a compiled as opposed to interpreted language because that would be faster. OR maybe you can use something that is even faster, like perhaps Assembler! Fuck it write machine code if speed is the most important thing.

Do you know why you don't? Cause writing Assembler or machine code sucks. You lose very little in load time by including a minified version of jQuery, while you gain an enormous amount of ease of use and readability. Also it'll be more fun.

Just include the jQuery and be done with it.

<comment><USER48> _I use jQuery because the DOM API for javascript sucks, and writing jQuery is fun._

How many lines of code are actually needed to give you selectors and the most common DOM manipulations?

How many lines of code are in jQuery?

Is there anything which would not be in selectors + common manipulations that you need, and which only jQuery can provide?

<comment><USER47> DOM selectors and events are critical, maybe ajax. Perhaps you could pare it down a bit - I don't need the animation stuff. I have no idea what the size using only what I might need when I needed it.

But then that becomes a whole another endeavor - how much load time will be saved by only using the parts you need, and how long will it take to figure out what you need and what you dont? It's all about return on investment. What do I need now, what won't I ever use, and what might I use later. It becomes more work to save, what, 1/4 second? Maybe a bit more on mobile. It isn't worth the trouble.

The whole obsession over the load time of jquery feels like an exercise in OCD.

</comment></comment></comment><comment><USER49> It's odd, but after reading everything and the examples at the end, I feel we need jQuery more than ever. Kind the opposite of the OP is stating. Great post though.

<comment><USER47> great content, terrible opinion. I like your take on the article.

</comment></comment><comment><USER50> You might need some semi-colons though...

[http://robertnyman.com/2008/10/16/beware-of-javascript- semic...](http://robertnyman.com/2008/10/16/beware-of-javascript-semicolon- insertion/)

</comment><comment><USER51> My colleagues and I learnt that lesson the hard way. We are working on a WYSIWYG editor (Aloha-Editor) and the first version did depend on jQuery (and jQuery UI for that matter). That caused a lot of trouble for people integrating the editor in their websites, especially if they were already using jQuery. For our particular case we really didn't need it, as it's just as easy to say .getAttribute() instead of .attr(), and we didn't use selectors much, if at all. Effort is underway to get rid of the dependency from the core library in the next major release.

</comment><comment><USER52> Makes me think of: [http://vanilla-js.com/](http://vanilla-js.com/)

<comment><USER53> You know that is a joke right?

<comment><USER52> [http://i1.ytimg.com/vi/xECUrlnXCqk/hqdefault.jpg](http://i1.ytimg.com/vi/xECUrlnXCqk/hqdefault.jpg)

</comment></comment></comment><comment> at-fates-hands This is fascinating to me since I'm already moving away from jQuery. I'm always looking for other ways to do what many people use jQuery for. For example, I'm now using CSS3 animations and transitions instead of jQuery.

I've also started using Angular.js quite a bit and have found most of the time, it requires less code than jQuery. It also has its own subset of jQuery "jqLite" which has a much smaller footprint so your app doesn't need to rely on that jQuery dependency.

</comment><comment><USER54> You might not need jQuery 1.x.

You might be able to use jQuery 2.x instead, which is smaller, faster, and drops support for IE8 and below.

</comment><comment><USER30> querySelector and querySelectorAll have bugs in IE8. Checkout the jQuery source code and search for these functions and see the comments and workarounds if you want to be sure:

[http://code.jquery.com/jquery-1.11.0.js](http://code.jquery.com/jquery-1.11.0.js)

Notice the rbuggyQSA variable.

Also check out Quirksmode:

[http://quirksmode.org/dom/core/](http://quirksmode.org/dom/core/)

</comment><comment><USER55> I don't know if i need jQuery or not But your page is seriously a great "Cheat Sheet" for all jQuery Learners out there ! Thanks

<comment><USER56> My favorite part is how I learned that I don't need to use `var`—I can make everything global!!

</comment></comment><comment><USER57> Recently, I have developed a small page where I wanted not to use jQuery on purpose and code against the DOM APIs instead. For IE8 compatibility I have used [1] (so I could use addEventListener and DOMContentLoaded for example), and also shims for ES5 [2] (e.g. Array.prototype.forEach) and classList [3]. While I did not run in any troubles, I don't think it is worth the effort, alone just because jQuery has a much nicer and shorter API (cp. ".on()" vs. ".addEventListener()").

But I still support the case that not every plugin/library developer should depend on jQuery by default, even if it is not necessary.

[1] [https://github.com/WebReflection/ie8](https://github.com/WebReflection/ie8) [2] [https://github.com/es-shims/es5-shim](https://github.com/es- shims/es5-shim) [3] [https://github.com/eligrey/classList.js](https://github.com/eligrey/classList.js)

</comment><comment> mike-- In my opinion jquery is a hell. Because jquery is only abstraction for browser features level (events, styles, dom), but it's ugly for writen complete code, for this need some like prototype.js or mootools, because it's have oop-style level for browser.

</comment><comment><USER58> I implore all developers to learn native Javascript methods, because I strongly believe jQuery has created a generation of developers who know the library but not the language. You'd be surprised how many developers I've come across think iterating over an object or array requires Javascript and how many people don't know how to write a simple for or while loop in Javascript. jQuery is a fantastic library, but it is by no means a cure-all for Javascript problems.

Now about this site itself. This is a great idea getting people to use and understand native methods, but please also understand that native methods aren't always necessarily the most efficient choice. There are a few of parts of this site I think send the wrong message. Don't get me wrong, I think this is great, but sometimes native methods are no better than jQuery's.

The first one being jQuery's each method. It is a known fact that jQuery's each method is extremely slow, it works, but from a optimisation perspective native ways of looping an array are always the fastest and most efficient.

The alternative given for a jQuery.each statement is the IE9+ supported Array.prototype.forEach — now you'd think this would be faster right? It's actually still not as performant as it could be. As this jsPerf set of benchmarks shows is that a for loop is the most performant option: [http://jsperf.com/foreach-vs-jquery-each/38](http://jsperf.com/foreach-vs- jquery-each/38) — it might not be as pretty as jQuery.each or Array.prototype.forEach, but heck, it's a whole lot faster than the alternatives.

The second being the use of querySelectorAll (which is awesome btw). It has similar capabilities to that of jQuery's native wrapper for querying, it looks just as nice, but once again the performance isn't all that great. Looking through multiple jsPerf benchmarks, querySelectorAll is rarely the best option to use in most cases. This is an example of one: [http://jsperf.com/queryselectorall-vs- getelementsbytagname/4...](http://jsperf.com/queryselectorall-vs- getelementsbytagname/44) — if your selector is extremely complicated, think to yourself, how can I make this easier to write? Do I need to query a chain of five classes and use CSS3 selectors, or can I just add an ID to the element I want and query it using document.getElementById instead.

Sometimes jQuery is needed though. It saves considerable amounts of time, especially when the budget of a project is tight and timeline is even tighter and you just need to get something out the door as soon as possible. If you have the time to properly build whatever it is you are building, consider spending that extra 15 seconds writing a for loop to iterate over that array or object.

And to those who understand and have taken a look into the internals of how some jQuery methods work like document.ready, you'll appreciate and know just how many different browser quirks the jQuery team have solved for us. There are quite a few methods where jQuery hides the gory details of a sometimes difficult to get right across all browsers feature.

Personally my favourite thing about Javascript is the power of documentFragment: [https://developer.mozilla.org/en/docs/Web/API/DocumentFragme...](https://developer.mozilla.org/en/docs/Web/API/DocumentFragment) — this is something all developers who use Javascript need to know about. It helps prevent reflowing and redrawing as well as being extremely efficient and fast for modifying and inserting elements into a page.

Over all of this I think we all need to reflect on the state of Javascript. It's a whole lot more powerful and better than it was 10 years ago, but I think because of the likes of jQuery and others, people have become obsessed with pretty code and methods. I know for loops and prototype methods might not be as nice as your one line of jQuery code, but don't take the easy way out, because you'll soon find the longer your Javascript grows in your app/site, the slower it will become.

<comment><USER59> > I strongly believe jQuery has created a generation of developers who know > the library but not the language

i think you mean "know the library but not the DOM and additional HTML5 APIs" \- they are after all just native libraries. ES5/6 would be the "language"

<comment><USER60> JavaScript is a dynamic language, and it is arguably the case that many of the frameworks that exist for it hide or transform enough of the "native" implementation details as to be different languages. Or supersets of it, if you like. I don't think it's at all unreasonable to suggest that a developer who uses jQuery (or any other framework) doesn't have to have more than a vague, fleeting understanding of the "native" language under it.

<comment><USER61> Such a viewpoint would be ignorant of the distinction between a language and an API.

<comment><USER60> Yes, that's rather the parent's point, I think.

<comment><USER61> except "many of the frameworks that exist for it hide or transform enough of the "native" implementation details as to be different languages. Or supersets of it" is wrong. It's all still javascript. Just.. plain.. javascript. with a different api/library.

<comment><USER60> I don't think you understood what I wrote. And I'll leave it at that.

<comment><USER61> is there an alternative interpretation? you appear to be saying that a library can make javascript into a new or superset language.

Are you saying something different?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER62> I would still stick with jQuery because it lets me achieve more by writing less. Out of many things, just see triggering custom events. It'd be horrible if I'll have to write that piece of code again and again and make sure it's bug-free. And if I contain that long logic into a function for re-use, and use this approach for everything listed on the page, I'll end up writing my own library that I'll be including in each of my projects. Wait, why don't I use jQuery instead which is battle proven and better tested than my library ever will be?

</comment><comment><USER63> I think many commenters are misunderstanding the main idea here. This page makes a strong case if you're just using jQuery for a few things in your site. I can see people complaining "why would I write all that code again? if jQuery offers a beautiful API?" if you're just using jQuery to do a few simple things (Which I've seen all over the place among peers) then why not just write the native version? it's only a few lines and you're saving a whole library in your load process

</comment><comment><USER64> jQuery or <jQuery-compatible substitute> is one of the few things I don't have to think twice about before including in EVERY WEB PROJECT I EVER WORK ON before doing anything else.

Next up: you might not need <insert abstraction>.

Really?! What does "need" mean? Go write assembly.

<comment><USER56> <3 lol

</comment></comment><comment><USER65> Articles like this miss the _true_ genius of jQuery – that it basically wraps all DOM operations in a maybe monad. You get null safety for free.

<comment><AUTHOR> One could ask if that's actually a good thing.

You also get the same thing from the existential operator in coffeescript, if you're in to that.

</comment></comment><comment><USER66> Thanks for traversing the bounds of space and time and posting this blog post from the year 2018 when IE8 is no longer supported for enterprise.

<comment><AUTHOR> It will still be here when the world is ready

</comment></comment><comment><USER67> It's plain stupid. Your code may work for IE8+, but there is no warranty that M$ will not do something stupid in IE16, and your code will be broken. jQuery is unified bridge between all major browsers, so you don't need to support all of them by yourself. "Support for all" is why we shift from compiled to VM languages, even though at the begin they were slower.

</comment><comment><USER68> Related:

Uncoring the Native DOM API [http://blog.ponyfoo.com/2013/06/10/uncovering- the-native-dom...](http://blog.ponyfoo.com/2013/06/10/uncovering-the-native- dom-api)

Getting Over jQuery [http://blog.ponyfoo.com/2013/07/09/getting-over- jquery](http://blog.ponyfoo.com/2013/07/09/getting-over-jquery)

</comment><comment><USER69> There are many things you don't _need_ to do. I'll take the time saved in development over cutting out an extra framework.

<comment><AUTHOR> Like it says at the top of that page:

> jQuery and its cousins are great, and by all means use them if it makes it > easier to develop your application.

</comment></comment><comment><USER70> I'm psyched by the idea that you don't need a bloated framework, but between using Zepto as an alternative, as well as the fact that some of this information is just plain wrong (e.g. they claim that the classList API is supported by IE8+, when in fact it is only supported by IE10+), this won't get you too far.

</comment><comment><USER71> Please can we embed jQuery in browsers instead of the standard being to use Google's hosted copy.

</comment><comment><USER72> Some of the examples are flawed. The ajax one for IE8+ is a big red flag, it's not _as_ easy as that.

However, operating in the world without jQuery is scary for a new developer. I think it has its utility.

Note: I tend to prefer not to use jQuery, especially with AngularJS around. YMMV

</comment><comment><USER73> I feel empathy for the OP, for two main reasons:

1) The fact that some people don't realize that JavaScript != jQuery scares me.

2) jQuery born when cross-browser compatibility was a mess and today it still carries that weight. I think nowadays it needs to be more modular and less monolithic.

<comment><USER46> > 1) The fact that some people don't realize that JavaScript != jQuery scares > me.

DOM != Javascript

That's the thing you dont understand and makes you say silly things.

</comment></comment><comment><USER74> I think this is great, i was also thinking of replacing jquery functionality in some of my scripts with native methods and this helps me alot.

One question though, what is the pure javascript equivalent of $(document).on('click', '.selector', function() { // do something });

This is the new jquery .live() replacement and i need it because normal events stop working after async postbacks (eg. from an asp.net UpdatePanel).

Will this code do the trick if i attach it to the document element? Also i need IE8+ support :)

function addEventListener(el, eventName, handler) { if (el.addEventListener) el.addEventListener(eventName, handler) else el.attachEvent('on' \+ eventName, handler) }

addEventListener(el, eventName, handler)

</comment><comment><USER75> I'm a little sad to see that nowadays there's a strong sentiment of "just use the pre-packaged tool", whereas when jQuery was still in its infancy, there was a lot of lively hacker-minded chatter on the down-and-dirty of getting things to be cross browser.

It's as if there are now two "levels" of people - "regular developers" and "framework designers", and only the latter are really supposed to know about the nitty-gritty. The excitement of finding out about standard, cross-browser gems like insertAdjacentHtml is all but gone :(

I get it that people are focusing more on the entrepreneurial side of things now, but I miss the banter of aspiring tinkerers.

</comment><comment><USER76> You might not need [Insert Library Here].

Although this is true, you don't really need any library. The problem comes when you start to need that library. You make a decision to not use it at the start of the project and then the dependency of lower level JS functions grow and it turns out you do need it. What do you do then? Go and get a copy of jQuery and start to rewrite all your functions?

Hindsight is the problem here, I'd rather make the decision to use the (relatively) low sized jQuery library and not have to worry about how the project grows.

As the old saying goes, "It's better to have it and not need it, than need it and not have it".

</comment><comment><USER77> I see a lot of people in both camps on this one.

It seems to me that if you are making a library, and therefore do not want to make assumptions about the availability of jQuery, one potential solution would be to go the route of AngularJS[1] and have a 'soft' dependency on jQuery.

In this instance you would use jQuery if it was present, but fall back on the code found in this submission if it wasn't.

Are there potential downsides to this solution that I am missing?

[1]: [http://docs.angularjs.org/api/angular.element](http://docs.angularjs.org/api/angular.element)

</comment><comment><USER78> Apart from size and many functions that translate 1:1, where it really doesn't make sense to use Jquery (time to learn ?) there are two extra factors: 1\. the extra http call to load a library, that can be optimized 2\. licensing, some company cares about that and avoid the the hassle of having yet another license to understand and manage, there are costs involved

I've seen thousands of js snippets using jquery just because the developer doesn't the pure js syntax, or because he is used to start from adding jquery.

very good page indeed, thanks for spreading the knowledge.

</comment><comment><USER79> This is a great resource, even though it's not really about jQuery, it's about the success of HTML5. The fact that we have a working DOM, XHR, and a better understanding of polyfills in general does tip the balance away from depending on a "fix it" library.

I can see myself reaching for this page a lot. And the author has a point as the only reason I used Zepto on my last project was one of the libraries I needed used it.

If I am gonna use a fix it library today, it's more about nodejs/browser compatibility than worrying about browser issues.

</comment><comment><USER80> FWIW, I was on a jQuery-hating kick before I read this article, which explains some of the beauty behind the jQuery api.

[http://coding.smashingmagazine.com/2012/10/09/designing- java...](http://coding.smashingmagazine.com/2012/10/09/designing-javascript- apis-usability/)

I agree that you probably only want to use a small subset of jQuery (e.g., none of the UI, none of the transitions), and zeptojs is actually a really good alternative. But it really does provide some convenience.

</comment><comment><USER81> document.title.replace("You","Your JS library");

</comment><comment><USER82> I've never liked jQuery. I use it because I am forced to. However, I will not write my own animation library, selector engine, and other helper utilities it provides.

<comment><USER5> You don't have to. Browser manufacturers wrote an animation library (CSS3 transitions & animations), selector engine (querySelectorAll) and other helper utilities it provides.

</comment></comment><comment><USER83> Well... I don't like this trend. I saw project once where main frontend guy decided to do stuff without jquery and etc. He said that vanilla.js is nice and people just don't get it. After project was done it worked only in firefox properly. Lot of time was spend after that to implement fixes for different browsers. So don't do that. Don't use vanilla js. Size of jquery is issues? Well you are trying to solve problem that does not exist.

</comment><comment><USER84> I wondered to myself, why did he create a custom website just to present this? It seems like a great way to position yourself as a skilled front-end developer and advertise your services to potential clients. I suppose it could also have been done out of some kind of altruism, but I'm guessing the former.

Either way, this is pretty neat, and I'll probably be bookmarking it. We're using ClojureScript now and migrating away from jQuery, so this may prove handy.

</comment><comment><USER21> The important part of ditching jQuery isn't the load time, it's aiding the transition from monolithic libraries to loosely-bound components.

</comment><comment><USER85> Sometimes doing it yourself makes sense. But most often using a well tested battle hardened tool is better. I rarely if ever build my own car.

</comment><comment><USER86> Seeing how many of these hand-picked trivial code examples are still made easier by jQuery just makes me want to use it all the more.

</comment><comment><USER87> If you only care about IE such as inside corporate intranet, and never had to worry about cross browser compatibility, knock yourself out. On the other hand, the scalablity and performance on the intranet usually are not a high priority. Why not just learn jQuery rather than tight yourself up to vender specific, proprietary technology?

</comment><comment><USER88> One thing I haven't seen mentioned in this thread, is that you can create custom builds of jQuery that only include some of the functionality: [https://github.com/jquery/jquery#how-to-build-your-own- jquer...](https://github.com/jquery/jquery#how-to-build-your-own-jquery)

</comment><comment><USER89> I may not need jquery for compatibility, I need it because it makes code in a language I find unesthetic and unconsitent more readable. Yes I can do vanilla JS, but my productivity and readability in jquery is better. And this site proves my claim: all their vanillaJS exemple are less expressive and more error prone.

<comment><USER90> Isn't the message about libraries?

</comment></comment><comment><USER20> What?

> $('<div>').append($(el).clone()).html()

vs

> el.outerHTML

Why not $(el)[0].outerHTML?

<comment><USER91> What if $(el).length === 0?

<comment><USER20> This check is required in both cases. el.outerHTML assumes that el is not NULL (which it could be as a result of getElementById, for example).

</comment></comment></comment><comment><USER92> DOMContentLoaded doesn't even get close to the jQuery counterpart $(document).ready. To start if the DOM is already loaded DOMContentLoaded won't fire and won't call the callback. On the other hand ready will notice that the DOM is loaded and fire the CB right away.

</comment><comment><USER93> Most CSS Frameworks require jQuery. Most designers are familiar w/ jQuery. If you use CDN, some other app likely downloaded jQuery already.

People that are not fans of jQuery are people that are are only familiar w/ MVC on client side and are not using APIs (ex: Parse, Kinvey, etc.)

</comment><comment><USER94> In my personal projects (and clients' too unless paid extra), I target for modern browsers + IE10 and haven't used jQuery for long time. Native APIs are good enough once you get used to them. Actually jQuery starts to feel cumbersome (this binding in .each() etc).

</comment><comment><USER95> Awesome site with clear message. +1

</comment><comment><USER96> What's a good resource to read up on how browsers handle unsupported JS, if I want to write a fall-back?

I've already got fall-back for people who've turned off JS, but I've yet to write anything for unsupported JS.

<comment><USER43> This might be overkill for you, but take a look at [http://modernizr.com/](http://modernizr.com/)

Sometimes it's just as simple as testing if the function your about to call exists before you call it.

</comment></comment><comment><USER97> Sure, why use something stable that everybody knows and loves to use, while you can just add in your custom half-baked solutions.

In a post IE8 world adding a minified jQuery library is not a big deal.

</comment><comment><USER98> Shouldn't you set request.onload before calling request.send?

</comment><comment><USER99> Boy, these snippets are really cool! Some of them are a bit longer in vanilla JS, though, so I think I'll wrap them in a utility of helper functions.

Oh wait -- that's what jQuery is!

</comment><comment><USER100> I don't get it. From the examples it seems that the jquery way of implementing things is much easier and more concise. Isn't that the entire point of a library?

</comment><comment><USER101> My contribution here is that we have a possible acronym troll on our hands.

        Y[t]MN(NJ)

"You're [the] man now, ninja!"?

As in: _Code ninja_?

Re-use is fun. See?

</comment><comment><USER102> [Component]([https://github.com/component/component](https://github.com/component/component)). That is all.

</comment><comment><USER103> I'd love to use a jQuery 'lite' version, just for the convenience and brevity of expressions. Some of it should be baked into javascript.

</comment><comment><USER104> jQuery's overhead is so minimal. Also, virtually every example of pure js was more verbose. jQueries selectors alone is such a great selling point.

</comment><comment><USER105> It's probably better to have it than not if you're going to be using AJAX, as at least jQuery implements promises (after a fashion).

</comment><comment><USER106> The worst are things packaged as jQuery plugins that don't actually need to be a plugin, or even use much of jQuery at all.

</comment><comment><USER107> jQuery still has it's uses... like when it's essential to have consistent support across browsers old & new. However I much prefer to tell users who insist on using out-of-date/poorly-built browsers to upgrade or fuck off, hopefully gently encouraging them to do so.

</comment><comment><USER108> It'd be cool if you could search a URL and it would analyse whether you need JQuery or not.

</comment><comment><USER109> Chaining and implicit iterators.

<comment><AUTHOR> Since I've started using an MVC, I use chaining less and less. I tend to just use a variable the few times I need to do a bunch of manipulation to the same element. Beyond that, any chain using .end is nuts to me.

</comment></comment><comment><USER110> There is a mistake in Matches section. The `is` method is not equal to `===` operator.

</comment><comment><USER111> forget it, i rather just use the jQuery

i have better things to do than merely writing my own dependency

</comment><comment><USER112> Man, the front-end developers really came out of the wood-works for this one.

</comment><comment><USER113> Why code with Rails instead of raw Ruby? Why code C++ instead of C? Why use Boostrap?

Choose one:

\- Performance

\- Rapid development

</comment><comment><USER114> In first example:

> data = JSON.parse(request.responseText)

Maybe "var data = ..."?

</comment><comment><USER115> Actually, you just showed me why I DO need jQuery. Thanks. :)

</comment><comment><USER116> I should probably register pleasedontusejavascript.com

</comment><comment><USER117> drop jquery and repeat yourself everywhere

</comment><comment><USER118> the dom traversal/chaining in jquery is a big reason why I use it. The native API simply isnt as nice.

</comment><comment><USER119> Next up: You might not need warm water.

</comment><comment><USER120> no one "needs" jQuery.

</comment><comment><USER121> [https://cloudup.com/cSLcmVC5F9h](https://cloudup.com/cSLcmVC5F9h) <\--- Def not a good example. hehe Great website, though.

</comment><comment><USER122> AngularJS is all you need.

<comment><USER123> Citing the AngularJS FAQs _:

Does Angular use the jQuery library?

Yes, Angular can use jQuery if it's present in your app when the application is being bootstrapped. If jQuery is not present in your script path, Angular falls back to its own implementation of the subset of jQuery that we call jQLite.

Due to a change to use on()/off() rather than bind()/unbind(), Angular 1.2 only operates with jQuery 1.7.1 or above.

_ [http://docs.angularjs.org/misc/faq](http://docs.angularjs.org/misc/faq)

</comment></comment><comment><USER53> I would glad to see a youmightneedclojurescript.com.

</comment><comment><USER124> Or in other words: YMNNJQ</comment>


Show HN: React-like Components for iOS - <AUTHOR> https://github.com/s4cha/Komponents <comment><USER2> Nice! But seems still needs a long way to go.</comment>


Making a Raspberry Pi-Powered AI to Play Piano - <AUTHOR> https://rpiai.com/piano/ <comment><USER2> Those interested in computer generated music may find some pragmatic ideas in this paper from 1989:

[http://peterlangston.com/Papers/amc.pdf](http://peterlangston.com/Papers/amc.pdf)

<comment><AUTHOR> Thanks this is wonderful! I think my implementation is very close to the "riffology" described in the paper. Lots of other great ideas in this to pursue!

</comment></comment><comment><USER3> I wonder if the author has considered connecting it to more sophisticated models. Carykh, for example trained a lexical RNN to read transcribed MIDI, specifically training it to learn jazz.

<comment><AUTHOR> Yes, I plan on adding something like this in the future! However, my goal is to do learning in real-time in the style of the current pianist. NNs need quite a lot of data to train correctly so it might be hard to do in realtime. Although there could be a neat hybrid (some kind of iterative NN...).

<comment><USER4> You could try this - it has online/realtime learning and runs on little resources (including raspberry pi)

[https://github.com/ogmacorp/EOgmaNeo](https://github.com/ogmacorp/EOgmaNeo)

<comment><AUTHOR> That looks awesome! Thanks.

<comment><USER4> No probs. Looking forward to playing with what you build :)

</comment></comment></comment></comment></comment><comment><USER5> The best part of this whole post was the approach the OP took to actually design this. A methodical process of writing the design document, Prototyping with Python and then rewriting the application in Golang to take advantage of speed. Which begs my question to the Sw folks in this thread, why is Golang faster than Python?. I didn't realize that Golang compiler was available for ARMV7 devices such as RPi.

<comment><USER6> That's not "begging the question," it's "raising the question."

[https://afterdeadline.blogs.nytimes.com/2008/09/25/begging-t...](https://afterdeadline.blogs.nytimes.com/2008/09/25/begging- the-question-again/)

</comment></comment><comment><USER7> Can't you use the generative adversarial networks?

Where the discriminator IA would learn to identify good melodies from real data. After that, the generator would try to make a good melodie to be approve for the discriminator IA. Thus you could play the generator melodie .

<comment><AUTHOR> Yeah, I'm thinking about trying this too. I think this is like Google's approach for A.I. Duet.

</comment></comment><comment><USER8> Next step is to rig up some mechanisms to pull the keys down and we have a modern day pianola that can improvise. Fascinating. Should be not too difficult to play blues or other pentatonic melodies, since they lend themselves well to improvisation. Using tabs or music from blues legends such as Stevie Ray or BB King would likely yield some very interesting results.

I find it interesting that we start with teaching AI music the same way we oftentimes start with children, the pentatonic scale, because it's simple and more difficult to play the "wrong" notes.

</comment><comment><USER9> The author may have been led down a blind alley when he (?) infers from a screenshot that Dan Tepfer is using Processing for this. You can also see that he's running SuperCollider (the icon on the right-hand side of the list of apps), a programming language oriented around procedural music composition and sound synthesis, which is to my mind a much more natural fit for this kind of work.

<comment><AUTHOR> Thanks! I didn't know about that! I will update the article and check out SuperCollider :)

</comment></comment><comment><USER10> amazing work and great documentation OP. thank you.

consider emulations of your piano playing on two interconnected systems, each conceiving themselves as the AI and the other player as you.

initiate one of the AI using a masterpiece of yours, unknown to either. would that be considered putting your current state of pianoplayership into silicone?

<comment><AUTHOR> Oh this is a neat idea, thanks! I may have to try this too.

</comment></comment><comment><USER11> The method of paper to code is really interesting. Does anyone have additional articles or books about this method?

<comment><AUTHOR> I do not know of any formal methodology. Personally I just feel like I can think better when I draw things out.</comment></comment>


Nitrogen 2.x Released (Erlang Web Framework) - <AUTHOR> http://nitrogenproject.com/whatsnew

<comment><AUTHOR> I've been using Nitrogen now for close to a year, and I've been anxiously awaiting 2.0, particularly the improved support for multi-node servers.

I've got a couple of startup-type projects I'm working on that will be using Nitrogen, though none of them are production ready yet.

Based on the documentation, it looks a bit easier to get up and off the ground as compared with 1.0, since it looks like it can be packaged as a self- contained system (packaged with the web-server and erlang binaries, if I read that correctly).

Overall, I'm very excited about this.

Thanks, Rusty!

</comment><comment><USER2> What are the advantages of Erlang for this kind of application compared to something like Django or Rails? From what I can tell Erlang's syntax isn't as nice for typical CRUD/string processing tasks and, unless you're doing some kind of distributed web app, it's not obvious to me how relevant Erlang's excellent support for distributed applications is.

Can somebody with more experience make the case for me?

<comment><USER3> The advantages of Erlang are not limited to distribution, but also excellent concurrency. By this, I don't necessarily mean high throughput and amount of queries served per second, but a general resilience over high loads.

Because every task can be broken into bits running concurrently (note: not necessarily in parallel, just concurrently) and because the Erlang VM has full control of the runtime, there is a general good load balancing where the applications remain responsive (although slower) over high load, rather than just dropping calls.

Another part comes from the high reliability. Of course a broken app is annoying. Fortunately, there are a lot of technologies with stuff like load balancers and whatnot that make it easy to scale in any language and deploy new releases without downtime no matter the kind of code you use. By doing this, the burden of high reliability and scalability is often moved to the database layer. An Erlang web app won't shine that much from this perspective -- the DB might do the heavy lifting.

However, the way exceptions are handled with Erlang and its supervision trees changes the way you write programs. You only program for the cases you know how to handle. For the others, you "let it crash." This is a bit weird at first, but what this really means is "only fix the errors you know how to fix" -- the runtime is made to support living with the other kind of errors.

The other aspect of using concurrent actors to do error management is that it shifts the perspective of where exceptions are to be handled. In most languages, exceptions are managed from within the execution flow of the program:

                   main
            (top level try catch)
                    |
                some code
            (might catch errors)
                    |
              deeper calls with
             own error management

The problem with this is that your regular code needs to handle outstanding errors on every level or you just delegate the burden of making things safe to the layer above until you end up having the eternal top-level try catch (it's more complex than that obviously). Erlang supports this model too. However, it also supports supervision trees, which change the structure in the following way:

         some actor   </comment></comment><comment></comment><comment></comment><comment>- supervisor
               |                                     > supervisor
           some code  <--> other actor -- supervisor
               |               |
         deeper calls      more calls

(I hope the drawings are clear)

Here what I mean to illustrate is that actors who run code are being supervised by other concurrent 'supervisor' actors who are dedicated to handling errors that won't be handled by 'worker' actors. They can restart dead workers, notify the user or a logging system of a problem, propagate the killing of workers to dependent ones, etc.

This means the burden of error handling is shifted from within your standard and correct execution path to a concept litterally parallel to it. This lets you organize your code towards non-defensive programming while keeping it more stable at the same time.

This is not to say standard exceptions are not the way. They're still pretty useful. However, there is more than one class of error that can happen in software, and I think Erlang deals with this beautifully.

In my opinion, this concept of supervision trees is what Erlang really is about. People come in for the concurrency, but they stay for the supervision trees.

<comment><USER2> Interesting. Thanks for the detailed response. When I rank about my current pain points in web development smarter error handling isn't very high on the list, so at least for the work I do this isn't a particularly strong selling point. I can imagine for some apps it might be more important though. The ease with which an Erlang stack could support Comet apps might be too.

The area in which I'd really like to see some new ideas is the impedance mismatch between the DB, the business rules, and the HTML user interface. I feel like at least half my code in a typical web app is just glue to make all these layers behave consistently. Any platform that could make that more natural would be very attractive.

<comment><USER3> Well, Erlang has its own database that can store Erlang terms (see mnesia). As you can save some there for the impedance mismatch.

Nitrogen itself deals with reducing the differences between your backend code and the frontend. See the demos and their source code for examples: <http://nitrogenproject.com/demos>

Erlang also makes it a lot more easier to model stateful applications. I've found the best way to make an active web app with Erlang is just to make a regular application for the command-line (or the Erlang shell), and then add bindings to a web-server.

Because every block of code you have is independent, this is really easy to do. It makes every program extremely modular and I've rarely had the concept of 'code reuse' come so easily.

Maybe stackless python could be an interesting option under this perspective too, but I never used it for any project.

</comment></comment></comment><comment><USER4> This looks much more promising than the earlier version, last time it was far too much of a pain to setup, docs were scant, and I didn't like the web server interfaces that much.

Good job! I actually want to start playing with this now...

<comment><AUTHOR> Scant is a good word to describe the the state of the Nitrogen 1.0 docs. You definitely had to be willing to dive into the Nitrogen internals to find some things. The internal code was pretty easy to follow, so you could pretty easily figure out what you needed to do, but the external docs did indeed leave something to be desired.

I haven't played with 2.0 yet, since it's only a few hours old, but the docs do look a bit better so far.

</comment></comment><comment><USER5> Well, I am now working on one project adopting nitrogen, thanks for the hard working. Really enjoy the event driven programming style</comment>


Show HN: Blazing Fast Domain Name Search built with React and Elasticsearch - <AUTHOR> http://blazingfast.domains/ We wanted to provide an interface where people not in the domain industry could realize the huge number of domains that are now available on the market. The aim is not to give a 100% accurate search result but to give a quick overview of what is still available or not on a single string. The search is based on zone files and other static sources which don't include the premium names nor the "Trademark Claims"
I'm open to feedback of course!
Cheers. <comment><AUTHOR> We wanted to provide an interface where people not in the domain industry could realize the huge number of domains that are now available on the market. The aim is not to give a 100% accurate search result but to give a quick overview of what is still available or not on a single string. The search is based on zone files and other static sources which don't include the premium names nor the "Trademark Claims"

I'm open to feedback of course!

Cheers.

</comment><comment><USER2> I know this might sound pretty stupid but at first glance it's not completely obvious that the words listed below the search box are the domain extensions. A lot of folks not in the domain industry have no idea there are so many possible extensions. I think it's because I'm used to seeing exts listed with the preceding dot.

</comment><comment><USER3> It looks good, but the results are mixed.

Premium/pre-registered names are shown as available when they are not, similarly other names that are registered show as available.

(Example of the former "edinburgh" shows ".pictures" is available, but it is a premium-name. Example of the latter dns.zone shows as being available but it is not.)

<comment><AUTHOR> Thx for the feedback, Steve. I know, this is part of the side effect of using zone files as main data source. We tried to import most of the blacklisted domain lists we were able to find. Concerning the premium unfortunately the registries didn't want to share their list with us as we are not an official accredited registrar.</comment></comment>


Remote Learning Isn't Remote Schooling - <AUTHOR> https://brendancahill.io/brensblog/remotelearning <comment><USER2> Totally agree.

The ROI from the outdated conventional schooling model is minimal compared to what is now possible.

<comment><AUTHOR> I agree. I think alternatives like Google Cert, Lambda School and other coding school alt certifications or altMBA's will continually widdle away at the strangle hold that colleges once had on opportunity.</comment></comment>


Ask HN: Does your company renew option grants after initial ones vest? - equity-q-1212 Just hit four years at a startup and was expecting to receive another options grant to replace my now completed grant, but was disappointed to see it doesn't work that way. What does your company/startup do once your initial option's grant is complete? <comment><AUTHOR> Mine stopped after 4 years. 20 employees, Europe. New hires for senior positions preferred clear bonus structure while new hires for junior positions hardly understood stock option legal documents. The company was running profitable, there was no exponential growing or projects/pivots planed, company valuation wasn't expected to double and there was no clear exit path. In my opinion it was a good decision to switch from options to bonus payments/goals.</comment>


SpaceX Starship and the Von Braun Rotating Space Station - <AUTHOR> https://www.youtube.com/watch?v=vTNP01Sg-Ss <comment><USER2> Wow, this is pretty amazing. How did I not know about this!</comment>


Ask HN: When to disclose shameful felony during interview process? - <AUTHOR> As someone with a very strong software background and a recent felony, I'm wondering what your advice is in securing a local tech job. When should I tell interviewers? Is it even possible to get a tech job ever again? The last person I interviewed with canceled my second interview because she found out about this through google, and suggested maybe I look into contracting, but that sounds just as unlikely because of how easy it is to google me. Should I tell interviewers during the first introductory 30 minute phone call? Would this kind of red flag completely stop <i>you</i> from hiring someone who otherwise seems very qualified? What would make you more likely to keep moving forward with them? <comment><USER2> Have you tried blogging and pushing those results off the first page. Sign up for every social media account you can with your real name and location and then create little snippets to post to them to push everything down.

</comment><comment><USER3> > As someone with a very strong software background and a recent felony, I'm > wondering what your advice is in securing a local tech job.

Local...where? (That may help people with appropriate local knowledge give more specific advice.)

While the pay may be worse, you may have better luck with public sector tech jobs (they will certainly consider the offense in hiring decisions, but they may be less likely to use it as an arbitrary complete disqualification.)

</comment><comment><USER4> Can you ask Google to remove your links? It is possible depending on countries. The legal ground is once a person has paid back to society they are just like any other person and they have the right to be forgotten [0].

[0] [https://en.wikipedia.org/wiki/Right_to_be_forgotten](https://en.wikipedia.org/wiki/Right_to_be_forgotten)

</comment><comment><USER5> When you have a record, there's almost always a middleman in the way of you getting a job. Most of the time, that's H.R.

HR is _NOT_ your friend. That is another conversation entirely.

If you cannot find someone to give you a break for a job, then I'm betting your best bet will be to remove the middleman, and go the self-employed route.

It is _NOT_ easy, but it can be more lucrative and rewarding.

Good luck.

</comment><comment><USER6> Depends on the specifics. What did you do?

<comment><AUTHOR> Suffice it to say it isn't something that makes me a risk to the employer, but it's also more awkward to discuss than other felonies.

<comment><USER7> Of course how much you disclose is totally your business, and I can't speak for the person you're replying to. But for me this isn't enough to go on, because your questions seem to be about others' perceptions of this as a risk.

</comment></comment></comment><comment><USER8> Move to Europe or some other place. Likely nobody will care at all about your past. Change your name.

<comment><USER6> Getting a visa with a felony is basically impossible.

<comment><USER8> Wow, that's a pretty dirty move. That means that about 1/3rd of all Americans can not travel abroad.

</comment></comment></comment><comment><USER9> This might be a useful resource:

[https://news.ycombinator.com/item?id=14911467](https://news.ycombinator.com/item?id=14911467)</comment>


Prediction: Google and Apple go to War. - <AUTHOR> http://thenextweb.com/2009/07/08/prediction-google-apple-war/ <comment><USER2> This is my second-favorite rumor ever, because it keeps coming up (Android vs iPhone, Gmail vs MobileMe, AppleSecretSearch vs Google Search) and because the origin of it is: There are two supercool companies, and people would rather see supercool things duke it out violently than have a quiet amicability wherein the CEO of Google is on the Apple board. Fact is, Google and Apple excel at two different things. Google can't release any product at Apple's price point because they can't achieve such an anal level of quality, Marissa Mayer's 30 shades of blue be damned. Apple can't compete directly with Google because they insist on making pricey products that cost money, and because making a free suite of things completely contradicts their philosophy.

My _favorite_ rumor is the Apple vs Nintendo rumor, because first off it makes more sense (iPod touch vs DS), and second off because both companies make excellent products but design them from different points of view, Nintendo focusing on innovative gaming and Apple focusing on its outright perfectionism. The one that _would_ be my favorite rumor but is absolutely true is Google vs Facebook, and that's the one that interests me most if Google's making its own OS. Facebook acquired Parakey a few years ago, and since then rumors of it launching a webOS have been scattered about. Interesting to see how they take advantage of this announcement.

</comment><comment><USER3> No more than Toyota and BMW are at war.

Regardless of how good Google's products get, their core business doesn't involve building the products that Apple is building. And even if beige box PCs came with an operating system and applications that better compared to a Mac, they'll still lack that integrated quality-assured ecosystem joining them together.

E.g. For the average user, a web-app-focused OS is going to have even _more_ confusing UI inconsistencies than Windows.

<comment><USER4> For a war to exist you have to have a frontier.

The 'google' territory centers around eyeballs, ads and possibly at some point in the future paid services (though it looks like google wants to avoid that).

The 'apple' territory is a unified media presentation vision centered around slick hardware and a common user interface design.

The 'microsoft' territory is mostly (xbox) centered around licensing software.

All three companies have a completely different take on how to make money of their IT business. Sure there are overlaps, and for sure there will be users crossing over from the one service to the other.

But if this were a 'real' war google would be selling hardware (or worse, giving it away), Apple would be getting in to the search business and microsoft would be going for the eyeballs at the expense of their licensing strategy.

Some of this is happening, but at least for the foreseeable time things are relatively stable and market shares will slowly fluctuate, no 'mass casualties' are expected.

For an idea of what happens when there is a war check out what happened to digital research, netscape and altavista. Skirmishes, yes, sure. War ? Definitely not.

</comment></comment><comment><USER5> The site has a ad banner with sound, very intrusive, 'congratulations, you won!', it may embarrass you if you open at work.

<comment><USER6> And the article is not worth enduring the torture (hint: use the Readability bookmarklet on such pages if you really want to read them).

thenextweb.com had been banned here before, and I think it should be again:

<http://news.ycombinator.com/item?id=637738>

</comment></comment><comment><USER7> Google sells ads. Apple sells hardware.

<comment><USER8> They both make operating systems, browsers, and web apps.

<comment><USER9> I think they'll be more like Intel and Microsoft. They'll benefit each other. Hopefully, they'll keep benefitting us.

</comment></comment></comment><comment><USER10> This is not an article. It's just some guy talking. There is not a _single sentence_ in this post that would not be improved by asking the question "Why?"

 _Today saw the announcement of ... something I've wanted for quite some time; an ... OS with the web and Google's services as its backbone._

Why do you want this? Is there something wrong with your current method of accessing Google's apps? What is it? What do you expect this new OS to improve?

 _The move by Google is sure to leave Apple and Microsoft shaking in their boots_

Why?

 _I'm certain this is the beginning of the end for Ubuntu._

Why?

 _Since the increasing development and improvement of Google Apps, the increased speed of Chrome, the release of Android and now, the Google OS. I'm left torn._

Why? What do these technologies have to do with one another? Do they interoperate? What do they offer you that you didn't have before?

 _My current commitment to Google Apps has left me ... entertaining ideas of what it would be like to truly incorporate all my primary web services into an operating system_

What _would_ that be like? What benefit would it offer? Why do you want this?

 _I'm left wondering what Apple can bring to the table between now and Google's OS release_

What should they bring? What does the new Google OS offer that you think Apple should incorporate in OS X? Why would that improve it?

 _The point is this. As long as Google and web applications continue to improve at the rate they are, [Apple is] going to have to start thinking far more Google-like._

For love of all that's good, _why_?! What does it mean to think more google- like? What is wrong with how Apple is thinking now? What improvements is google making? How are those superior the improvements Apple's making (if, indeed, they are not completely orthogonal).

 _this is the beginning of an era of Google dominance, the likes of which we've never seen before_

Why?

 _The company is slowly but surely taking over every aspect of our lives ... for some its scary, for me... I'm excited._

Why?

 _And for now at least, the one company I want to see step up to Google's surge in dominance is Apple_

W-H-Y?

 _and I predict they will, but its not going to be easy._

Predictably: _why_?

I propose a new rule. If you're considering posting something to HN, think how a fifth grade teacher would mark it up. If there would be more red than black on the page by the end, maybe give it a miss?

</comment><comment><USER11> I really can't take such articles seriously anymore because they very simplistically confuse companies with tribes and competition with war...

Microsoft, Google, and Apple have figured out ways to make money in different ways. Whatever Google has to offer, it is going to help Apple and Microsoft further delineate what they do best. I hardly see this as "going to war".

</comment><comment><USER12> Apple was never going to be anything other than a niche player in the personal computer marketplace, and they knew it all along. Why else would they commit so many resources to co-opting the personal music and cell phone markets? Apple has already won the wars of its choosing.

<comment><USER13> You mean to say that Apple is first and foremost a hardware company.

<comment><USER14> I think Apple is first and foremost an industrial design company.

</comment></comment></comment><comment><USER15> The Google OS appears to be geared more toward business than the home user. I mean email / Docs / Spreadsheets? That's a business combo. The Mac has Music / Movies / Photos that's for home.

</comment><comment><USER16> Quote: "I'm certain this is the beginning of the end for Ubuntu and Linux"

It's funny how ex-marketing dudes, who now call themselves "social media experts", write crap just for the sake of it.</comment>


Front end engineer - core developer - <AUTHOR> http://www.tello.com/jobs You are a Ninja when it comes to JS/Ajax development.
You are not afraid to build well formed html and advanced CSS structures.
You are interested in mobile web app development with new cutting edge JS/html5 frameworks such as Sensa Touch and you care about cross phone portability.
You can get your hands into the C and the V of the MVC rails code to help control UI/REST API flows and work with more back end oriented engineers.
If you like the above, want to make a mark in the world by building world class products and like to work in a collaborative environment, we want to hear from you.
Must haves!

    Passionate about consumers and the mobile landscape
    Top notch analytical skills
    Appreciation for very well polished front ends
    Like to work on cutting edge technologies
 This position is in Palo Alto, CA.
Contact: email@example.com <comment><USER2> I've read the About page but I have no clue as to what Tello does. They do in fact need a UX mastermind.</comment>


An Open Letter to CloudFare, a company who has broken the entire Internet - <AUTHOR> https://gist.github.com/rtsisyk/ed1f8157fca1f2de64165d74aa0c802f <comment><AUTHOR> Medium.Com is totally broken for me:

```

HTTP/2.0 403 Forbidden Server: cloudflare-nginx <!-- CloudFlare Date: Sun, 24 Apr 2016 16:45:26 GMT Content-Type: text/html; charset=UTF-8 Set-Cookie: __cfduid=dbfe2964790ee51252ab642de294d32ea1461516326; expires=Mon, 24-Apr-17 16:45:26 GMT; path=/; domain=.medium.com; HttpOnly Cache-Control: max-age=2 Expires: Sun, 24 Apr 2016 16:45:28 GMT X-Frame-Options: SAMEORIGIN Strict- Transport-Security: max-age=15552000; includeSubDomains; preload X-Content- Type-Options: nosniff CF-RAY: 298b06918f1f2b8e-AMS Content-Encoding: gzip X-Firefox-Spdy: h2 ```

</comment><comment><USER2> It can really be annoying.. They break so many simple static websites that I can only use my phone for a limited ammount of websites (I use orfox with orbot and noscript, as I'm a little paranoid phone-wise)

</comment><comment><USER3> "We do have a fancy solution that we are working on, but I don't want to make a specific promise yet." \- CEO of CloudFlare [1]

But read the discussions [1][2], it doesn't sound like they are looking for a good solution.

[1] [https://trac.torproject.org/projects/tor/ticket/18361](https://trac.torproject.org/projects/tor/ticket/18361)

[2] [https://news.ycombinator.com/item?id=11404770](https://news.ycombinator.com/item?id=11404770)

<comment><USER4> "We do have a fancy solution"

That's never a good sign.

</comment></comment><comment><USER5> Relevant discussion :

[https://news.ycombinator.com/item?id=11404770](https://news.ycombinator.com/item?id=11404770)

<comment><AUTHOR> I'm not TOR user.

</comment></comment><comment><USER6> What is CloudFare?

<comment><AUTHOR> Ohh, yes, CloudFlare. Sorry.</comment></comment>


Relevance Blog : Hacker-in-Residence - <AUTHOR> http://blog.thinkrelevance.com/2009/11/11/hacker-in-residence-update-and-call-to-action <comment><USER2> I hadn't heard about this before now. What a cool idea.</comment>


Show HN: An ORM for Python objects, inspired by Django - <AUTHOR> https://github.com/onyb/reobject <comment><USER2> So it makes abstract objects into more abstract objects? Is that the idea?</comment>


The Curse of a New Building - <AUTHOR> http://steveblank.com/2009/05/15/supermac-war-story-11-the-curse-of-a-new-building/ <comment><USER3> I'd also like to say that this also happens with churches. Every church I've enjoyed didn't own their own building. Rather, they just rented space from the local high school, etc. These groups were extremely focused on building tight- knit communities, and were pretty free to adapt to changing circumstances. Conversely, I can think of a few churches with buildings, where the primary focus of the staff was maintaining enough donations to pay the mortgage.

This sort of phenomena applies to other communities in addition to technology businesses.

<comment><USER4> Generally agreed, though I can think of one example to the contrary.

The churches that rent are usually newer and growing. The much loved idea that a startup is a better place than a well established organization works for churches too. I also heard that (IIRC) a church just about doubles in size when it gets a building. I don't know what analogue that has in the business world.

(Protip: Rent from a Catholic highschool, even if it's a Protestant church. Lower prices, smarter people.)

</comment></comment><comment><USER5> This is one of Parkinson's Laws: "perfection of planned layout is only achieved by institutions on the point of collapse."

In the chapter "Plans and Plants" of "Parkinson's Law" (see [http://www.amazon.com/Parkinsons-Law-Cyril-Northcote- Parkins...](http://www.amazon.com/Parkinsons-Law-Cyril-Northcote- Parkinson/dp/1568490151) ) he makes the point that

"During a period of exciting discovery or progress there is no time to plan the perfect headquarters. The time for that comes later, when all the important work has been done. Perfection, we know, is finality; and finality is death."

Parkinson reviews a number of headquarters buildings: League of Nations, Pentagon, St. Peter's Basilica, Versailles,.... He concludes that their completion marked the sunset of the organizations that they were intended to house.

<comment><USER6> Absolute rubbish. I can give you just as many anecdotes to the contrary, viz.: Microsoft, Apple, Oracle, all of whom had reasonably perfect offices two decades ago.

<comment><USER7> Parkinson published his book in 1958 :)

One imagines that there were counterexamples even in his day, though. Can anyone think of some companies that were rising stars in 1958? Did they have nice offices?

</comment></comment></comment><comment><USER6> Jeez, I hate this attitude... that the only way a company can succeed is if you suffer. You spend all friggin' day at the office. It doesn't have to be a coalmine for the company to succeed. On the contrary. When a startup gets to the point that it needs to recruit the top talent, it better have nice working conditions. Look at Amazon today... crappy offices, pride in using doors as desks, and huge turnover among the development staff. Where are the Amazon engineers going? Google and Microsoft.

<comment><USER8> Do you have more insight into why Amazon's turnover is so high? I'm starting there fairly soon, and things look pretty peachy on the outside, but I am aware that for some reason or another people up and leave after about 2 years.

I honestly didn't mind the office - cramped sure, no fancy furniture sure, but I'm there to work, not marvel at the finishing and grain on my desk...

I do agree though, IMHO from the article the biggest loss was putting people into their own offices - but that's a failure in planning and understanding the company's development dynamics, not necessarily in the very act of moving.

</comment></comment><comment><USER9> So is it a case of "damned if you do, damned if you don't"? How do startups expand when they really have outgrown that little hole in the wall without losing the startup culture that allowed the initial success?

Is the curse of the new building unavoidable?

<comment><USER10> The title is misleading.

The article is really about excess spending.

Yes, if you spend excessively you're damned. No, you're not damned if you don't spend excessively.

<comment><USER11> It's about more than excessive spending:

"The new building telegraphed to our employees, "We've arrived. We're no longer a small struggling startup. You can stop working like a startup and start working like a big company." We started to believe that the new building was a reflection of the company's (and our own) success. We took our eye off the business. We thought that since we in such a fine building, we were geniuses, and the business would take care of itself."

Even if you had a modest new building and didn't give every engineer his or her own office you still might observe this.

But I think probably by making a serious effort to preserve the culture and values of the company that existed pre-new-building you could avoid the "damned if you do" piece.

<comment><USER10> This is absurd:

"Now every engineer can have their own office."

NOT INEVITABLE--EXCESSIVE SPENDING

"The new building needs to reflect that we're a successful and established company. Lets "do it right" and have a lobby and reception area that projects a professional image."

NOT INEVITABLE AND IMPLIES EXCESSIVE SPENDING

"Lets get comfortable chairs and great new desks for everyone. None of this used stuff."

NOT INEVITABLE, BLATANTLY EXCESSIVE SPENDING

"Now we can pick out carpets that look good and feel good and we can have clean walls with great artwork and murals. "

ETC

"Lets make sure that we have plenty of conference rooms. We need our own cafeteria so employees don't have to leave the building."

ETC

<comment><USER12> Why shouldn't the engineers have new Aeron chairs? Software Engineers spend most of their careers sat down, so you should buy them the best damn chair you can afford, something that supports their bodies and is very comfortable.

Look at fogcreek software, they managed to move to AWESOME offices and they are still a lean company hiring great engineers who make great products.

<comment><USER13> They can have comfortable chairs. There is no reason, though, that they have to be _new_ comfortable chairs.

</comment></comment></comment></comment></comment></comment><comment><USER14> This happened to me when our company moved at the height of the 1st dot com boom and ended up burdened with space that caused us to close (rumor said about $1mill / 100 people). It certainly was months of disruption. In my neighborhood I can think of Sun, Netscape, Bay Networks and SGI that had this happen. The big move is at least an indicator to look twice.

<comment><USER15> As one who started at Netscape in 1996 and saw it through to the sale to AOL ($4B Sale, Final Day of Trading $10B) - I'll agree that the constant shuffling, moving, and campus growth was a pretty constant distraction - <USER2> what else could they do? Ton of product lines, lots of markets in the land grab, and you needed to put the people _somewhere_

I think Netscape managed their office shifts pretty well from 1996 onwards. I don't think it could have been done much better.

And, one could do worse than selling their five year old company (April 4, 1994 - sometime around April, 1999) for $10 Billion. :-)

</comment></comment><comment><USER16> What an excellent set of observations! I have been around and witnessed organizations going through the same mindset and pretty much watched the same tragic downfalls happen.

I personally witnessed this professionally in ministry settings as well as tech companies. Very interesting.

</comment><comment><USER17> you stay number 1 by acting like you're number 2.</comment>