Hacker News Reader

Comment by horsawlarway | Hacker News Reader

"Bah humbug, the old stuff is good enough for me!" is a shitty answer.

Why would you not want a toolkit that makes rich application experiences across multiple platforms easy and standard?

I get that performance is a problem with the tooling in its current form (arguably...) but that's not a reason to ignore the problem electron is solving: creating complex UIs using things like WinForms, QT, GTK, Cocoa, etc SUCKS.

It requires learning vendor specific toolchains, different builds for different platforms, and an incredible amount of wasted time that could be spent developing your business logic instead.

View on HN

I'd argue the old stuff is better, not simply "good enough" vs. Electron etc. What have we gotten in exchange for the crap performance and extra RAM usage? Pretty animations? I don't need those; in fact they're distracting and annoying. You absolutely can make "pretty", complex UIs in native/cross-platform toolkits, and personally I find them much nicer to work with than the horror show that is HTML/JS/CSS.

I get that Electron brings benefits: it's dirt-easy to build something that'll run on Windows, MacOS, and Linux, without having to know a bunch of platform-specific details, and if you already have a webapp, you can leverage a lot of that work, but in the end it just feels to me like people cutting corners. You get a sub-standard app, but you don't have to pay developers to build for each platform plus the web. Which I think is a perfectly reasonable business trade off to make; I'm just not happy with the result as a user.

I'm glad you understand one part of Electron adoption, but the other part is user experience.

Apart from being resource hogs Electron apps are usually delightful. And usability (for non programmers!) is what for a large part decides the value of your app. You want users to use your program, right? What they see is the UI. Making it easy to develop good UIs is important for a GUI tool (obviously!).

> Pretty animations? I don't need those; in fact they're distracting and annoying.

Animations are an important tool for showing transitions between states.

Pasquale D'Silva has a bunch of good blog posts explaining how they can help an interface:

- https://medium.com/@pasql/transitional-interfaces-926eb80d64...

- https://medium.com/elepath-exports/spatial-interfaces-886bcc...

We can totally accept old-fashioned UI as developers. Hell, we even work in our terminals all day or use i3wm instead of any desktop environment. However, most apps target normal end users, not developers. Show your cousin whether she likes a flashy "modern" UI more or a succinct UI more, the answer is a no-brainer. And then try to explain to her what RAM usage actually means... The same as asking her whether she prefers using i3 or Windows, Vim or Word etc.

creating complex UIs using things like WinForms, QT, GTK, Cocoa, etc SUCKS

I think that this depends on your background. Personally, I would rather do a UI in QT than Javascript. I like that Qt supports high level components such as trees:

  https://doc.qt.io/qt-5/qtwidgets-itemviews-simpletreemodel-example.html

With Qt I can also use a lot of the experience that I gained 5 years ago on a UI today. Any Javascript UI experience that I picked up 5 years ago is obsolete.

It annoys me when people say something sucks without taking the time to understand it.

"Any Javascript UI experience that I picked up 5 years ago is obsolete."

That is only true in the sense that your Python 2.x experience didn't translate into your Python 3.x experience. That is, I think the overlap is similar on a language level. The difference lies in the libs/frameworks.

No its nothing like a minor language change. This actually happened to me and my Javascript UI experience (Jquery) is obsolete in the world of React and Angular or whatever the flavour of the month is.

Python's transition from 2 to 3 was anything but "minor"... further, jquery was designed and developed for a completely different reason than React or Angular at a different time in the evolution of the web. Your jquery knowledge still works I promise... the thing is there are better options.

> Python's transition from 2 to 3 was anything but "minor"

For the purpose of this discussion — carrying learned knowledge forward — it was minor.

If you learned Javascript and not jQuery then your experience is just as relevant today, with the main difference being that Javascript has had a lot of improvements since then (e.g. myArray.includes vs myArray.indexOf(x) != -1).

Even jQuery is still helpful if you think of how it's accessing the DOM rather than just a set of magic functions to make things happen.

If you know Javascript you can learn Angular or React or Vue fairly quickly.

What does obsolte mean actually? Today you still can build web app by jQuery.

Obsolete does not mean you cannot use your knowledge anymore. It means that community are shifting interested into new thing, maybe for better or for worse.

In this case, I do not think stick with JQuery or old framework for 5 years is productive for programming. If that happen to any community I would say that is a downside, not an upside.

Except for that fact that community and newly graduated junior developer are ahead of me in something. I can live with that

> I would rather do a UI in QT than Javascript.

This has nothing to do with Javascript. It's much easier to do complicated UI using a web browser's layout engine than it is using one of the above frameworks. For really simple stuff, yes it's about the same, maybe even easier with native UI, but if you ever need to do something outside of buttons and lists, things will get ugly fast. On a browser on the other hand, you can very quickly implement any component you can think of using well-documented CSS rules.

CSS rules still have a lot to improve compared with XAML styles, triggers and best of all, modularity.

> Why would you not want a toolkit that makes rich application experiences across multiple platforms easy and standard?

Because way more often than not the "rich" stuff are all fluff with no meat, end up taking wasting system resources and work badly with the rest of the system.

Sure, so we should try to make them better instead of sticking with things that are old and crappy.

Developers have already been working around the standard styles with all those technologies. It only took more time and effort. I look at the native apps I've installed and the standard layout is the rare exception. I mean no offense, but arguing that a standard set of controls would be enough for most of the applications would be faulty judgement at best, if not being delusional.

Also because it often violates the standard UI conventions for the given OS, so I have to learn how to use every application from scratch.†

Accessibility is another big one.

† The flip side is if you use the same app on different operating systems often. There are some apps that fall into that category for me personally, but I think your average user probably only uses two operating systems regularly: one on their mobile device(s) and another on their "real" computer(s).

The platform widget set is a language: when you look at a well-behaving application that uses such language, you immediately know what's a button, what's a menu, what's a tooltip, what's a label etc., and you can configure how ALL the applications look via applying a theme system-wide. Especially important if one needs certain color schemes or font sizes globally. Modern apps each have their own distinct language, and that puts the user at discomfort (and also danger, from time to time) as he through trial and error seeks how to use the thing to get what he wanted to do done. It's a feature when all the apps look like each other for the most part.

> "Bah humbug, the old stuff is good enough for me!" is a shitty answer.

Ignoring the snark, "Modern" is better should not be the default, either. Performance is a valid reason to ignore Electron.

That is the problem right there, not wanting to learn.

Reply on news.ycombinator.com