Live data from Hacker News

From Markdown to remote code execution in Atom

statuscode.ch

71–80 of 152 posts

Re: From Markdown to remote code execution in Atom

#71

Earlier quoted context omitted.

Why? Qt/swing/gtk apps tend to look like shit and are horrible to try and code

> Qt/swing/gtk apps tend to look like shit You couldn't be further from the truth. Have you seen the Blizzard app (Qt) [0]? The JetBrains Toolbox app(Qt) [1]? Also, here's a small app I wrote in kotlin and swing for my GF who wanted to download music from youtube without installing crapware downloaders [2]. You'll notice it has a custom window frame, support for drag and drop, and fully customized table and buttons.…

The Jetbrains toolbox UI (and your downloader) do very little. Blizzard's app does a great deal more but is a terrible, sluggish, battery-hogging mess, which also includes web UI elements of some sort. Even Blizzard knows this which is why the app has a setting to hide its windows after launching a game. It doesn't feel like an example of a quality Qt app at all, if such a thing exists.

Re: From Markdown to remote code execution in Atom

#72
post #63

Earlier quoted context omitted.

Still doable when user experience is more valuable then developer convinience. It is all about design a good application architecture from the get go.

I'd love to be shown an example, because I honestly don't believe it is doable, let alone doable easier than just making several different applications.

Non UI code lives in a static/shared lib that gets called from UI code. The non-UI code shouldn’t be coupled to a UI at all, instead reporting progress/completion via callbacks or other notification mechanisms.

If you must run on every platform for whatever reason, there is Rust, C, C# (Xamarin), etc.

Re: From Markdown to remote code execution in Atom

#73

Earlier quoted context omitted.

How about “not using a bazooka to kill a mosquito”? There's no reason why a text editor needs a frigging browser engine as a core component.

Apparently there's a reason because VS Code (and Atom) is way more useful than any other editor built over last few decades.

Unsure how to quantify this kind of hyperbole. Compared to SublimeText 2 which is outdated at this point, VS Code and Atom are only getting back to the standard of fast code editors from the last few years ...

If you go back a few decades, you're competing against vi/vim and emacs, and there's no way you can say VS Code (and atom) can go against the "usefulness" or even productivity of either of those editors and their development environments.

Re: From Markdown to remote code execution in Atom

#74
post #16
post #10

This is why I don't run any Electron apps on my computers at all, ever. That means I'm stuck with the web browser version of Slack, Skype, Signal (going away), and so forth, which is a shame. But it's better than the security nightmare that is Electron. I wish developers wanting to make cross platform GUI applications would look instead at Qt. It's extremely easy to use, really fast, and generates great GUIs. It's be…

All your positives about Qt can be applied to electron but even better. From a business point of view electron is a winner. For example at our company we have built a desktop app, web app, salesforce plugin, chrome extension, outlook plugin, cli app, and are working on mobile apps all using one JavaScript codebase. It’s a business and developers dream. There really is no competition and any claim to the contrary woul…

> For example at our company we have built a desktop app

Keep telling yourself that if it makes you feel better.

Re: From Markdown to remote code execution in Atom

#75
post #16

Earlier quoted context omitted.

All your positives about Qt can be applied to electron but even better. From a business point of view electron is a winner. For example at our company we have built a desktop app, web app, salesforce plugin, chrome extension, outlook plugin, cli app, and are working on mobile apps all using one JavaScript codebase. It’s a business and developers dream. There really is no competition and any claim to the contrary woul…

It's not a developers dream if that developer loathes Javascript, like I do. Even Typescript just feels like lipstick on a pig.

I not a fan of javascript either, although I write js almost evey day and use Atom mainly because I could not find a better open source desktop editor that looks and works like Sublime Text. If anyone cares to write one in C++, D, Rust or Go, I'll happily use it.

Re: From Markdown to remote code execution in Atom

#76
post #64

Earlier quoted context omitted.

And many developers loathe C++. Why should I have to use such a low level and antiquated language for developing a GUI? Nowadays you don't even have to use JS/TS, there are many languages that target JS and have decent bindings to its ecosystem, such as Scala, Purescript, Clojure. This doesn't seem to be the case with Qt which lacks decent bindings to languages other than Python.

It is all a matter of actually knowing how to write proper C++, or just using a C++ compiler to compile code that looks like C.

"It is all a matter of actually knowing how to write proper JavaScript, or just using TypeScript to compile code that looks like JavaScript."

Re: From Markdown to remote code execution in Atom

#77
post #10

This is why I don't run any Electron apps on my computers at all, ever. That means I'm stuck with the web browser version of Slack, Skype, Signal (going away), and so forth, which is a shame. But it's better than the security nightmare that is Electron. I wish developers wanting to make cross platform GUI applications would look instead at Qt. It's extremely easy to use, really fast, and generates great GUIs. It's be…

> I sort of suspect that Electron's popularity is due to it being accessible to the hordes of JavaScript developers

Look, let's not kid ourselves, we all hate JavaScript like it's the plague, but no other framework comes even close to the ease of CSS/HTML and a drop of JavaScript for interactivity (transpiled from a sensible language), when it comes to GUI development. It's such a fucking embarrassment working with Gtk, Qt, Tk whatever have you, it's not even funny. Even native mobile dev (Swift/Java) is easier through a web interface, because nobody wants to have to remember that you had to "drag click from here to your source code" or "add this to your xml file to make it accessible".

Honestly, Electron is a shitty resource hog, but it is a trillion miles better than what the current offerings are.

Re: From Markdown to remote code execution in Atom

#78

Earlier quoted context omitted.

I'd love to be shown an example, because I honestly don't believe it is doable, let alone doable easier than just making several different applications.

Non UI code lives in a static/shared lib that gets called from UI code. The non-UI code shouldn’t be coupled to a UI at all, instead reporting progress/completion via callbacks or other notification mechanisms. If you must run on every platform for whatever reason, there is Rust, C, C# (Xamarin), etc.

That's a valid architecture, but it's not a cross platform UI library that uses fully native looking UI on every platform which is what I'm skeptical of working.

Re: From Markdown to remote code execution in Atom

#79
post #64

Earlier quoted context omitted.

And many developers loathe C++. Why should I have to use such a low level and antiquated language for developing a GUI? Nowadays you don't even have to use JS/TS, there are many languages that target JS and have decent bindings to its ecosystem, such as Scala, Purescript, Clojure. This doesn't seem to be the case with Qt which lacks decent bindings to languages other than Python.

It is all a matter of actually knowing how to write proper C++, or just using a C++ compiler to compile code that looks like C.

> It is all a matter of actually knowing how to write proper C++, or just using a C++ compiler to compile code that looks like C.

You might wanna read that back to yourself. Now replace it with any language you hate, and then tell me how that statement makes any form of argument at all (it doesn't...).

Re: From Markdown to remote code execution in Atom

#80

I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser. Not only will this be more secure, it'll also be 10s or 100s of times more performant.

> I've an idea. Let's write GUI apps using GUI libraries, like everyone used to, instead of writing them for a web browser.

Great idea! Now show me an application that can be extended in the same way Atom can, that didn't have 30-40 development behind it...

Post reply on HN