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

It’s strange this article effectively pins the attack on Iran, but doesn’t mention Stuxnet/Olympic Games, a malware attack on Iran that destroyed nearly 1,000 of their centrifuges[1].

1: https://www.washingtonpost.com/world/national-security/stuxn...

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.

For folks who want to play around with this, we've got an interactive playground at https://try.glimmerjs.com/ that lets you add components, templates and helper functions.

In a nod to The Net, you can click the π symbol in the bottom right corner where you'll get a debug view of the disassembled binary bytecode.

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.

Certainly not dead! One of the nice things about VS Code/Monaco is how easy they make it to embed the editor in the browser.

With Glimmer, for example, I was able to hack together this playground with full intellisense over a weekend: http://glimmer-playground.netlify.com/

Source code here: https://github.com/tomdale/glimmer-repl (itself a Glimmer app that wraps Monaco)

Yep, this is pretty spot on!

At a high level, the Glimmer VM is built on top of two primitives:

1. References (as you describe, an interface implementation to provide the underlying value)

2. Tags, an interface that communicates "is it possible this value has changed?"

Every reference has an associated tag, so once you have a reference, at any time you can ask: Is it possible this thing has changed? If so, what is it's value?

In KVO systems, every time a dynamic value is used in the template, that view usually adds an observer on to the root object. This adds a fair bit of overhead to both rendering and teardown. And if multiple properties change, you have to figure out the optimal re-rendering strategy. (E.g., if a value inside an `if` changes, you probably don't want to re-render it if the conditional also changed from truthy to falsy!)

Today in Ember, the view layer no longer sets up observers. Instead, during rendering, we create a tag for each property. When you mutate a property (this.set('firstName', 'Matthew') for example), two things happen:

1. That tag is marked as dirty.

2. A revalidation of the entire tree is scheduled.

The revalidation process starts from the top of the render tree and walks down, asking every reference/tag "is it possible you've changed?" Because this is just an integer comparison, it's very very fast on modern JavaScript VMs, even if you have lots of data on screen.

The tag is like a Bloom filter, though. It means a change MAY have happened, not that one necessarily did. If the tag is dirty, we do a last chance identity check for primitive values. Only if it has actually changed do we update the DOM.

One nice thing that falls out of this is that the application developer can change as much component state as they'd like at once, and we can avoid doing any expensive computation to figure out the optimal place to start re-rendering (the `if` case I mentioned above). By revalidating the tree from the top down and keeping constant time factors low, you get that optimization "for free."

The other nice thing is that you can express all sorts of cool semantics on top. For example, if you have immutable data you can attach a tag that always says "I'm never modified." If you don't want to do any bookkeeping at all, you can attach a tag that says "Always recheck me to see if I've changed." Best of all, as Yehuda mentioned, you can mix and match these semantics in your components. It also allows the data to drive the change semantics, not the component, which you often don't want to have care about how model data might change.

If this is interesting to you, there is some WIP documentation in the Glimmer VM repository that talks more about the philosophy behind references and tags:

https://github.com/glimmerjs/glimmer-vm/blob/master/guides/0...

https://github.com/glimmerjs/glimmer-vm/blob/master/guides/0...

The Glimmer runtime is under 30k, and we have not done much bundle optimization yet so hopefully this should go down a little bit even further.

React Fiber is currently just over 70k, and that's just the reconciler, not the complete React package. However, according to Dan Abramov[0] they have not yet focused on optimizing the bundle size either. And Fiber includes some prioritization features that we don't have in Glimmer yet.

https://twitter.com/dan_abramov/status/844223224732958721

This is because we recently added the ability to specify a blueprint as an npm package, and it hasn't made it out of canary channel yet.

If you don't want to install canary Ember CLI, you can always just give it the longer git url:

ember new my-glimmer-app -b https://github.com/glimmerjs/glimmer-blueprint.git

JSX vs. templates is a common debate, with popular JSX options like React and Preact and template-based options like Vue and Glimmer. The reality is that there are hard tradeoffs to both and anyone who tells you one is obviously superior to the other is probably trying to sell you something.

For me personally, templates ever-so-slightly edge out tools like JSX. For one, I subscribe to the Rule of Least Power[0]. Having the full expressiveness of JavaScript is very nice, but it makes it harder for tools to statically analyze and optimize the rendering process. Ember has gone through three major rendering engine architectures now (string-based, DOM-based and now the Glimmer VM) and the simplicity of the templating language has made that portability much easier.

[0]: https://www.w3.org/2001/tag/doc/leastPower.html

More importantly though, there are a lot of people in the world who know HTML and CSS. The fact that Glimmer templates are "just HTML" makes them accessible to people like designers who may not understand all of the fancy destructuring or array mapping happening in your JSX.

Lastly, and this is perhaps just a personal foible, but I have a really hard time mentally mapping more complicated JSX expressions into the final HTML output. It's fine when you're writing it, but reading it later, particularly to write CSS for it, is more challenging for me than Handlebars. I know some people would say that this is a code smell and that I should break that component up into smaller components, but I'd rather that decision be made by me than because I feel forced into it by the muddiness of my render() method.

The API docs themselves are a Glimmer app: https://glimmerjs.com/api/. The source code is here: https://github.com/glimmerjs/glimmer-api-docs

You may also enjoy the prerequisite turbo-stress-test app:

https://glimmerjs.com/demos/uptime-boxes/

https://github.com/glimmerjs/glimmer-demos

A legitimate question!

One thing people really love about Ember is that the process for going from nothing to a working app is very streamlined. Typically, this is not the case with smaller component libraries. Personally, I think there's a market for opinionated tools on this side of the simplicity spectrum.

Another aspect of this is that more complex build tools can often do better analysis of your app and move more work to build time, improving the boot and/or runtime performance of your app. For me, I'll trade a longer npm install time if it leads to a better experience for users.

That said, all of the Glimmer packages are distributed as AMD, CommonJS and JavaScript modules on npm[0], with a `module` field and everything in their package.json. While it's not as turnkey as using Ember CLI, I hope people feel empowered to experiment with whatever their favorite build tools are.

[0]: https://www.npmjs.com/org/glimmer

I'm excited for this and eagerly look forward to adopting it in Ember as soon as it's mature, but I'm guessing this is still at least a few years out.

WebAssembly doesn't give you access to DOM APIs, so it's not like you could rewrite Angular in wasm, for example. Most load time/parse time discussions are in the context of web frameworks, but they're typically not able to benefit from the performance improvements of WebAssembly, particularly given the overhead of moving data into and out of the wasm context.

I tweetstormed about this once. https://mobile.twitter.com/tomdale/status/786950181522636801

LinkedIn has actually done a ton of work optimizing Ember for mobile devices, and they've got code splitting (what we call lazy engines) in production already: https://twitter.com/trentmwillis/status/796748896659800064

I have to say, the work being done on Servo is really exciting—the first tectonic shift in browser engines to come along in years.

pcwalton's talk about WebRender earlier this year[1] was one of those rare technical presentations that left my jaw on the floor. In particular, the insight that modern browsers are just AAA game engines with a security model, so they should be architected similarly, changed the way I think about browsers. That game developers and Mozilla are both so excited by Rust's ability to safely write parallel systems at scale makes a lot of sense.

[1]: https://air.mozilla.org/bay-area-rust-meetup-february-2016/#... Previous HN discussion: https://news.ycombinator.com/item?id=11175258

I don't think it's fair to compare jspm and Yarn. jspm is an interesting project, but is tightly coupled with SystemJS. Telling everyone to rewrite their apps to use SystemJS and jspm is a huge lift.

Yarn, on the other hand, has focused on npm compatibility from the get-go. The entire point is to be a drop in replacement, with no changes (or maybe very very minimal changes) required to gain a lot of benefit.

In this slice of the industry where everyone is told they have to rewrite to the latest thing every year or two, I find it very refreshing to see Yarn's focus on backwards compatibility, improving existing infrastructure, and having a clear, painless adoption path.

Yes, that's why I said it was a Ruby limitation, not a Bundler limitation.

This is a huge leap forward for the JavaScript community—probably more than many people will realize right away.

I loved Bundler's deterministic builds but chafed against the Ruby limitation of only having a single version of a dependency at once. npm solved this problem elegantly, but still struggles with non-determinism. I had resigned myself to thinking that maybe these were just fundamental tradeoffs in package management that could never be resolved.

Then I had the opportunity to use Cargo, the package manager for Rust. It synthesized what, in my mind, are the best features of npm and Bundler into a single package manager, with terrific speed to boot.

Yarn looks like it will be Cargo for JavaScript. After Cargo improved on many of the great ideas of npm, those ideas are returning to help improve the JavaScript ecosystem. Cross-pollination at its best.

This also highlights a shrewd move on the part of npm: a clear decoupling between the npm registry and client, with a well-defined protocol between the two. The strength of Node is in the staggering size of its ecosystem; how those bits end up on disk is an implementation detail. This smart separation allows for this kind of experimentation on the client side, without causing the ecosystem fragmentation that happens when a new package manager requires a new registry.

I'm also happy to see that a significant amount of work has already gone into the governance model. Despite the largest contributors being Facebook employees, it looks like they've really outdone themselves making sure this is a community-run project. A BSD license, no PATENTS file, and an Ember/Rust RFC process[1]; this has all the hallmarks of a community open source project. That's critical for open infrastructure projects like this, and they've nailed it.

[1]: https://github.com/yarnpkg/rfcs

I'm very much looking forward to using Yarn in my own projects because it looks like it solves a lot of real problems I encounter every day. Thanks for all the hard work!

Most "vim emulation" plugins suck, because the vim way of thinking about things is so different from the typical GUI editor. Because of this, extension APIs often have to be wildly abused just to get even moderately decent parity with vim. Bugs and inconsistencies abound and are often impossible for the plugin author to fix.

That's why it's been extremely heartening to see releases of VS Code that explicitly add extension points to enable features for the vim plugin[1]. It's not perfect now, but given that the VS Code team seems to be making it their mission to offer an extension API robust enough to make it perfect, I'm willing to deal with the quirks for now.

[1]: https://code.visualstudio.com/updates/v1_5#_extension-author...

I have been using VS Code as my full-time editor for a few months now and couldn't be happier. Originally I was only using it for TypeScript projects, where the language integration is top-notch, but eventually found myself using it all the time. I use the vim plugin, which is surprisingly good although it does have a few issues still.

The best thing about VS Code (and Microsoft's other big open source project, TypeScript) is the steady stream of releases. Because of the regular release cadence, small but important improvements never get blocked by some big feature that took longer than anticipated. As much as I wouldn't have believed this 10 years ago, Microsoft does open source better than almost everyone.

VS Code: developed on GitHub, written in TypeScript, great extension API, clear roadmap and regular releases. I am a very happy user.

The recent flurry of activity around async IO in Rust has been really exciting; to me, it indicates that the core team's decision to stabilize the language was a smart bet that is paying off in rapid ecosystem growth.

One quibble I have with this post is that it talks about futures as a zero-cost abstraction. That might be true (or close to true) from a performance perspective, but in my (admittedly inexperienced) opinion, it seems to have a significant ergonomic cost that is not accounted for.

While futures help us deal with multi-threaded coordination of data from multiple sources, that overhead isn't necessary for situations where you're running in a single thread dedicated to doing IO operations.

Dealing with futures in your code is not non-trivial. Browsing through the futures version of the HTTP server, I had a hard time following along:

https://github.com/alexcrichton/futures-rs/blob/master/futur...

And it requires a bunch of helper code to go with it:

https://github.com/alexcrichton/futures-rs/blob/master/futur...

The blog post mentions Tokio, another high-level abstraction on top of mio (by the same author). Because it doesn't require the futures abstraction from top-to-bottom, it offers similar (maybe even a little better) performance with what, to my eyes, is far simpler code:

https://github.com/tokio-rs/tokio-minihttp/blob/master/src/l...

I'm still learning Rust and spend most of my time in JavaScript. The analogy I'd use is: imagine if in the Node programming model, every API required you to use JS Promises, even at the very lowest level. Even if you could reduce the cost of creating new Promise objects, interacting with them over simple values could make the code you write more verbose. In Rust, that problem is exacerbated by the much stricter type system and the fact that you have to do cross-thread coordination.

I'm a total beginner to systems programming, and a lot of this stuff is above my pay grade. However this shakes out in the community, I'm very happy to see Rust on the way to becoming the fastest, most productive way to write high-performance web services.

For example, see Robert Jackson's addon for using decorator syntax to describe computed properties: https://github.com/rwjblue/ember-computed-decorators