Live data from Hacker News

From Markdown to remote code execution in Atom

statuscode.ch

121–130 of 152 posts

Re: From Markdown to remote code execution in Atom

#121
post #21

Earlier quoted context omitted.

Cross-platform GUI development has always been fraught, though. I don't blame people for picking an existing, working (mostly) technology that guarantees (mostly) identical results across lots of platforms.

Cross-platform GUI development in general is a dumb idea. The user chose a specific platform and expect applications to follow that platforms UX guidelines. Building a cross-platform app is basically saying you don't give a fuck about your customers. It's an insult to your users.

> The user chose a specific platform and expect applications to follow that platforms UX guidelines.

1) Most users don't actually give a crap about "UX guidelines". I promise.

2) "UX guidelines" are, in my opinion, why our user interfaces continue to suck.

Re: From Markdown to remote code execution in Atom

#122
post #120

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.

Instead of taking 1 high quality UI paradigm that works exactly the same on virtually every computer and spending time solving my business problem, you'd like me to spend time on learning the weirdnesses of each platform's native UI. No thanks!

If you consider web to be "high quality UI paradigm", then you might be seriously interested in learning other UI tools. You know like literary any other UI library on Earth where vertical centering of one element in another is just a basic functionality not a task that requires a hack.

Re: From Markdown to remote code execution in Atom

#123
post #54
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 of OS features

Not sure I agree here. There are a great many browser features (e.g. web speech api for recognition and tts, webrtc, etc) that are just not lowest common denominator. Even if we stick with UI only, features like cross platform vector graphics are not trivial. Of course some libs like qt abstract it, but you're back to your same complaint except it's qml, css, and js (or often times worse, c++ if using widgets)

Re: From Markdown to remote code execution in Atom

#124
post #115

I wish there was a dead-simple, you-cannot-get-it-wrong, step-by-step, nothing-left-out, no-knowledge-assumed, all-in-one-document, not-spread-out-over-various-pages, tutorial/checklist on how to ensure your Electron app is as secure as possible. It shits me that it is a research task with all the attendant uncertainty about whether or not I did in fact make it secure. I do appreciate that security is complex and eve…

Security is never easy. It is always a battle. Maybe AI is the answer

AI is decidedly not the answer. Formal verification is the answer, and tooling around it.

Re: From Markdown to remote code execution in Atom

#125
post #122
post #120

Earlier quoted context omitted.

Instead of taking 1 high quality UI paradigm that works exactly the same on virtually every computer and spending time solving my business problem, you'd like me to spend time on learning the weirdnesses of each platform's native UI. No thanks!

If you consider web to be "high quality UI paradigm", then you might be seriously interested in learning other UI tools. You know like literary any other UI library on Earth where vertical centering of one element in another is just a basic functionality not a task that requires a hack.

You need some Flex in your life: https://css-tricks.com/snippets/css/a-guide-to-flexbox/

Re: From Markdown to remote code execution in Atom

#126
post #122
post #120

Earlier quoted context omitted.

Instead of taking 1 high quality UI paradigm that works exactly the same on virtually every computer and spending time solving my business problem, you'd like me to spend time on learning the weirdnesses of each platform's native UI. No thanks!

If you consider web to be "high quality UI paradigm", then you might be seriously interested in learning other UI tools. You know like literary any other UI library on Earth where vertical centering of one element in another is just a basic functionality not a task that requires a hack.

[deleted]

Re: From Markdown to remote code execution in Atom

#127
post #120

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.

Instead of taking 1 high quality UI paradigm that works exactly the same on virtually every computer and spending time solving my business problem, you'd like me to spend time on learning the weirdnesses of each platform's native UI. No thanks!

Or use one of the systems that is already well-established. Here's just a few.

WxWidgets [0], bindings in: Python, Perl, Ruby, Lua, C++, C#, and others.

Qt [1], bindings in: JS, Python, C++, and others. Also has QML to make things easier.

Tk [2], bindings in just about everything. Included in most Python distributions.

Kivy [3], Python only.

Java/FX [4] Java and other JVM languages.

If your main problem is the duplication effort between the web and an application: Qt is the simple path. Qt includes WebKit. Everything Electron can do, Qt can do, but faster and smaller.

[0] http://wxwidgets.org/

[1] https://www.qt.io/

[2] https://www.tcl.tk/

[3] https://kivy.org/#home

[4] https://docs.oracle.com/javafx/2/overview/jfxpub-overview.ht...

Re: From Markdown to remote code execution in Atom

#128
post #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 G…

>the ease of CSS/HTML

Is this a joke? I can't use either of those for more than 5 minutes without wanting to commit self-harm.

Re: From Markdown to remote code execution in Atom

#129
post #36
post #26

Earlier quoted context omitted.

So you're saying software OEMs need to pick one of Windows or MacOS and not support any other platforms?

No, you create a proper abstraction layer that maps to native plaform elements. For example, IFileDialog maps to a Cocoa dialog on macOS, file picker on UWP, open dialog on Win32, document selector on Android and so on. Yes, it takes some initial effort, but it only needs to be done once.

Yes, it takes some initial effort, but it only needs to be done once.

It needs to be redone for each platform every few years as apis and visual styles change. Cross platform libraries are notoriously hard and usually end up in the uncanny valley (qt, swing etc).

Platform vendors of course any devs to buy into just one platform, they want and need the lock-in. Using web UI is a way to sidestep that.

Re: From Markdown to remote code execution in Atom

#130
post #115

Earlier quoted context omitted.

Security is never easy. It is always a battle. Maybe AI is the answer

AI is decidedly not the answer. Formal verification is the answer, and tooling around it.

My impression is that making everything formally verified is a lot of work and it would be very hard to make formally verified code as easy to write as non-verified code.
Post reply on HN