Hacker News Reader

Comment by devenblake | Hacker News Reader

Clicking it: "Please don't use electron, please don't use electron..."

Guess what modern technology the Arduino IDE uses?

Now that I have fully read the article I think this misses out on due credit though. The arduino cli looks pretty cool and there's no necessity per se to use the IDE 2.0 nor does it seem like there will be in the future. I just wish we weren't so reliant on web technologies to power what should really be native apps and it seems like everything uses electron nowadays.

View on HN

I tend to agree with this POV. However, even I have to admit that VS Code (which this IDE is based on) is pretty much the poster child of Electron done right. For many languages it's quite literally IDE level of functionality, for less resources than most IDEs I've worked with (especially looking at you, JetBrains), extensions included. Of course YMMV, but it's been working pretty well for me. Hell, I've already had Slack take more resources (depending on the project).

(Now waiting for people telling me their vim setup works fine for them)

JetBrains IDEs provide a huge amount of functionality that VSCode doesn’t, so it’s not really fair to compare them.

JetBrains also makes most Electron apps look downright parsimonious when it comes to resource usage. Hopping over to my work laptop, mine is consuming 3.21G of memory idle.

Let's compare industrial grade IDE with state of the art inspections and refactoring capabilities to music players and chat clients.

> For many languages

It's perfectly fair to compare them for some languages (mostly web). Let's also not pretend like people aren't comparing vim and ST with VSC all the time, while they're very different products.

> especially looking at you, JetBrains

JetBrains IDEs are an order of magnitude smarter than anything VSCode provides.

Depends on the language/plugin. They seem to prefer their own plugins instead of using LSP and tools given by the language ecosystem and they often end up with vastly incorrect error highlighting and autocomplete. At least this is what I saw in the Scala and Rust plugins (Scala finally got damn good but it took many years).

My completions/auto-imports/refactoring/debugging workflow is more or less identical in VS Code and PyCharm for JS/TS stuff. Python it's so-so. The golang plugin has pretty good integration for all that stuff too.

I pretty explicitly said that some languages are doing better than others. Of course a language specific IDE will probably do a better job than a generalist one in most cases.

Not when one tries to compare similar workflows in SublimeText vs VSCode.

Unfortunely most rather get the free beer VSCode, so here we stand.

Last I tried setting up LSP in ST, it kinda blew. Tons of manual, machine specific configs. No debugging, refactoring...

From my POV they are _not_ comparable.

Indeed, ST wipes the floor of VSCode regarding performance, not comparable indeed.

Unfortunely, free beer is where most plugins end up being.

It's kind of horrifying to open my /Applications folder and realise that it contains probably twenty web browsers, eighteen of which are disguised as stand-alone applications. Often very simple ones.

BalenaEtcher, a pretty front-end for a bunch of drive-copying terminal commands, is over 200 megabytes. A competent developer could probably recreate its functionality with 20 kilobytes of shell script. Yes, this script probably wouldn't be cross-platform, but I dare say that there's more than 20 kilobytes of platform-specific code in the current BalenaEtcher app already...

For better or worse, it doesn't really need to be smaller.

Of course it does. It's really a giant waste of bandwidth for a program that is probably 50% 'dd if of bs'.

Sure, and your house might look a smidgen better if it were painted a slightly different shade of the same color. It's a lot of work for very little gain.

Bandwidth is cheap. Human time is not. There are better ways to spend development time than shaving 2 seconds off the download of a utility app.

And yet loads of people still use it, and loads of people still recommend it... That’s what I mean by it doesn’t need to be smaller. It’s already hugely popular at the size it is, even though it’s a waste of bandwidth.

>Yes, this script probably wouldn't be cross-platform, but I dare say that there's more than 20 kilobytes of platform-specific code in the current BalenaEtcher app already.

I can do what BalenaEtcher needs to be done in a shell, but how many can/want to? When you say "probably wouldn't be cross-platform" you have already given a reason for this to exist. "20KB of platform-specific code", you clearly know what you're talking about. You should write cross-platform applications.

I don't understand the point of your snark. If you're trying to pointing out that writing cross-platform applications isn't trivial, you're agreeing with me.

I felt the opposite. Fist pump in the air when I read the part where they said it would be an electron application. Why? Because I knew what it meant... Rather than trying to roll their own editor and doing a second rate job of it, they were likely leveraging something that was Tried and true, modular, and easy to use out of the box such as the Monaco editor (the same editor built for VScode). And the end product would be much better for it.

Reply on news.ycombinator.com