This definitely reads like one at least. I can't help but be amazed at the way he uses to publish / distribute it all at the same time using this print spool.

Exactly what I was looking for. Thanks!

IMHO I would expect a big proportion of the sites to break when you browse w/o JS nowadays ; nothing wrong with it, it's just the state of the web now...

Most sites are broken in some way without JS these days, but usually in a way that doesn't matter if if all you want to do is ready the body content, and sometimes it's actually an improvement. Not loading 10 sharing buttons, 15 analytics packages, and a bunch of ads due to them all relying on Javascript makes the internet a more pleasant place.

> We've added file-level JavaScript variable scoping. Variables declared with `var` at the outermost level of a JavaScript source file are now private to that file. Remove the `var` to share a value between files.

I think it is convenient to be able to declare global variables like that but perhaps there should be a way to monitor those ; in other words, it would be really convenient to have some form of alert system to notify you when a new global variable is created.

That way, globals created by mistakenly forgetting the 'var' keyword would be easily spotted.

This is under active development on the linker branch: https://github.com/meteor/meteor/tree/linker ! The goal, hopefully coming in one of the next few releases, is to provide package-scoped variables and explicit exports from packages, so that you don't need to rely on globals at all any more.

I'm happy to hear this. One of the primary problems with client-side development right now is the lack of commonjs style imports and exports -- something which people are trying to solve using component, etc. It'd be nice if Meteor had something baked in.

Seems like a good idea to add outside of meteor projects too. Maybe an extension for Chrome dev tools that lists global variables loaded per page?

This will give you a list of globals in browser

for(var i in window){ if(typeof window[i]=="object"){console.log(i);} }

But I think op wanted variables server side as well

I think it would be good to have that on both the client and the server.

Also, as simple as this might be, making it a de-facto standard (on meteor) would be a good thing since it would be a tool that we can count on, all the time. There are too many browsers IMO to make an extension a viable option.

Whitelisting variables would be good as well ; that way we do not get alerted if it is something we expect to be global.

Create a collection called MyVars and add this to your Server.js file:

Meteor.setInterval(function(){ for(var i in global){ if(MyVars.find({name:i}).count()==0){ MyVars.insert({name:i}); console.log("New Public Variable: ", i); } } }, 5000);

Thanks for the fun challenge :-)

Alert system if you're running Canary with experimental JS flag on:

Object.observe(window, function(changes){ console.log(changes) })

:)

What is the project direction in relation to complex JS apps?

i.e.: How do you guys expect the instarepl idea to be used in apps made of serveral node.js modules/libs or several files meant to be loaded together via RequireJS ?

Here's an interesting list of bugs [1] (some related to path-finding some not) found in SC / Broodwars.

[1] http://wiki.teamliquid.net/starcraft/Bugs

I wonder what part of their path finding algo created a glitch like the drone float[1]

[1] http://www.youtube.com/watch?v=7MN0wjoqmzU

I suspect a hack was involved -- the animation leading up to the construction of a Zerg Extractor involves the drone hovering over the geyser temporarily. This requires the unit to be put into a "floating" state which wasn't properly cancelled if the build failed -- queueing up additional move commands would then allow it to clip through barriers.

A number of similar bugs with queued commands existed. I get the sense that this feature wasn't adequately tested. :)

Well, THAT is odd. I'll look into it right now. Thanks for the heads up!

Oh, no, don't worry, you can turn social sharing off permanently. Hit the 'preferences' item in the menu at the top right. In there, you've got all kinds of social features to turn off. And they'll stay off.

Hey Andrew, wavo co-founder here.

We definitely understand that some of our users prefer not to use the social sharing features of our app ; hence we added the capability to turn those off, either temporarily with the use of the "social-sharing" switch at the top of the interface --or-- permanently via the preference dialog that you can find in the top left menu.

Thanks for the response. I fully get why you're doing it and appreciate the options to turn them off. With that said, it's really just a band-aid to appease the vocal opponents.

My mental model of sharing (and I'd bet it's shared by many others as well) is that there needs to be an explicit "sharing action" taken. I should know exactly what happens when I do something - I don't on your site. As a result, I never get to the "aha" moment because I'm afraid to click on anything.

You are definitely right and we'll be continually looking at better ways to integrate seamless sharing into the app.

Seamless sharing is also a "band-aid." It gets users sharing your app at the beginning but there's definitely some users who are turned off by it.

So although this is where a lot of our referral traffic comes from at the moment there are undoubtedly better ways to do this and we're working on it. These are early iterations on the product and we'll be circling back very soon.

My own opinion is that people should begin with total control over their sharing, instead of default auto share, and eventually chose to share automatically if they want.

I think just based on the title of the HN submission is that this site is built from the ground up to encourage social sharing, so Facebook sharing seems like a sensible default based on that.