Ugh. I don't disagree with his analysis, but it's presented in a pretty biased way. I think his message will get lost when people read statements like: I'm no fan of Javascript, but it's clearly a...
Ugh. I don't disagree with his analysis, but it's presented in a pretty biased way. I think his message will get lost when people read statements like:
Developers around the world would still rather reach for the brain eating parasite which goes by the name of Javascript than those dusty battle proven RAD tools.
I'm no fan of Javascript, but it's clearly a useful tool for some people. And it's frequently pointed out that you can write crappy code in any language. Sticking to the facts instead of name-calling would have made for a better article.
From the way he writes, it seems like he genuinely doesn't entertain the idea that other people interact with technology differently to how he does. You really can't see the difference in end user...
From the way he writes, it seems like he genuinely doesn't entertain the idea that other people interact with technology differently to how he does.
I can’t quite figure it out, why do people prefer writing Electron apps as opposed of having a thin backend layer that communicates with the frontend in the user’s existing browser via websockets or long polling or whatever. All you need to do is create a small native wrapper that opens a new tab in the user’s existing browser and package it in an platform specific installer.
You really can't see the difference in end user experience between something that looks and behaves like its own, dedicated, standalone application with all that implies, compared to just opening a random tab somewhere in the user's browser? You can't see how one is clearer from a UX perspective? You can't see how, even if they happen to be functionally identical in your use case, the blurred line between dedicated application and web page could be confusing to a less technical user?
Even putting all that aside, bundling the major dependency (browser engine) compared to relying on whatever configuration the user happens to have is a vast win for the developer. He acknowledges it further up with a bundled JRE installer, so why not here as well?
I don't even like Electron that much, but claiming not to understand why it's valuable (even if not optimal) makes me think less of him, not think less of it.
The icing on the cake is the casual dismissal of mobile applications towards the end. I spent the whole article thinking that "cross platform" in 2020 can't reasonably exclude iOS and Android, only to find out at the end that he did so intentionally.
Like it or not (and again, I have a lot of concerns about walled garden operating systems and their increasing prevalence), phones are the primary mode of interaction for the majority of users and the only one for many millions of people globally. If you consider that irrelevant, you're building for yourself rather than for the user.
Personally, I can't think of any non-trivial GUI app that can be designed in such a way, as to be convenient to use both on desktop and on phones. Desktops can use tabs, windows, tables, dropdown...
The icing on the cake is the casual dismissal of mobile applications towards the end. I spent the whole article thinking that "cross platform" in 2020 can't reasonably exclude iOS and Android, only to find out at the end that he did so intentionally.
Personally, I can't think of any non-trivial GUI app that can be designed in such a way, as to be convenient to use both on desktop and on phones. Desktops can use tabs, windows, tables, dropdown menus, etc. Mobiles use activity screens, sidebar menus and need to worry about battery and tons of different screen sizes. So, since you have to re-design your app anyway, what's the benefit of being cross-platform between desktop and mobile? I see benefits being cross-platform between Mac, Windows and Linux. I see benefits being cross-platform between iOS and Android. But all that together? Why?
I think we're looking at it slightly differently. First and foremost, I'm separating the UI framework from the design: the former takes your code and turns it into pixels, the latter defines what...
I think we're looking at it slightly differently. First and foremost, I'm separating the UI framework from the design: the former takes your code and turns it into pixels, the latter defines what those pixels should look like on the user's screen.
Why bother sharing a framework if the designs are going to differ anyway? Because one thing the author is dead right about is GUI frameworks generally being complex, idiosyncratic, and difficult to learn. If your team can share knowledge, share code, and run the same tests across multiple platforms then it reduces the surface for bugs and removes a lot of opportunities for documentation, functionality, and fixes to go out of sync.
Since we're talking about cross platform frameworks at all, we've already accepted that we're happy with a non-native look and feel here; while a truly beautiful native experience may be the gold standard, I'll take a clearly non-native but well thought out application over an "uncanny valley" of misplaced pseudo-native widgets. Non-native is good enough for Slack, Spotify, Photoshop, VS Code, et al, after all.
This gives us an opening to question how we define the breakpoints between those designs. Having a design for Windows/Mac/Linux and a design for iOS/Android is one perfectly reasonable way to do it, but not the only way. The iPad Pro and Microsoft Surface, for example, are both bridging the mobile/PC divide from opposite sides of the gulf - how much do we want the UX to differ between those two devices, between either one of them and a phone, and between either one of them and desktop? For me, there are three key distinctions: pointing device vs touchscreen, size and orientation of screen, and user expectation. Two of those three have many years of best practice to draw on from the web design world, where OS is almost irrelevant.
All that said, fully cross platform frameworks are still in the minority and they're undoubtedly less mature than their desktop-focused cousins. There are many totally reasonable arguments not to use them, even in light of everything I said above. I just don't buy "I'm not considering mobile" as one of those arguments.
Complex -- sure. But difficult to learn? I don't know about that, in my experience -- not really. I can see the benefit of that, kind of. Though I'm not sure how much of an overlap in code there...
Because one thing the author is dead right about is GUI frameworks generally being complex, idiosyncratic, and difficult to learn.
Complex -- sure. But difficult to learn? I don't know about that, in my experience -- not really.
If your team can share knowledge, share code, and run the same tests across multiple platforms then it reduces the surface for bugs and removes a lot of opportunities for documentation, functionality, and fixes to go out of sync.
I can see the benefit of that, kind of. Though I'm not sure how much of an overlap in code there would be, and if that possibly small overlap in code and tests is enough to justify huge additional efforts on the developers of the framework itself.
For me, there are three key distinctions: pointing device vs touchscreen, size and orientation of screen, and user expectation
But that last one is where the major difference between behaviour of mobile and desktop apps lies, isn't it? Personally, I would much prefer if we had two different cross-platform frameworks, with one striving to give the best desktop experience, and the other -- the best mobile experience. It's not "I'm not considering mobile" for me, rather that I don't want to mix two worlds that are so different in my mind.
All fair - in my opinion there's more overlap than you'd think, and more value in consistency throughout the development, but I'll readily accept that it does come down to a matter of opinion.
All fair - in my opinion there's more overlap than you'd think, and more value in consistency throughout the development, but I'll readily accept that it does come down to a matter of opinion.
While any hate JavaScript gets is well-deserved, it's just a matter of reality: The web is powerful in its reach, which makes JavaScript powerful by association. The true irony to me, is that this...
While any hate JavaScript gets is well-deserved, it's just a matter of reality: The web is powerful in its reach, which makes JavaScript powerful by association.
The true irony to me, is that this is an article about creating GUIs, which is as much a UX issue as it is a technical one and here's a long article criticizing the state of GUI frameworks which barely spends a word on whether the resulting UIs are... usable.
I swear to god, the only reason open source software (I use the term "open source" to refer to a variety of idealistic, anti-monopoly movements) isn't more wildly used is because of bad UX. It's just as much work to make a program usable as it is to program its core, under-the-hood features and almost nobody in these communities seems to respect this (notable exceptions include Firefox). It might be tedious to deal with JavaFX' hyper-OOPed structure or JavaScript's lack of type safety, but people actually produce software with them. And hey, Visual Studio Code is based on Electron and the interface is on point, which I'll happily sacrifice a few ms of performance for.
Thank you! I feel the same way. I really dislike most web apps because their interface is so different from the one I chose to purchase because I felt it suited me best. And I can usually tell...
Thank you! I feel the same way. I really dislike most web apps because their interface is so different from the one I chose to purchase because I felt it suited me best. And I can usually tell when the author used a cross-platform UI framework because it has similar issues. They might have actual native buttons, but they're spaced weirdly. Or they look native, but don't react properly. Or whatever. That's far more important to the user in me than the issues with the tools used to create them. (Although the developer in me certainly does appreciate the issues with the tools.)
You're telling me JavaScript isn't a royal pain? Its only justification is spread through web usage, and that might trump all of its weak points, but holy hell is it a bad language! It's a...
You're telling me JavaScript isn't a royal pain? Its only justification is spread through web usage, and that might trump all of its weak points, but holy hell is it a bad language! It's a historic mistake we have to deal with.
Honestly, the whole web is. HTML, CSS... it's all technology that was meant to format a few lines of text on a 640x480 monitor, based on type writer analogies. Never for the monstrous web presences we see today. We only endure it because of the benefits of a common standard.
I honestly would be ready for a "web 2". Not "2.0", a whole redo. There's got to be something better. The amount of man-hours wasted on fiddling with the many quirks of HTML positioning or JavaScript errors is mind-boggling, we have entire branches of software development dedicated to avoiding the bad parts of it, fighting it. It's a bizarre circus.
I ain't telling you nothing. I'm just surprised by a sentiment this heavy towards something that doesn't appear to be as odd and maligned as you describe. What are the alternatives? What are the...
I ain't telling you nothing. I'm just surprised by a sentiment this heavy towards something that doesn't appear to be as odd and maligned as you describe.
What are the alternatives? What are the potential alternatives?
Does the lack of good alternatives make bad thing less bad? It's still bad and there are no good alternatives, which makes bad thing optimal, but not good.
Does the lack of good alternatives make bad thing less bad? It's still bad and there are no good alternatives, which makes bad thing optimal, but not good.
None, really. But I can't believe that a significantly better alternative is beyond reach. This is the defining technology of the world and likely will continue to be for decades if not centuries....
What are the alternatives? What are the potential alternatives?
None, really. But I can't believe that a significantly better alternative is beyond reach. This is the defining technology of the world and likely will continue to be for decades if not centuries. Do you think people will fiddle with CSS hacks 50 years from now? I find that thought depressing.
Also I already acknowledged it as being largely the best compromise today, I don't deny that! But, you know... I don't feel like listing all the JS quirks and bizarre CSS spacing issues out there, it's been done to death. Generally, it's just full of edge cases and attempts to alleviate user errors (think JS using but not requiring semicolons, browsers just assuming certain element behaviors and collapsing empty divs, etc). It's all stuff that can be "coped with" but that coping takes so much time, requires so much cruft and even slows things down. It's pretty obvious to me. If it isn't to you, I welcome your positivity but I can't find many reasons to share it.
The thing is: I work with all of this nonsense. I find the method to the madness more valuable than the quirks I have to deal with because it aids my self-expression. I could learn a real...
The thing is:
I work with all of this nonsense. I find the method to the madness more valuable than the quirks I have to deal with because it aids my self-expression. I could learn a real programming language – bullshit a term that it is – but the Web makes for such a beautiful fucking platform for getting your ideas out there that it's just... okay.
But I'm not blind to the flaws. I may choose to accept them and work around them, but I don't dismiss them. All this backwards compatibility shit in JS? All this having to deal with popular libraries and the way they name things 'cause the Web's supposed to be a democratic platform? Hoo boy.
I've been thinking to myself for a while that I'd be completely fine with a complete overhaul of the Web frontend. No backwards compatibility in mind whatsoever: clean slate, only for those developers who's willing to support it. Maybe leave the languages as is 'cause that's what I already know, but yeah, fuck it, I'd learn a handful of new ones if that's what it takes to no longer get bogged down in a swamp where IE9 support is still a meaningful benchmark for code quality.
I asked about alternatives, however, because all this musing is ultimately pointless. The thing that matters when you see a problem is doing something about it; bemoaning it being there is the bystander syndrome I want to take no part in. I asked because maybe someone has come up with something meaningful already: something that could maybe even remotely approach the thing that would replace the HTML+CSS+JS framework.
I think Markdown's gotten close to some sort of a foreground layer of layout composition: it doesn't replace HTML: instead, it abstracts it to a point where the user no longer has to worry about how the underlying layout's going to behave because it's been narrowed down to a list of things that are known to work unless you go out of your way breaking them.
If you could use something like HTML – an Assembly of its kind which browsers understand natively – and be able to use a limited subset of it – like C++, or like JS, or like Brainfuck which browsers also understand natively – for your regular blog-grade posting, that would be splendid. That way, you still retain a powerful codebase that could be abstracted to the level where you don't have to have a degree in CS to make a webpage (like the myriad of frameworks and CMSes allow today). You could, if you wanted to, write SVG by hand in your code – but if you don't, you could just insert a link to a partial containing said SVG and do other meaningful stuff. Enabling amateurs without disabling professionals.
But I'm no fucking expert in this. The best I can do is speculate based on my own experience. Which is a shame, 'cause I'd really like to be involved in something like that and contribute to it in what ways I can.
Also, if I may address a minor concern I have with your comment:
It's pretty obvious to me. If it isn't to you
I just left a long-ass comment breaking down critically this sort of approach to commentary. It's probably going to get deleted 'cause it has a lot of profanity and what you might consider excessive countering.
The reason I mention this is because I cannot fucking stand people assuming shit of me, especially in such passing manner. In fact, this was one of my first comments here, and I stand by it still. If you want to converse on a matter, I'm open to it. If you want to know how I feel about something, I'd be glad to answer. If you want to know what my outlook is on a certain aspect of the subject matter, your best bet is asking me.
It's not easy to criticise JavaScript from inside. I don't think it's that weird given the influence from Smalltalk, and in fact I think prototypes are pretty cute. But we need to step back and...
It's not easy to criticise JavaScript from inside. I don't think it's that weird given the influence from Smalltalk, and in fact I think prototypes are pretty cute.
But we need to step back and ask why we'd use it in the first place: to make web documents dynamic. For that dynamic content, we usually don't want to manipulate an arbitrary tree, we want shallow structured data rendered as presentation components.
From this perspective I think the mismatch between web apps and JavaScript becomes clearer. JavaScript isn't very good at creating DOM nodes in this way ― or really at all. From MDN:
constsect=document.querySelector('section');constpara=document.createElement('p');para.textContent='We hope you enjoyed the ride.';sect.appendChild(para);
I think it's silly to work with the document on such a low level, because we're using a scripting language, which was designed for document manipulation, specifically to make part of a document. Template instantiation is frankly no simpler.
Imagine if JavaScript itself, the language of 1995, had a tighter type system and element creation as a primitive feature. (Imagine if permitted content were type checked.) Imagine if Node.js, when it was inevitably created, could already represent documents in memory, and using an HTML template on a server were exactly the same as within a web browser.
That's just a bit about JavaScript. Here's some about the DOM as a whole. (I take it with salt but there's some good stuff.)
In reality, most styles don't actually cascade: paddings and backgrounds are set on individual elements. The inherited ones are almost all about typography: font styles, text justification, writing direction, word wrap, etc.
Allow me to get jest out of the way first: Ah yes, the good stuff. (The actual content is all the way down here.) It's also a little disconcerting that an article talking about how full of crap...
Allow me to get jest out of the way first:
(I take it with salt but there's some good stuff.)
I only found out 'cause I wanted to dull the contrast a little. Couldn't figure it out! The <body>background-color was white, and I guess it inverts it somewhere down the tree but I couldn't be bothered.
But yeah, it has some good points. I would not want padding to be inheritable, but the fact that it isn't – in an ostensibly cascading stylesheet – is suspect. I disagree with some of those – like the fact that it's better if font values be set on the text child (as if we need any more confusion) – but it is a decent overview.
Well... Now I can see it. You're right: this kind of element creation is... less than perfect. I can perfectly see why JSX is so popular. Guess I just never thought about it from the perspective of how poorly-thought-out it is.
we want shallow structured data rendered as presentation components
Not OP, but for me: React. We can quibble about syntax (I prefer Hiccup to JSX, and I know I'm in a vanishing minority), but the core concept of "data goes in, UI comes out, data changes, UI...
What would that look like?
Not OP, but for me: React.
We can quibble about syntax (I prefer Hiccup to JSX, and I know I'm in a vanishing minority), but the core concept of "data goes in, UI comes out, data changes, UI changes" is so closely suited to what most people actually want to do that it's transformed the web, mobile, and desktop development landscape in the space of a few short years.
Components are understandable and composable. They map the tree of data to the UI, and they do so in a way that developers can reason about. It isn't perfect, but it's a big step in the right direction; from what I've seen, Flutter is structured in a very similar manner, and given that it has such a different technical basis, I think that says a lot.
What I don't understand is the difference between tree syntax and something like JSX or Hiccup. Is it that you get to define your components as an object, as opposed to running around the...
What I don't understand is the difference between tree syntax and something like JSX or Hiccup. Is it that you get to define your components as an object, as opposed to running around the already-existing DOM tree?
You can do that with vanilla JS without much difficulty with template literals. And don't you have to navigate DOM with JSX/Hiccup anyway?
Bear in mind: I've never worked with either, so I may be missing key information.
To answer your last question first: no, you don't, and that's particularly important because DOM manipulation (a) is prohibitively slow at scale and (b) assumes your JS runtime has a DOM...
And don't you have to navigate DOM with JSX/Hiccup anyway?
To answer your last question first: no, you don't, and that's particularly important because DOM manipulation (a) is prohibitively slow at scale and (b) assumes your JS runtime has a DOM implementation at all.
The core of what React provides is an extremely fast virtualised DOM and a diffing algorithm that can efficiently figure out the minimal changes between two states of that DOM. Really, that's what React is as a piece of software - although for good reason people are generally more familiar with what it does.
It's probably also worth mentioning that I'm not tied to React as a specific implementation - I'm just using it as the most well known instance of these ideas.
Is it that you get to define your components as an object, as opposed to running around the already-existing DOM tree?
I think we're broadly on the same page there - it makes the mental model much clearer: this component, given this input, will produce this output. You don't need to worry about which bit of the DOM you're finding, or what you're editing, or what order you do things in, or what its existing state was. Data goes in, UI comes out, in a way that's easy and predictable to reason about.
You can do that with vanilla JS without much difficulty with template literals.
Template literals are strings, so they're great for some use cases, but not all; as I understand, they're basically the language native version of something like Handlebars.
Let's assume you've built your template components, nested them sensibly, and you now have a function at the top that takes in a JSON object state and outputs a page of HTML. Server side, this should work fine; you could probably improve the dev experience a bit, but it does the job. If you're just sending static pages, and you don't want to deal with dependencies, this could be a solid way to do it.
On the client side, changing any part of state (say just the colour of a button in response to a click) would regenerate the string from the top, inject it in body.innerHTML, and cause the browser to re-parse and re-render the whole page from scratch. It's slow enough to be untenable on any complex page, and the alternative of keeping track of certain components' mount points, generating only those strings, and replacing specific DOM nodes manually just brings back the original problem of synchronisation between data and view. Automating that process of tracking and applying minimal changes is what the React diff is built for.
The other advantage to having a DOM without relying on an external implementation (i.e. the browser's) is that you don't have to output HTML at all. You can build and output whatever you like, as long as it follows the same structure. React Native, for example, outputs iOS or Android native components using the exact same technique. There have been experiments in rendering straight to canvas, which in turn could likely be extended to use something like Skia to draw straight to the screen. That last example would end up with something very akin to Google's Flutter, which uses a "widget tree" rather than a "virutal DOM" but otherwise provides a broadly similar dev experience.
This is something I've encountered when designing the code base for Intergrid. Its desktop counterpart, by the words of its developer, "redraw[s] everything", which I knew would be a ridiculous...
It's slow enough to be untenable on any complex page
This is something I've encountered when designing the code base for Intergrid. Its desktop counterpart, by the words of its developer, "redraw[s] everything", which I knew would be a ridiculous proposition on the Web, what with the massive overhead of it all compared to more-barebones system graphics.
Right now it searches for the specific element to change. In the future, I was planning on writing an engine that sounds suspiciously like React in the way you describe it: more akin to a state manager, with DOM being just the source of output.
Which is to say: hoo boy am I aware of that. :)
I've just looked at React as a JS library. The development version shocked me at being 100kb+ – Intergrid's unoptimized engine is almost twice smaller – but the production version is just 12kb, which is... not what I expected.
But then, React DOM library is a whopping 900kb+ uncompressed and 100kb+ compressed.
That said, thank you for mentioning React. It took me on a minor journey, and I found out a few important things for my own dev experience that I could stand to replicate.
Glad to hear it! Can't vouch for it personally, but Preact might suit your needs if you're looking for a slimmed down and performance focused version of the React API.
Glad to hear it!
Can't vouch for it personally, but Preact might suit your needs if you're looking for a slimmed down and performance focused version of the React API.
For building a UI, Dart and Flutter are a promising alternative. I haven't kept up but I think using it anywhere other than mobile is still experimental, though.
For building a UI, Dart and Flutter are a promising alternative. I haven't kept up but I think using it anywhere other than mobile is still experimental, though.
I'll be the first one to agree with you about how bad JS is, and there are many stupidities in HTML, but I would not call CSS bad at all. CSS is well respected to the point that I see it's...
I'll be the first one to agree with you about how bad JS is, and there are many stupidities in HTML, but I would not call CSS bad at all. CSS is well respected to the point that I see it's influence in many other UI toolkits. Heck, there is a CSS analogue right in at least two of the toolkits in the article (qt and JavaFX).
It's funny how languages that make it simpler to produce code suddenly become more popular. Most people who code – particularly in JS – are not programmers in the traditional understanding of the...
It's funny how languages that make it simpler to produce code suddenly become more popular.
Most people who code – particularly in JS – are not programmers in the traditional understanding of the term. They don't seek performance as the ultimate goal aside from the goal itself. They don't strive to memory-manage so that their app takes up as little RAM space as possible. (Which is apparently a thing? I dunno – I'm not one either.) They just want to reify their idea.
Much like amateur photographers who "make it difficult" for professionals with their easily-accessible equipment and no painstaking training.
Much like amateur musicians who "don't get it" because their tools were an app and a YouTube video, not hours of experimentation on a faulty keyboard that didn't play certain sounds right.
"Old men shouting at clouds" is not a new trope. "Professionals cursing amateurs for not being professionals" is just barely younger. It's okay to teach non-pros about things you know as a pro, 'cause they're usually good ideas that are worth picking up. Upset, in the fashion it's being expressed in the article, only begets upset: nobody's learning, nobody's better off.
Also, can I ask you all, have you ever done cross platform (as in Mac/Windows/Linux) development before? When I was doing it, it didn't seem very difficult to keep my business logic separate from...
Also, can I ask you all, have you ever done cross platform (as in Mac/Windows/Linux) development before? When I was doing it, it didn't seem very difficult to keep my business logic separate from my UI logic, and it didn't seem very difficult to me to use the native UI framework on the various systems. (I was only targeting Mac and Windows at the time, though, not Linux.) But I will admit that what I was writing (image and video processing plug-ins) didn't need a ton of UI. I did write some custom views to display custom data types. It seemed pretty straightforward to me at the time. Has that changed? Is there something that makes a need for a cross-platform toolkit essential these days?
If I know one system and need to learn another, I'd rather learn the native one than a different one that's supplied by neither system (and hence may go away in the future before the platforms I'm working on do). It seems like it will take the same amount of work. If I have to learn a 3rd, then maybe it starts to be attractive. I guess that would depend on how complicated the thing I'm working on is. If it's just standard windows with standard controls, I don't know that it would be worth it to me.
I did (well, still do), and I chose JavaFX. Our team is pretty small, so the idea of first writing and then supporting two different apps was quite daunting. And it would have been two different...
I did (well, still do), and I chose JavaFX. Our team is pretty small, so the idea of first writing and then supporting two different apps was quite daunting. And it would have been two different apps, since no-one wanted to touch C++ with a ten foot pole, so to be native we'd have to write in C# for Windows and use something like Rust/Go and GTK on Linux, and you can't really keep your business logic intact and separate UI that way (well, you can, but it would be not that trivial).
Nowadays, I find that it's easier to just use MonoGame even for application UIs. It's a game framework which allows me to do some really fancy stuff like write shaders for custom stuff. I just...
Nowadays, I find that it's easier to just use MonoGame even for application UIs. It's a game framework which allows me to do some really fancy stuff like write shaders for custom stuff.
I just wrote my own UI and input libraries for it. I can design my UIs to work with mouse, keyboard, gamepad, touchscreen.
It's pure .net core (development works in windows, mac, linux) and works everywhere: Desktop, mobile, consoles like Xbox, PS4, Switch, etc.
Something nice with MonoGame is that it has a cousin project called FNA https://fna-xna.github.io/. Going from one to the other is rather seamless since they share the same API. There are also some really big players that rely on both those projects.
I've also seen a bunch of people using Godot for that. The engine itself or, rather, the IDE part of it is written in Godot itself, so it has a lot of UI controls that are working out of the box...
I've also seen a bunch of people using Godot for that. The engine itself or, rather, the IDE part of it is written in Godot itself, so it has a lot of UI controls that are working out of the box (and are also themeable)
I think that's the future. Game engines / framework are really optimized. And they give so much more freedom. Especially with MonoGame, you can really control your program's architecture.
I think that's the future. Game engines / framework are really optimized. And they give so much more freedom. Especially with MonoGame, you can really control your program's architecture.
There are plenty more alternatives. There's also this one, which is for whatever reason not listed in the previous link. Oni2 looks cool. I'd like to give it a shot. I wish they had pre-built...
Huh, that's exactly what I was ranting about today in another topic here (that I posted)! Though his style of writing is a bit nauseating, I agree with the general premise: there is no solid...
Huh, that's exactly what I was ranting about today in another topic here (that I posted)!
Though his style of writing is a bit nauseating, I agree with the general premise: there is no solid solution when it comes to cross-platform GUI, and it's not great that Electron is considered de-facto standard now.
Ugh. I don't disagree with his analysis, but it's presented in a pretty biased way. I think his message will get lost when people read statements like:
I'm no fan of Javascript, but it's clearly a useful tool for some people. And it's frequently pointed out that you can write crappy code in any language. Sticking to the facts instead of name-calling would have made for a better article.
From the way he writes, it seems like he genuinely doesn't entertain the idea that other people interact with technology differently to how he does.
You really can't see the difference in end user experience between something that looks and behaves like its own, dedicated, standalone application with all that implies, compared to just opening a random tab somewhere in the user's browser? You can't see how one is clearer from a UX perspective? You can't see how, even if they happen to be functionally identical in your use case, the blurred line between dedicated application and web page could be confusing to a less technical user?
Even putting all that aside, bundling the major dependency (browser engine) compared to relying on whatever configuration the user happens to have is a vast win for the developer. He acknowledges it further up with a bundled JRE installer, so why not here as well?
I don't even like Electron that much, but claiming not to understand why it's valuable (even if not optimal) makes me think less of him, not think less of it.
The icing on the cake is the casual dismissal of mobile applications towards the end. I spent the whole article thinking that "cross platform" in 2020 can't reasonably exclude iOS and Android, only to find out at the end that he did so intentionally.
Like it or not (and again, I have a lot of concerns about walled garden operating systems and their increasing prevalence), phones are the primary mode of interaction for the majority of users and the only one for many millions of people globally. If you consider that irrelevant, you're building for yourself rather than for the user.
Personally, I can't think of any non-trivial GUI app that can be designed in such a way, as to be convenient to use both on desktop and on phones. Desktops can use tabs, windows, tables, dropdown menus, etc. Mobiles use activity screens, sidebar menus and need to worry about battery and tons of different screen sizes. So, since you have to re-design your app anyway, what's the benefit of being cross-platform between desktop and mobile? I see benefits being cross-platform between Mac, Windows and Linux. I see benefits being cross-platform between iOS and Android. But all that together? Why?
I think we're looking at it slightly differently. First and foremost, I'm separating the UI framework from the design: the former takes your code and turns it into pixels, the latter defines what those pixels should look like on the user's screen.
Why bother sharing a framework if the designs are going to differ anyway? Because one thing the author is dead right about is GUI frameworks generally being complex, idiosyncratic, and difficult to learn. If your team can share knowledge, share code, and run the same tests across multiple platforms then it reduces the surface for bugs and removes a lot of opportunities for documentation, functionality, and fixes to go out of sync.
Since we're talking about cross platform frameworks at all, we've already accepted that we're happy with a non-native look and feel here; while a truly beautiful native experience may be the gold standard, I'll take a clearly non-native but well thought out application over an "uncanny valley" of misplaced pseudo-native widgets. Non-native is good enough for Slack, Spotify, Photoshop, VS Code, et al, after all.
This gives us an opening to question how we define the breakpoints between those designs. Having a design for Windows/Mac/Linux and a design for iOS/Android is one perfectly reasonable way to do it, but not the only way. The iPad Pro and Microsoft Surface, for example, are both bridging the mobile/PC divide from opposite sides of the gulf - how much do we want the UX to differ between those two devices, between either one of them and a phone, and between either one of them and desktop? For me, there are three key distinctions: pointing device vs touchscreen, size and orientation of screen, and user expectation. Two of those three have many years of best practice to draw on from the web design world, where OS is almost irrelevant.
All that said, fully cross platform frameworks are still in the minority and they're undoubtedly less mature than their desktop-focused cousins. There are many totally reasonable arguments not to use them, even in light of everything I said above. I just don't buy "I'm not considering mobile" as one of those arguments.
Complex -- sure. But difficult to learn? I don't know about that, in my experience -- not really.
I can see the benefit of that, kind of. Though I'm not sure how much of an overlap in code there would be, and if that possibly small overlap in code and tests is enough to justify huge additional efforts on the developers of the framework itself.
But that last one is where the major difference between behaviour of mobile and desktop apps lies, isn't it? Personally, I would much prefer if we had two different cross-platform frameworks, with one striving to give the best desktop experience, and the other -- the best mobile experience. It's not "I'm not considering mobile" for me, rather that I don't want to mix two worlds that are so different in my mind.
All fair - in my opinion there's more overlap than you'd think, and more value in consistency throughout the development, but I'll readily accept that it does come down to a matter of opinion.
While any hate JavaScript gets is well-deserved, it's just a matter of reality: The web is powerful in its reach, which makes JavaScript powerful by association.
The true irony to me, is that this is an article about creating GUIs, which is as much a UX issue as it is a technical one and here's a long article criticizing the state of GUI frameworks which barely spends a word on whether the resulting UIs are... usable.
I swear to god, the only reason open source software (I use the term "open source" to refer to a variety of idealistic, anti-monopoly movements) isn't more wildly used is because of bad UX. It's just as much work to make a program usable as it is to program its core, under-the-hood features and almost nobody in these communities seems to respect this (notable exceptions include Firefox). It might be tedious to deal with JavaFX' hyper-OOPed structure or JavaScript's lack of type safety, but people actually produce software with them. And hey, Visual Studio Code is based on Electron and the interface is on point, which I'll happily sacrifice a few ms of performance for.
Thank you! I feel the same way. I really dislike most web apps because their interface is so different from the one I chose to purchase because I felt it suited me best. And I can usually tell when the author used a cross-platform UI framework because it has similar issues. They might have actual native buttons, but they're spaced weirdly. Or they look native, but don't react properly. Or whatever. That's far more important to the user in me than the issues with the tools used to create them. (Although the developer in me certainly does appreciate the issues with the tools.)
it what
You're telling me JavaScript isn't a royal pain? Its only justification is spread through web usage, and that might trump all of its weak points, but holy hell is it a bad language! It's a historic mistake we have to deal with.
Honestly, the whole web is. HTML, CSS... it's all technology that was meant to format a few lines of text on a 640x480 monitor, based on type writer analogies. Never for the monstrous web presences we see today. We only endure it because of the benefits of a common standard.
I honestly would be ready for a "web 2". Not "2.0", a whole redo. There's got to be something better. The amount of man-hours wasted on fiddling with the many quirks of HTML positioning or JavaScript errors is mind-boggling, we have entire branches of software development dedicated to avoiding the bad parts of it, fighting it. It's a bizarre circus.
I ain't telling you nothing. I'm just surprised by a sentiment this heavy towards something that doesn't appear to be as odd and maligned as you describe.
What are the alternatives? What are the potential alternatives?
Does the lack of good alternatives make bad thing less bad? It's still bad and there are no good alternatives, which makes bad thing optimal, but not good.
None, really. But I can't believe that a significantly better alternative is beyond reach. This is the defining technology of the world and likely will continue to be for decades if not centuries. Do you think people will fiddle with CSS hacks 50 years from now? I find that thought depressing.
Also I already acknowledged it as being largely the best compromise today, I don't deny that! But, you know... I don't feel like listing all the JS quirks and bizarre CSS spacing issues out there, it's been done to death. Generally, it's just full of edge cases and attempts to alleviate user errors (think JS using but not requiring semicolons, browsers just assuming certain element behaviors and collapsing empty divs, etc). It's all stuff that can be "coped with" but that coping takes so much time, requires so much cruft and even slows things down. It's pretty obvious to me. If it isn't to you, I welcome your positivity but I can't find many reasons to share it.
The thing is:
I work with all of this nonsense. I find the method to the madness more valuable than the quirks I have to deal with because it aids my self-expression. I could learn a real programming language – bullshit a term that it is – but the Web makes for such a beautiful fucking platform for getting your ideas out there that it's just... okay.
But I'm not blind to the flaws. I may choose to accept them and work around them, but I don't dismiss them. All this backwards compatibility shit in JS? All this having to deal with popular libraries and the way they name things 'cause the Web's supposed to be a democratic platform? Hoo boy.
I've been thinking to myself for a while that I'd be completely fine with a complete overhaul of the Web frontend. No backwards compatibility in mind whatsoever: clean slate, only for those developers who's willing to support it. Maybe leave the languages as is 'cause that's what I already know, but yeah, fuck it, I'd learn a handful of new ones if that's what it takes to no longer get bogged down in a swamp where IE9 support is still a meaningful benchmark for code quality.
I asked about alternatives, however, because all this musing is ultimately pointless. The thing that matters when you see a problem is doing something about it; bemoaning it being there is the bystander syndrome I want to take no part in. I asked because maybe someone has come up with something meaningful already: something that could maybe even remotely approach the thing that would replace the HTML+CSS+JS framework.
I think Markdown's gotten close to some sort of a foreground layer of layout composition: it doesn't replace HTML: instead, it abstracts it to a point where the user no longer has to worry about how the underlying layout's going to behave because it's been narrowed down to a list of things that are known to work unless you go out of your way breaking them.
If you could use something like HTML – an Assembly of its kind which browsers understand natively – and be able to use a limited subset of it – like C++, or like JS, or like Brainfuck which browsers also understand natively – for your regular blog-grade posting, that would be splendid. That way, you still retain a powerful codebase that could be abstracted to the level where you don't have to have a degree in CS to make a webpage (like the myriad of frameworks and CMSes allow today). You could, if you wanted to, write SVG by hand in your code – but if you don't, you could just insert a link to a partial containing said SVG and do other meaningful stuff. Enabling amateurs without disabling professionals.
But I'm no fucking expert in this. The best I can do is speculate based on my own experience. Which is a shame, 'cause I'd really like to be involved in something like that and contribute to it in what ways I can.
Also, if I may address a minor concern I have with your comment:
I just left a long-ass comment breaking down critically this sort of approach to commentary. It's probably going to get deleted 'cause it has a lot of profanity and what you might consider excessive countering.
The reason I mention this is because I cannot fucking stand people assuming shit of me, especially in such passing manner. In fact, this was one of my first comments here, and I stand by it still. If you want to converse on a matter, I'm open to it. If you want to know how I feel about something, I'd be glad to answer. If you want to know what my outlook is on a certain aspect of the subject matter, your best bet is asking me.
But don't assume this, yeah?
It's not easy to criticise JavaScript from inside. I don't think it's that weird given the influence from Smalltalk, and in fact I think prototypes are pretty cute.
But we need to step back and ask why we'd use it in the first place: to make web documents dynamic. For that dynamic content, we usually don't want to manipulate an arbitrary tree, we want shallow structured data rendered as presentation components.
From this perspective I think the mismatch between web apps and JavaScript becomes clearer. JavaScript isn't very good at creating DOM nodes in this way ― or really at all. From MDN:
I think it's silly to work with the document on such a low level, because we're using a scripting language, which was designed for document manipulation, specifically to make part of a document. Template instantiation is frankly no simpler.
Imagine if JavaScript itself, the language of 1995, had a tighter type system and element creation as a primitive feature. (Imagine if permitted content were type checked.) Imagine if Node.js, when it was inevitably created, could already represent documents in memory, and using an HTML template on a server were exactly the same as within a web browser.
That's just a bit about JavaScript. Here's some about the DOM as a whole. (I take it with salt but there's some good stuff.)
Allow me to get jest out of the way first:
Ah yes, the good stuff. (The actual content is all the way down here.) It's also a little disconcerting that an article talking about how full of crap HTML is deals it with this horrific structure. (
<body>has a set height!!)I only found out 'cause I wanted to dull the contrast a little. Couldn't figure it out! The
<body>background-colorwas white, and I guess it inverts it somewhere down the tree but I couldn't be bothered.But yeah, it has some good points. I would not want padding to be inheritable, but the fact that it isn't – in an ostensibly cascading stylesheet – is suspect. I disagree with some of those – like the fact that it's better if font values be set on the
textchild (as if we need any more confusion) – but it is a decent overview.Well... Now I can see it. You're right: this kind of element creation is... less than perfect. I can perfectly see why JSX is so popular. Guess I just never thought about it from the perspective of how poorly-thought-out it is.
What would that look like?
Not OP, but for me: React.
We can quibble about syntax (I prefer Hiccup to JSX, and I know I'm in a vanishing minority), but the core concept of "data goes in, UI comes out, data changes, UI changes" is so closely suited to what most people actually want to do that it's transformed the web, mobile, and desktop development landscape in the space of a few short years.
Components are understandable and composable. They map the tree of data to the UI, and they do so in a way that developers can reason about. It isn't perfect, but it's a big step in the right direction; from what I've seen, Flutter is structured in a very similar manner, and given that it has such a different technical basis, I think that says a lot.
What I don't understand is the difference between tree syntax and something like JSX or Hiccup. Is it that you get to define your components as an object, as opposed to running around the already-existing DOM tree?
You can do that with vanilla JS without much difficulty with template literals. And don't you have to navigate DOM with JSX/Hiccup anyway?
Bear in mind: I've never worked with either, so I may be missing key information.
To answer your last question first: no, you don't, and that's particularly important because DOM manipulation (a) is prohibitively slow at scale and (b) assumes your JS runtime has a DOM implementation at all.
The core of what React provides is an extremely fast virtualised DOM and a diffing algorithm that can efficiently figure out the minimal changes between two states of that DOM. Really, that's what React is as a piece of software - although for good reason people are generally more familiar with what it does.
It's probably also worth mentioning that I'm not tied to React as a specific implementation - I'm just using it as the most well known instance of these ideas.
I think we're broadly on the same page there - it makes the mental model much clearer: this component, given this input, will produce this output. You don't need to worry about which bit of the DOM you're finding, or what you're editing, or what order you do things in, or what its existing state was. Data goes in, UI comes out, in a way that's easy and predictable to reason about.
Template literals are strings, so they're great for some use cases, but not all; as I understand, they're basically the language native version of something like Handlebars.
Let's assume you've built your template components, nested them sensibly, and you now have a function at the top that takes in a JSON object
stateand outputs a page of HTML. Server side, this should work fine; you could probably improve the dev experience a bit, but it does the job. If you're just sending static pages, and you don't want to deal with dependencies, this could be a solid way to do it.On the client side, changing any part of
state(say just the colour of a button in response to a click) would regenerate the string from the top, inject it inbody.innerHTML, and cause the browser to re-parse and re-render the whole page from scratch. It's slow enough to be untenable on any complex page, and the alternative of keeping track of certain components' mount points, generating only those strings, and replacing specific DOM nodes manually just brings back the original problem of synchronisation between data and view. Automating that process of tracking and applying minimal changes is what the React diff is built for.The other advantage to having a DOM without relying on an external implementation (i.e. the browser's) is that you don't have to output HTML at all. You can build and output whatever you like, as long as it follows the same structure. React Native, for example, outputs iOS or Android native components using the exact same technique. There have been experiments in rendering straight to canvas, which in turn could likely be extended to use something like Skia to draw straight to the screen. That last example would end up with something very akin to Google's Flutter, which uses a "widget tree" rather than a "virutal DOM" but otherwise provides a broadly similar dev experience.
This is something I've encountered when designing the code base for Intergrid. Its desktop counterpart, by the words of its developer, "redraw[s] everything", which I knew would be a ridiculous proposition on the Web, what with the massive overhead of it all compared to more-barebones system graphics.
Right now it searches for the specific element to change. In the future, I was planning on writing an engine that sounds suspiciously like React in the way you describe it: more akin to a state manager, with DOM being just the source of output.
Which is to say: hoo boy am I aware of that. :)
I've just looked at React as a JS library. The development version shocked me at being 100kb+ – Intergrid's unoptimized engine is almost twice smaller – but the production version is just 12kb, which is... not what I expected.
But then, React DOM library is a whopping 900kb+ uncompressed and 100kb+ compressed.
That said, thank you for mentioning React. It took me on a minor journey, and I found out a few important things for my own dev experience that I could stand to replicate.
Glad to hear it!
Can't vouch for it personally, but Preact might suit your needs if you're looking for a slimmed down and performance focused version of the React API.
Indeed! Sounds interesting. I might give it a shot for a project. Thanks for the link.
No problem!
For building a UI, Dart and Flutter are a promising alternative. I haven't kept up but I think using it anywhere other than mobile is still experimental, though.
I'll be the first one to agree with you about how bad JS is, and there are many stupidities in HTML, but I would not call CSS bad at all. CSS is well respected to the point that I see it's influence in many other UI toolkits. Heck, there is a CSS analogue right in at least two of the toolkits in the article (qt and JavaFX).
It's funny how languages that make it simpler to produce code suddenly become more popular.
Most people who code – particularly in JS – are not programmers in the traditional understanding of the term. They don't seek performance as the ultimate goal aside from the goal itself. They don't strive to memory-manage so that their app takes up as little RAM space as possible. (Which is apparently a thing? I dunno – I'm not one either.) They just want to reify their idea.
Much like amateur photographers who "make it difficult" for professionals with their easily-accessible equipment and no painstaking training.
Much like amateur musicians who "don't get it" because their tools were an app and a YouTube video, not hours of experimentation on a faulty keyboard that didn't play certain sounds right.
"Old men shouting at clouds" is not a new trope. "Professionals cursing amateurs for not being professionals" is just barely younger. It's okay to teach non-pros about things you know as a pro, 'cause they're usually good ideas that are worth picking up. Upset, in the fashion it's being expressed in the article, only begets upset: nobody's learning, nobody's better off.
Also, can I ask you all, have you ever done cross platform (as in Mac/Windows/Linux) development before? When I was doing it, it didn't seem very difficult to keep my business logic separate from my UI logic, and it didn't seem very difficult to me to use the native UI framework on the various systems. (I was only targeting Mac and Windows at the time, though, not Linux.) But I will admit that what I was writing (image and video processing plug-ins) didn't need a ton of UI. I did write some custom views to display custom data types. It seemed pretty straightforward to me at the time. Has that changed? Is there something that makes a need for a cross-platform toolkit essential these days?
If I know one system and need to learn another, I'd rather learn the native one than a different one that's supplied by neither system (and hence may go away in the future before the platforms I'm working on do). It seems like it will take the same amount of work. If I have to learn a 3rd, then maybe it starts to be attractive. I guess that would depend on how complicated the thing I'm working on is. If it's just standard windows with standard controls, I don't know that it would be worth it to me.
I did (well, still do), and I chose JavaFX. Our team is pretty small, so the idea of first writing and then supporting two different apps was quite daunting. And it would have been two different apps, since no-one wanted to touch C++ with a ten foot pole, so to be native we'd have to write in C# for Windows and use something like Rust/Go and GTK on Linux, and you can't really keep your business logic intact and separate UI that way (well, you can, but it would be not that trivial).
Nowadays, I find that it's easier to just use MonoGame even for application UIs. It's a game framework which allows me to do some really fancy stuff like write shaders for custom stuff.
I just wrote my own UI and input libraries for it. I can design my UIs to work with mouse, keyboard, gamepad, touchscreen.
It's pure .net core (development works in windows, mac, linux) and works everywhere: Desktop, mobile, consoles like Xbox, PS4, Switch, etc.
Something nice with MonoGame is that it has a cousin project called FNA https://fna-xna.github.io/. Going from one to the other is rather seamless since they share the same API. There are also some really big players that rely on both those projects.
I've also seen a bunch of people using Godot for that. The engine itself or, rather, the IDE part of it is written in Godot itself, so it has a lot of UI controls that are working out of the box (and are also themeable)
I think that's the future. Game engines / framework are really optimized. And they give so much more freedom. Especially with MonoGame, you can really control your program's architecture.
As an alternative to electron, there's Revery https://github.com/revery-ui/revery
It's used to create Oni2 https://github.com/onivim/oni2
There are plenty more alternatives. There's also this one, which is for whatever reason not listed in the previous link.
Oni2 looks cool. I'd like to give it a shot. I wish they had pre-built alpha releases for schmucks like me who can't build apps on their own.
Haven't heard about revery before, seems like a cool idea (though I don't like JS, but what can ya do). Hope it gets to stable version soon.
Huh, that's exactly what I was ranting about today in another topic here (that I posted)!
Though his style of writing is a bit nauseating, I agree with the general premise: there is no solid solution when it comes to cross-platform GUI, and it's not great that Electron is considered de-facto standard now.