felixrieseberg

It's worth a try ;-)

https://www.macintoshrepository.org/195-microsoft-excel-1-03...

Developer here! I'm so excited to see that people like this toy. I'm happy to answer any questions, if you have any.

But first, some important credits: Emulator: Basilisk II, a 68k Macintosh emulator, by Christian Bauer et al, modified and compiled with Emscripten by James Friend. Installed software from vintage computing archives: WinWorldPC, Macintosh Garden, and Macintosh Repository.

Author here. You're 100% right, I do consider Basilisk and the Emscripten compiler to be the "real" work here. I added that in a Credits file in the repo, the app, and even _in_ the virtual machine - because I think that's important to know.

Hi, author here! This is silly, but I'm allocating the entire size of the _virtual_ disk on your actual hard drive. There's probably a smarter way to do this, but that's how it is right now. PRs would be lovely!

Fun fact: The Chromium dev tools are "just another web app": https://github.com/ChromeDevTools/devtools-frontend

Look, I get it, "less web apps" is an easy post to write these days, but all I ask is that we tone down the FUD. Let me just pick off the inaccuracies that will likely stick the most:

> But building for the web(and electron) forces you to HTML/Javascript(and derivates).

This is incorrect. Electron supports Objective-C, C++, Rust, and obviously WASM (amongst others). If you want to build native code (and native UI) in any of these languages, go for it. Countless Electron apps have native components.

> It has no type safety, memory leaks are common and it’s slow due to its dynamic nature.

TypeScript has been a thing for a while now. [Citation needed] for the statement that memory leaks are more common than in, say, C++. Slow: Yes, it's slower, but probably by _a lot_ less than you think[1].

> And it’s laughable how weak the browser platform itself is. SQLite is available on raspberry pi, embeddable systems, mobile platforms and just about every other platform on the planet.

I agree, SQLite is fantastic. We don't really have to argue whether IndexDB will get thee job done, because native bindings to use SQLite with Electron exist. Just... use it.

And lastly...

> These days to send a text message over Slack I need over 1GB of RAM. [...] Even basic apps with all of their trackers, external javascript scripts and doms take up 100s of MBs in memory.

We're always working on performance and we're quite far from the place I'd like us to be at, but it'll send your message just fine if you have less than one GB of memory installed in your whole machine. Even if you're a heavy user, your memory _should_ be below one GB. To be clear, I'll say it again: Yes, things should be better and we'll keep working on performance. The post mentioned Instagram earlier, which I'd say goes a bit beyond the most basic app, and it's using a humble 40MB on my machine.

Disclaimer: I'm one of the maintainers of Electron and an engineer at Slack. I'm not here to argue opinions or which tool is better for which job, but we should get the basic facts right.

[1]: https://www.youtube.com/watch?v=81CECdKCJNc

If you're already running code on the victim's machine, presumably with sudo rights to change `/Applications`, you've already hit the jackpot. Yes, you can change apps, but if you're the victim, that's _probably_ not the biggest issue. It's the rootkit on your machine.

Electron co-maintainer here, so I'm a bit biased.

1) We should absolutely work towards allowing developers to sign their JavaScript.

2) Re-packaging apps and including some menacing component as a threat vector isn't really all that unique. We should ensure that you can sign "the whole" app, but once we've done that, an attacker could still take the whole thing, modify or add code, and repackage. We sadly know that getting Windows SmartScreen and macOS to accept a code signature doesn't necessarily require exposing your identity and I'd _suggest_ that most people don't _actually_ check who've signed their code.

3) If you ship your app as a setup bundle (say, an AppSetup.exe, an App.dmg, or rpm/deb files), you should code-sign the whole thing, which completely sidesteps this issue. The same is true if you use the Mac App Store, Windows Store, or Snapcraft Store.

> Are the full-time employees paid a wage above the poverty line?

Yes, very much so. It's tech. We're all really, really lucky.

Electron maintainer here.

Most of the maintainers are being paid to maintain Electron full-time. I've worked in jobs before where you got to do "some open source during work hours", but in the case of Electron, most of our people are specifically paid to work on Electron.

Yes, absolutely, find and use more ways to fund Open Source, but describing Electron as a project below the poverty line is plain incorrect. Yes, we too need funding, but that description strikes me as inaccurate and thus problematic.

"Below the poverty line" means something, doesn't apply to Electron, and saying it because it sounds good trivializes a problem in a world where 1/7 children in the US live _actually_ below the poverty line.

> so their code wasn't so easy to reverse engineer

As a bit of history, most of our team is made up by old-school desktop engineers with a background in native desktop development (and we still have a pretty decent amount of C++ and ObjC running in our app). Decompilers these days are pretty impressive – seeing the implementation of most desktop apps is fairly trivial.

This is just a personal statement, but I never had trouble with the files being there. They're currently present to support some outdated and soon-to-be-replaced module resolution, but I'd give this advice: If you're shipping logic to users, make your peace with the fact that it can be reverse-engineered. Sure, opening a source file is a bit easier than having DotPeek decompile your DLL, but it's pretty easy either way.

In other words: My stuff should be safe and secure whether or not an attacker knows how I implemented my logic.

Yes, we’re actively working on that.

Hi, Felix from Slack's Electron team here.

Slack co-maintains Electron together with GitHub, employing multiple core maintainers full-time, contracting those who can't join us full-time. We've also just hosted (and paid for) the first Electron conference. We're also maintaining a fairly large number of electron-userland modules.

tl;dr: That page might be misleading, we're investing heavily in Electron.

Currently not on the roadmap – for what it's worth, the majority of apps perform their Electron updates at different times, so you'd still have the same number of binaries and files as you do today.

Hey! Author here. I got to admit, that’s an angle I did not fully consider - but adding theming should be fairly easy, given that our editor already has built-in themes.

I’ll put that on my personal to-do list (unless someone sends us a Pr first)!

This looks really, really impressive. I'd love to connect this to Electron apps, too.

As someone who wants Windows users to have a decent time using and developing with Node.js, it warms my heart to see developers of modules to at least consider them. As the maintainer of `windows-build-tools`, it makes me so happy that more and more modules are including it as an installation instruction.

> The following was shared as a twitter thread. Here’s the medium version.

I'm wondering if this could have been a much more accessible piece of writing if it wasn't 44 tweets copied-and-pasted together.

Slack desktop engineer here: We're not discontinuing anything – we're just offering more options.

The author is likely not confused, given that Axel turned "knowing JavaScript" into a fairly decent career.

(Besides: Doesn't telling people that they aren't real programmers get really boring quickly? Shouldn't we all be over this by now?)

[1] http://www.oreilly.com/pub/au/5474

If you're on Windows and want to give this thing a test drive, use `npm-windows-upgrade`:

Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force

npm i -g npm-windows-upgrade

npm-windows-upgrade --npm-version latest

At least on the West Coast it seems pretty common - considering that companies here also pay for your health insurance, it seems like an overall decent idea.

It's probably worth pointing out that Slack _also_ contains a ton of native code, written in C++ (with a bit of C++/CX and Objective-C). All of us on our small team have an extensive background in typed languages, including giant code bases (Windows, for example).

We just also happen to really like JavaScript, feeling that it and the ecosystem around us makes us more productive given our needs. TypeScript a few years ago was simply not good enough, and neither were the alternatives.

It's okay if you feel otherwise, but trust that there are quite a few developers out there who are comfortable with building and maintaining rather large JavaScript codebases, building pretty impressive applications with it. This post isn't yet another "JavaScript is terrible" rant, I quite like it.

Thanks for the update, good to know!

Sorry, I just chose the image because TypeScript's official hero image is a Seattle skyline. I hope I didn't disappoint - I love Seattle though, I can't wait to be back this year for //build.

I personally haven't spent too much time looking at Dart, but I find it pretty suspicious that TypeScript is on Google's list of approved languages for projects, while Dart is interestingly missing. I'm sure there's upsides to Dart, but I would certainly need to spend more time with it to make a judgement call.

https://www.reddit.com/r/programming/comments/64e6x7/typescr...

I'll be careful not to tell anyone not to use Flow - we're using many of Facebook's tools and we're grateful for their gifts to the community. If Flow works for people, that's great!

That said, back when we got started, we found that TypeScript is all around a better team player. For us, we found that it worked better with npm modules, different operating systems, vanilla JavaScript, and various coding tools (VIM, Visual Studio Code, Atom, etc).

Hey! Author here - let me know if you have any questions about anything in that post (or, you know, anything else... like, erm, Electron).

Neat! To avoid being sucked into anything too big, you might want to check out the "good first" issues on the Desktop App (https://github.com/tryghost/ghost-desktop/issues?q=is%3Aopen...) or the beginner ones on the heart of it all (https://github.com/tryghost/ghost/issues?q=is%3Aopen+is%3Ais...).

Hi, I'm one of the volunteer core devs on Ghost

The company is a non-profit that supports journalism and professional publishing. Everything is open-sourced. I'm leading the work on the Desktop App (https://github.com/tryghost/Ghost-Desktop), but all projects (server, admin interface, etc) can always use more love.

If your company allows you to donate some time to non-profits and you think that democratized journalism is important, consider helping us out

That's an excellent question! The auto updater requires your packages to be code-signed, meaning that someone would have to compromise the endpoint _and_ also be able to sign code with your root-trusted certificate.