[mschuster91]

But the JS ecosystem learns things! They implement tree shaking and other stuff to improve performance!

Obviously real programmers learned all this decades ago - same for the "NoSQL" followers who after years of struggling with piles of cr.p finally (re)discover what a true ACID-capable database is...

I'm just waiting for the JS world to rediscover threads and proper multitasking, but given the track record I don't expect that in the next decade.

Seriously, the JS world is a hellhole of disasters, and many of them easily preventable if the people acting as "evangelists" actually had a bit of clue about what they're talking. And to top it off, a JS-only implementation will never be nearly as fast as well-written C or even C++ code, no matter how hard "evangelists" push it.

[movedx]

You'll probably get down-voted for your choice of language, but I agree.

I actually feel what's going to happen is the JS community will start implementing WebASM and other very low-level mechanism to improve the speed of slow software components and, given enough time, will eventually just have entire binary applications being delivered through the browser (automatically installed, without asking you.)

We'll go from `yum install software-suite` to `https://www.software-suite.com/` and the results will be the same. We'll have gone full circle.

[corndoge]

I agree with you. Actually I think that at this stage, the browser should be viewed as a sandbox that can fetch and execute arbitrary binaries; then we can finally get past all the hacks that Web tech (js/dom/html/css/templates) is using to approximate that and actually build it for that express purpose, which should lead to better security (since we aren't pretending about what's happening -- it's untrusted code execution) and a better UX overall.

[johncolanduoni]

I don't think the developers of any of the main browser's JS engines pretend they're not going to be executing hostile code. In fact I struggle to think of better embeddable software sandboxes than V8, SpiderMonkey, etc., especially now that they support WebAssembly.

[movedx]

Good point. These are smart people developing these sandboxes - they know what they're getting themselves, and their users, in for.

[movedx]

Yep.

We need to just skip all this JS and other web standards nonsense and skip straight to the writing Golang, Rust, C, whatever, that is delivered (as a binary) through the browser and into a nice little sandbox that exposes system level APIs (notification, temp file storage - everything we can already kinda do in JA now) so we can get on with a faster, better web.

(Kind of makes me think we have this now: Docker/containers. Hmm... hit an HTTPS endpoint and a Docker container is downloaded and the application is launched...)

[pitaj]

This isn't a JS issue. It's an optimization bug in the CSS rendering.

Holy crap the superiority complex is just gushing out of you. Sometimes it's just incredible seeing how much shit "real programmers" will throw at the "fake programmers."

The Electron platform is popular because it's easy to work with when building portable GUIs. It's especially easier for webdevs who use the same languages all the time. They can accessibly hack on the editor, create plugins, etc. Just like Java devs use Eclipse and IntelliJ, and C# devs use Visual Studio, and Obj-C / Swift devs use XCode.

If it's so easy to build portable GUIs the "right way", why are Slack, WhatsApp, Google, game producers, hardware vendors, browsers, etc all using this technology?

Also, I don't understand why you keep complaining about all of these Electron apps. Do you work on desktop GUIs yourself? Have you built GUIs that hook into mainly CLI programs like many of these Electron apps?

[frozenport]

But C++ GUI toolkits are disaster. While any kid can put together a reasonable looking JS app, the default options in toolkits like Qt are junk. Common features like centering a QComboBox aren't there. Quickly, you're going to have to custom build every widget. Then you need to hire engineers to manually press all the buttons. These engineers won't be too good at art stuff, so guess what, now you need to hire graphic designers - many of whom aren't familiar with Qt. You're best bet is to pay a consulting company tons of money to make a GUI, which you will struggle to keep updated. Even with unlimited cash, the lead time for this is unjustifiable.

Do customers really want to trade performance for actual money? Are people still browsing the fatweb?

[simion314]

From what I remember centering in Qt is possible and easy. Why would you need designers to know, Qt, they will show you a picture and you implement that. hopefully they don't want elliptic windows with elliptic buttons with animated shiny/metalic colors and animated shadows, you can get that but you may need to create custom widgets. Don't even compare a GUI Listbox or similar widget that can handle 10000 items because it smart to create and paint only visible stuff and the html DOM UL/OL that can't handle so many items, and you have to implement the smart list yourself. Same with DataGrids , for html you probably need to buy some code that has part of the functionality present in normal GUI toolkits.

[mschuster91]

> Common features like centering a QComboBox aren't there

Well, browsers didn't have proper vertical centering for UI elements for ages, too. Not to mention it's between a PITA and impossible to do "simple" things like styling a file upload button (only works via pseudo CSS on Chrome) or cross-browser styling of a scrollbar (usually people tend to handroll JS stuff, which is expectedly slow and unintuitive).

> You're best bet is to pay a consulting company tons of money to make a GUI, which you will struggle to keep updated.

It's the same in the Web sphere, with the added difference of clients not simply accepting "you cannot style a file upload button/input element cross-browser-like", they will usually answer you something along "it's the Web and HTML5 after all!!!". You will always need specialized engineers, designers and UX designers for a well-working app, no matter if native or web.

(But yes I agree with you that C++ GUI toolkits are a desaster, especially when cross-platform! And especially the build tooling coughs at autotools)

[LeoNatan25]

What saddens me is that instead of improving the web software development process with tried and tested methodologies, the inverse happened, and the web and its terrible software ecosystems and perpetrators are somehow seen as the "cool kids" of software development. When observer pattern is seen as the holy grail of modern web development, you know we are in trouble.

[tracker1]

The observer pattern isn't sold to everyone... The thing is, Web browsers have been nearly as diverse as OSes both historically and recently... But, you get a mostly compatible UI and runtime engine that's installed on pretty much every personal computing device out there. There's a lot to be said for that.

As to the "cool kids", they exist in every corner of things that get done by people. I think WebASM will open up to higher-level tools once it's widely available, and signalling between the UI layer and WebASM code becomes easier to deal with.

[LeoNatan25]

> But, you get a mostly compatible UI and runtime engine that's installed on pretty much every personal computing device out there. There's a lot to be said for that.

Only "lowest common denominator" comes to mind.

But to the point of this thread, what bothers me is the transcendence of web tech outside of browsers, where a technology known historically for terrible practices with a very low barrier to entry is now considered the "assembly" of all these platforms, such as mobile and desktop, and the developers, that until yesterday could only make a web page that loads 20MB of dependencies to show a few paragraphs of text, now call themselves "mobile developers" or "full-stack developers".

[tracker1]

Well, I take a bit of offense to the last statement... in only that JavaScript is just as, or more valid as a server-side language for development as any other scripting language is. The engines themselves tend to be more optimized than alternatives, and combined with NPM/CJS modules a much nicer experience than many of the alternatives.

As to being able to target mobile/desktop, why not? I mean with Cordova and Electron you can target 4+ platforms with minimal code variance. And in most cases the performance is good enough, until you need more. And React-Native can go even further towards native/compiled language performance, with slightly more variance.

Yes, there is more memory and cpu use than alternatives, but there's also a real cost in developer time, and time to launch. In many cases it's the difference between having platform X, or not... the alternative is nothing, not something better in most cases.

[mschuster91]

"Tried and tested" cannot be sold for money (as it's already known).

So in order to create demand for consultants the ecosystem repeats history and willfully messes up... and we all know where the consultantocracy finally ended up goes looking at Enterprise FizzBuzz

[kitsunesoba]

Assuming this is Qt Widgets we're talking about, this issue can be sidestepped entirely by just going with native style controls with tastefully placed brand accents. The need for each app to have a unique UI theme unto itself is questionable at best.