Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Markdown to remote code execution in Atom

statuscode.ch

Post reply on HN
Print view View original

81–90 of 152 posts

Re: From Markdown to remote code execution in Atom

#81

Post by pjmlp »

IncRnd wrote: post #67
pjmlp wrote: post #53

Earlier quoted context omitted.

Office, Photoshop.

Office is hardly the same on multiple platforms. There may be shared code, but from UI and function-based perspectives there are big differences.

Which is exactly my point, the application architecture has to be done in proper modular layers to separate UI specific code that makes use of the UI elements that provide a good UX, from the common code.

Microsoft calls it hamburger design, and has held three talks at CppCon 2015 presenting how they unified their codebase across all platforms. They are available on YouTube.

Re: From Markdown to remote code execution in Atom

#82

Post by rootlocus »

pvg wrote: post #71
rootlocus wrote: post #27

Earlier quoted context omitted.

> 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.

> The Jetbrains toolbox UI (and your downloader) do very little.

That's true, but the argument was never about how complex applications are. It was about how they look. If you want an `idea` how well a swing look and feel scales with the complexity of the application, look at the IntelliJ IDEs.

Not to mention the irony of complaining about performance, when the promoted alternative is electron...

Re: From Markdown to remote code execution in Atom

#83

Post by Rapzid »

DandyDev wrote: post #40
qudat wrote: 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.

There are many viable compile-to-js languages out there to pick from:

* clojurescript

* f# via fable

* c# via different means(even an MSIL compiler)

* Golang

* etc

I mean, clojurescript and F# are bomber if you want functional. Typescript may give the best interop with existing packages, but I've read good things about F#'s .d.ts file support for creating type providers. In any case, if the lang you pick creates a bit of extra work that's probably small beans compared to the work required to get all of what parent described with completely separate languages and platforms.

Re: From Markdown to remote code execution in Atom

#84

Post by pvg »

rootlocus wrote: post #82
pvg wrote: post #71

Earlier quoted context omitted.

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.

> The Jetbrains toolbox UI (and your downloader) do very little. That's true, but the argument was never about how complex applications are. It was about how they look. If you want an `idea` how well a swing look and feel scales with the complexity of the application, look at the IntelliJ IDEs. Not to mention the irony of complaining about performance, when the promoted alternative is electron...

Well, I don't think your app looks better than an Electron app, in fact, you've styled it in a very web-like fashion. The Blizzard app does not look good and its performance is vastly worse than most Electron apps I've tried, so the irony eludes me.

Re: From Markdown to remote code execution in Atom

#85

Post by rootlocus »

pvg wrote: post #84
rootlocus wrote: post #82

Earlier quoted context omitted.

> The Jetbrains toolbox UI (and your downloader) do very little. That's true, but the argument was never about how complex applications are. It was about how they look. If you want an `idea` how well a swing look and feel scales with the complexity of the application, look at the IntelliJ IDEs. Not to mention the irony of complaining about performance, when the promoted alternative is electron...

Well, I don't think your app looks better than an Electron app, in fact, you've styled it in a very web-like fashion. The Blizzard app does not look good and its performance is vastly worse than most Electron apps I've tried, so the irony eludes me.

> Well, I don't think your app looks better than an Electron app, in fact, you've styled it in a very web-like fashion

Well, it wasn't about being "better", it was about not looking like shit.

> The Blizzard app does not look good and its performance is vastly worse than most Electron apps I've tried, so the irony eludes me.

Well, Visual Studio Code used to drain battery life for blinking the cursor in the background. But again, it was never about performance. My original argument was that newer 'native' applications written using Qt or swing can look just as good as web based UIs

Re: From Markdown to remote code execution in Atom

#86

Post by Johnny_Brahms »

Klathmon wrote: post #65
pjmlp wrote: 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.

Transmission comes to mind. It as a gtk, osx and Qt GUI

Re: From Markdown to remote code execution in Atom

#87

Post by pvg »

rootlocus wrote: post #85
pvg wrote: post #84

Earlier quoted context omitted.

Well, I don't think your app looks better than an Electron app, in fact, you've styled it in a very web-like fashion. The Blizzard app does not look good and its performance is vastly worse than most Electron apps I've tried, so the irony eludes me.

> Well, I don't think your app looks better than an Electron app, in fact, you've styled it in a very web-like fashion Well, it wasn't about being "better", it was about not looking like shit. > The Blizzard app does not look good and its performance is vastly worse than most Electron apps I've tried, so the irony eludes me. Well, Visual Studio Code used to drain battery life for blinking the cursor in the background…

Your argument was that Qt and Swing apps looking like shit 'could not be further than the truth'. Your counter-examples are a pair of apps that do next to nothing and a really bad app.

Re: From Markdown to remote code execution in Atom

#88

Post by pfooti »

pjmlp wrote: post #54
pfooti wrote: post #47

Earlier quoted context omitted.

I agree; if you build a system that completely covers specifying layouts for all widget needs and a DSL that handles wiring views into models, for all operating systems and device formfactors, you will have invented HTML, CSS, and JavaScript, with the DOM api and a browser as the default interface.

Not at all, because HTML, CSS and JavaScript are a poor man's UI with the lowest common denominator of OS features.

"lowest common denominator" is kind of a feature, when it comes to something used on a ton of different platforms. The rest can be built up out of those. I'm not saying that html et. al are amazing, just that I am doubtful something could be built that spans such a large vector space, so to speak, so expressively, without being subject to the same complaints.

Re: From Markdown to remote code execution in Atom

#89

Post by IncRnd »

pjmlp wrote: post #81
IncRnd wrote: post #67

Earlier quoted context omitted.

Office is hardly the same on multiple platforms. There may be shared code, but from UI and function-based perspectives there are big differences.

Which is exactly my point, the application architecture has to be done in proper modular layers to separate UI specific code that makes use of the UI elements that provide a good UX, from the common code. Microsoft calls it hamburger design, and has held three talks at CppCon 2015 presenting how they unified their codebase across all platforms. They are available on YouTube.

You misunderstand. Even forgetting the UI, the Office programs are different between platforms. One know this, because functionality differs between platforms.

Re: From Markdown to remote code execution in Atom

#90

Post by xfer »

Rapzid wrote: post #83
DandyDev wrote: post #40

Earlier quoted context omitted.

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

There are many viable compile-to-js languages out there to pick from: * clojurescript * f# via fable * c# via different means(even an MSIL compiler) * Golang * etc I mean, clojurescript and F# are bomber if you want functional. Typescript may give the best interop with existing packages, but I've read good things about F#'s .d.ts file support for creating type providers. In any case, if the lang you pick creates a bi…

Adding Reason(which is Ocaml with bucklescript backend) and Purescript to the list.
Post reply on HN