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.
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].
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.
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.
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:
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.
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.
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.
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.
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.
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)