tomdale

It seems to me this accounting is missing the significant financial contribution many companies make to open source by way of paying employees to contribute, either part time or full time.

Many of the arguments here are premised on the idea that the only valid model for open source funding is a donation model. But if a company believes they get more benefit by contributing via employment instead of patronage, I don’t think it’s fair to say they’re exploiting open source.

(Disclaimer: I work at a BigCo where my role sometimes involves open source and standards bodies)

I'm really happy to see this. As fumbled as the launch was, I played it on PC and found the world and its characters to have more depth than I'd personally experienced in a video game before.

What broke my heart was to feel viscerally how much time and love the developers had poured into the game, dedicating years of their lives, only to have it all overshadowed by a disastrous, rushed launch. I for one am glad to see the game getting a shot at redemption, and I'm glad more people are getting to experience what IMO is a masterpiece of digital storytelling.

Hey folks, I've been working with wycats and my colleague Chirag Patel on Starbeam for the last few months. We prefer to work in the open, but this repo is still a work in progress and is definitely not ready for public consumption, other than very very very early adopters. We were planning to reveal more in June when things were more buttoned up, and certainly didn't expect to see this on the HN front page!

That said, we'd be happy to answer any questions people have about Starbeam, with the understanding this repo is still very WIP.

When I joined LinkedIn 4 years ago, the JavaScript infrastructure was a mess. We had a tool called `just` that integrated with the existing Java infrastructure, including Node version and dependency management, but it was a bit of a hack that predictably became a core part of the foundation.

Worse, onboarding took longer than it needed to, because every new hire had to learn the alternate "just" universe. I can't begin to count how much time was wasted because people subconsciously fell back to the "normal" npm or Yarn commands they were used to, mysteriously putting their project into a bad state, costing them and support engineers valuable time.

We've been able to replace that legacy infrastructure with Volta and Yarn, and working on JavaScript projects finally feels like a first class citizen.

What I appreciate about Volta is two things:

1. It treats the _entire_ toolchain (including npm or Yarn) as important, not just the Node version.

2. It's fast. Like, really fast. Tools like nvm never previously felt slow to me, but now that I've used Volta for the better part of a year, going back feels like they're running in molasses.

Wowwwwww

I was just in Medellín for JSConf Colombia a week ago. It was my first time in Colombia and I didn’t know exactly what to expect.

I was blown away by how friendly and engaged the developers I met were. I can say unequivocally I have never had the audience burst out in spontaneous cheering and applause at the end of a technical talk with such enthusiasm as they did in Medellín.

The conference venue was a beautiful, modern building next to the botanical gardens. The coffee was both delicious and strong. But most of all, the people were whip-smart and hungry to make their dent in the world. I can’t say enough positive things about Colombia.

Ember doesn't have a PATENTS file.

The process of getting content on to the web has historically been pretty daunting, and is IMO much easier now than the bad old days when a .com domain cost $99/year and hosting files involved figuring out how to use an FTP client.

In comparison, services like Now from Zeit, Netlify, Surge, heck, even RunKit, make this stuff so much easier in comparison now. As long as the performance optimizations are something that can happen automatically with tools like these, and are reasonable to use yourself even if you want to configure your own server, I think that's a net win.

I do agree with you though that we ought to fight tooth and nail to keep the web as approachable a platform for new developers as it was when we were new to it.

On balance, I'm more comfortable with services abstracting this stuff, since new developers are likely to use those services anyway. That's particularly true if the alternative is giving Google even more centralized power, and worse, access to more information that proxying all of those AST files would allow them to snoop on.

I don't think the binary AST proposal changes the accessibility status quo. In my mind, the best analogy is to gzip, Brotli, etc.

If you had to have a complicated toolchain to produce gzipped output to get the performance boost, that would create a performance gap between beginners and more experienced developers.

But today, almost every CDN worth its salt will automatically gzip your content because it's a stateless, static transformation that can be done on-demand and is easily cached. I don't see how going from JavaScript -> binary AST is any different.