I think the problem with bundling chromium is that it wouldn't be evergreen, which means it doesn't have the latest security fixes, etc .

You'd still potentially have the out-of-date problem with Node though, which is arguably an easier attack vector since Chromium is sandboxed and Node has user-level privileges by default.

On the other hand you have more control over your app. The app will work and look as the author intended.

Many[citation needed] electron-ish apps are also available over the internet (vis: slack, atom, vscode, discord being examples I've personally used).

In the case where your software development practices require static bindings to exact versions, you're correct, but your app is participating in the "IoT anti-pattern" of deploying baked code which may or may not be updated based on the long-term viability of your company / product.

I think this offers a great leap forward in transparently keeping local software up-to-date. Your argument boils down to it being better to ship an entire Windows95 VM with your app so you "have control".

In most cases, better to ship your own app and integrate properly with the external operating system / runtime provider (or hide: "Use bundled chrome.exe" as an advanced checkbox).

Ideally it'd be possible to select puppeteer/firefox as the target runtime environment as well.

While I am not a fan of Electron, the problem with using the system-wide install of Chrome is that while Chrome and your online web-app are both updated, the installed app might not be. So then the installed app could break in the future when Chrome is updated.

>I think this offers a great leap forward in transparently keeping local software up-to-date.

Not really. You're forgetting that there is also nodejs runtime bundled with your app. And it needs to be updated too.

You could install that and node_modules system-wide ...

... are we re-inventing shared libraries?

Yes, was thinking about that. But is that really viable for regular joe?

Sure it can be. Shared libraries are also viable for a "regular joe".

There would just need to be a central manager for dependencies. And yes, I realize that we are on many layers of abstraction.

VSCode and Atom are available over the internet? I've seen online cloud-IDEs based on some of the work in them (Cloud9) but wasn't aware the vanilla versions could run in the browser.

It's not standalone and I don't know the details, but codesandbox.io can run what is recognizably VSCode.

Yes. At least, VSCode is using monaco-editor: https://microsoft.github.io/monaco-editor/

That's not the same thing

Stackblitz and CodeSandbox both run VSCode in the browser afaik

>On the other hand you have more control over your app. The app will work and look as the author intended.

Sure, but it's just the age old argument of static vs dynamic linking. General opinion has settled firmly on the side of dynamic evergreen dependency management for software on the web because exploits are so common and fast moving.

I think the +1 button was a really nice feature and something they should've done a while ago, but it's hard to draw the line.

If everyone contributes their pet UI feature (e.g. custom theme, use XYZ monospace font), then there will be dozens of features that only 0.01% of users use, but it increases the overall complexity of the product and maintenance burden.

+1 button could work as voting system to reduce that maintenance burden too. Semi-democratic method can be introduced to merge most voted and looks good to MS.

The only thing that sounds worse than design by committee is design by democracy. Do you know of any successful projects that are managed this way?

My words were not clear, I meant and edited to "semi-democratic" way. The voting is one indicator but I also believe strong vision and strategy of leader is the key to success.

And my point was not +1 button but splitting code into open source "Client side + Test-backend" and closed sourced "Production-backend". Backend can be composed of some interface and multiple implementation such as test impl and prod impl. Actually Github could be hosted in Azure and I do not care their backend as I go github.com anyway.

Looks very exciting! I've used firebase for some small weekend projects and it's been very productive for me.

I'm curious, what's the react native support like for Firestore / firebase in general?

There's a pretty complete React Native library you can use to build with Firebase services, including Cloud Firestore: https://github.com/invertase/react-native-firebase

The Cloud Firestore integration is fresh out of the box, but I'd certainly recommend trying it out!

Citation?

Very interesting DB service. If I'm reading the docs right it sounds like you can't do JOINs across documents?

https://docs.microsoft.com/en-us/azure/documentdb/documentdb...

Not using DocumentDB API but you can kinda do joins using graph traversal Gremlin API.

Congrats on the release. Could you summarize the pros and cons of picking Relay Modern vs Apollo Client?

Here is a detailed comparison between Apollo and Relay: https://www.graph.cool/docs/tutorials/relay-vs-apollo-iechu0...

(Note: This article hasn't been updated for Relay Modern yet but the main points are still the same.)

I think the comparison is going to be pretty different for Modern because Relay Modern has some significant changes in the approach.

You're absolutely right, we're already working on an updated version. We'd love to have Apollo's feedback on it to make it as helpful as possible!

It's possible. I got a job as a software engineer at Google despite having a degree in Economics and only knowing Javascript. I spent a lot of time studying data structures & algorithms on my own but it's do-able.

I installed the extension and it's incredibly easy to use. I tried it on a personal site, google.com, etc and it's interesting to see the various performance metrics for each site. I'd be curious to see what the highest PWA (progressive web app) score someone saw for a major website (for reference, I got 44/100 for google.com).

Tried it on www.flipkart.com (Amazon of India) and it scores 72-75/100. AliExpress scored 78.

I've noticed some open source projects (particularly Angular 2) follow this convention where they never actually "merge" the PR, but rather rebase it into their main branch and have a message in the commit to close the PR.

The advantages seem to be that you get a cleaner git history, and you can keep all the "in-between" / WIP commits that tell the story. Is this done through an automated tooling or is someone manually rebasing it into master? It seems to be a really useful practice so I'm curious how people do it. It would be great if GitHub could offer this natively, as I think many power Git users appreciate the benefits of rebasing over merging.