8 ms·
> Revery is the same - aside from platform-specific behavior, if your app looks or behaves differently on another platform, that's a bug! I want my application
by hutattedonmyarm 8y ago
> Revery is the same - aside from platform-specific behavior, if your app looks or behaves differently on another platform, that's a bug!
I want my applications to feel like they belong to the platform and not identical on every platform
- ekianjo 8y ago> I want my applications to feel like they belong to the platform and not identical on every platform Yeah, Electron already does that. I can hardly say I am looking for more of it.
- saagarjha 8y ago> Yeah, Electron already does that. Electron apps don't look like they belong on the platform.
- ekianjo 8y agoThat's exactly what I was saying.
- chrisweekly 8y agoI interpreted GP's "that" as referring to "identical on every platform".
- AnIdiotOnTheNet 8y agoOn Linux, what does? There isn't a defined platform to begin with outside of the syscall ABIs.
- saagarjha 8y agoMost Linux distributions have a de-facto visual design that most applications follow. Generally, if you're using GTK+, this should get applied automatically?
- jarvuschris 8y agoAs a desktop Linux user who rarely got to have good GUI applications until electron became popular because it's barely economical for anyone to actually maintain 3 sep UIs, I am absolutely looking for more of it And to be clear, what we're talking about is more options for folks that want to ship to all platforms and focus on perfecting one UI. Is it better than doing a truly native app on each platform? Of course not, but that's outside the realm of possibility for the resources most developers have
- anonymfus 8y agoAlso I am afraid that not a single thought was given to an accessibility.
- FiveSquared 8y agoTrue, if some users can’t use it, you are shooting yourself in the foot. And if you brand as “accessible” you get free PR from the disabled community.
- obl 8y agoOf course that's a choice for everyone to make, but I feel like in general the benefit of fitting in the platform is overrated. After all the whole webapp-everything somewhat shows that people don't care that much, they are happy to use GMail for example. Another family of examples would be the big software packages like the Adobe or Autodesk stuff, they tend to have a fairly custom look&feel. IMO it's probably sufficient for the thing to look "modern" (ie up to date wrt to UI fashion trends). Then you get the huge upside of easier maintenance and less bugs.
- TeMPOraL 8y ago> Of course that's a choice for everyone to make, but I feel like in general the benefit of fitting in the platform is overrated. I disagree; the benefit isn't overrated, it's underrated because it's not realized, thanks to most apps doing their best to _not_ fit in the platform. What full platform fit enables is consistent UX and interoperability. Lack of the latter places an actual cap of what users can do (except for the small percent that can force an app to interoperate, whether it likes it or not). In my not so humble opinion, the current UX trends are based on circular reasoning - users don't demand functionality, interoperability and ergonomic design because those are rarely given to them, so they don't know they could have it. And since they're not demanding, this is used as a justification to not give it. > After all the whole webapp-everything somewhat shows that people don't care that much, they are happy to use GMail for example. It doesn't show that. It's just that people don't have much choice anyway. Crappy and bloated GMail UI vs. Thunderbird that requires a little bit of knowledge to set up. That's the choice. Most software, including webpages, isn't substitute goods. Fastmail isn't a substitute to GMail once you have an account. LibreOffice isn't a substitute for Google Docs, not once someone shares a document with you through Google's cloud. Network effects are powerful, and they reinforce the basic way normal people treat software - as magic, "gift from gods", something that works the way it works because that's how it works. I'm just pointing this out, because I hate the constant use of "the market decided" and "users voted with their wallets/eyeballs" as justification for bad engineering. It's mostly circular reasoning. > Another family of examples would be the big software packages like the Adobe or Autodesk stuff, they tend to have a fairly custom look&feel. Those are somewhat special cases, because they need so much functionality packed in the UI that they replace platform's conventions with ones better suited to the problem. (Sometimes it leads to weird stuff, like Photoshop and its dialog boxes, in which buttons change meaning when you hold down CTRL.)
- hawski 8y agoAs an alternative for Electron it's not as important, so I cheer the effort. But... For me that means it's not really "native". Native as in CPU native is just to say it's reasonably fast and efficient. It's nice, but I'm looking for platform native. When your application is native in the first sense, you are competing with almost everyone. Games, even applications written with SDL are native in this sense. And almost every cross-perform widget toolkit out there - Qt, GTK+, FLTK, Fox Toolkit, IUP, Juce... I think that then you also need to state if you handle accessibility. If you don't handle it _yet_ you better have a plan to do so. With accessibility you could cross out most of the toolkits I mentioned. That's how you stand out. Now I'm wondering is there a toolkit that started as a crossplatform accessibility library and then gained rendering capabilities? I think accessibility is harder, so when it's bolted on later it's even harder.
- saagarjha 8y agoQt is "semi-native" in the sense that it uses native components, but does so in a hackish, "lowest common denominator" way. It's better than the other alternatives you've mentioned.
- yourapostasy 8y ago> With accessibility you could cross out most of the toolkits I mentioned. That's how you stand out. I'd like to see accessibility baked-in because that would be my preferred path to a fully-addressable/programmable UI, and UI-QA-as-code. The way we QA UI's today is way too hack'ish. I want to be able to write unit tests for the UI within the development flow of writing the UI itself, not in some external, bolted-on fashion. Part of what seems missing is I can call the UI to perform some action on my behalf, but querying the compositor upon the final results sitting on the display output seems to be haphazardly available; I can query for some elements, but not all, or I can query for pixels but not what UI element those pixels belong to.
- jordwalke 8y agoMuch of the work put into Revery will also be applicable to other variations of it that can use platform components for the most important parts. See the Brisk project for an example that adheres to much of the same API and can target MacOS native platform components. But also, take a look at VSCode, and Atom and notice how much of those applications are actually rebuilt skins from the ground up. Even the exit buttons in the Windows version are rebuilt from scratch, not using the platform "components". The number of times I've ever heard anyone complain that VSCode reimplements clickable regions that look exactly the same on all platforms instead of using some ugly stock Windows buttons: zero.
- saagarjha 8y ago> The number of times I've ever heard anyone complain that VSCode reimplements clickable regions that look exactly the same on all platforms instead of using some ugly stock Windows buttons: zero. The number of times I've been annoyed that Electron apps break some semi-obscure but nevertheless important macOS feature: quite high, and it would be much higher if I hadn't sworn off Electron apps long ago.
- jordwalke 8y agoI'm curious what kind of features you're referring to.
- saagarjha 8y agoGood accessibility support, a proper drag and drop implementation, support for services, vibrancy and automatic dark mode support, UI scripting, …
- danpalmer 8y agoYeah to me, as someone who considers themselves a Mac power user (12 years of learning keyboard shortcuts and clever system tricks), Electron apps stand out immediately. There are so many small details, like proxy icons and commonly accepted shortcuts for particular actions. These are things you either get for free or nearly so when writing native apps using the system frameworks, or they are things that people trying to make a consistent app across multiple platforms miss. As a user, the consistency isn’t really a feature for me. I don’t use windows or Linux on the desktop regularly, so having my editor/chat client/etc behave the same on all three isn’t useful.
- rapsey 8y agoThis sentiment is very common among developers/enthousiasts and virtually non-existent among regular users. Some companies waste way too much money chasing some ideal very few care about, trying to please a segment of the users that are generally never happy anyway.
- rimliu 8y agoI think you got it backwards.
- rapsey 8y agoIf users rejected electron apps they would not exist. Platform native is not even a concept 99% of users are familiar with.
- Kliment 8y agoGood luck rejecting something when it's mandated by your job, as is often the case with slack and other electron-crapware. Electron apps exist because it's not the users deciding what the things they use are built in, it's the people who build them. For the vast majority of electron apps there isn't a non-electron alternative that allows you to do the same on said platform, and that's not even starting to look at network effects.
- yyyymmddhhmmss 8y agoMoot point. Parent did not suggest that users decide which libraries or methods to use in development. Nothing of the sort. Electron apps come at a steep price, so if it didn’t offer something to the users, it would be hard to understand the proliferation. In many cases, it offers extremely similar availability on more platforms for less expense than the native alternative dev processes. The argument is if it lost users, that would need to be accounted for. I don’t believe it does.
- yyyymmddhhmmss 8y agoThis is absolutely true. Even if they notice, they won’t have the familiarity with the functional differences to even measure whether either is a good or bad thing.
- giornogiovanna 8y agoAs a user, I prefer consistency across platforms. I don't really want the apps I use to blend into the same gray native soup, anyway. As I see it, the only thing achieved by more consistency within an OS is a thicker garden wall, and I don't really like walled gardens either.
- boudin 8y agoI personally prefer creativity over everything looking the same. I also prefer that people who build things I use spends time on the actual features of the app rather than hoow it looks on this or this operating system. Some level of integration that make sense, sure (like notifications, using native way to select a file, drag'n'drop), but having to look exactly like any other app on the platform i don't see how it's worth the added complexity
- _pmf_ 8y ago> I want my applications to feel like they belong to the platform and not identical on every platform As does everybody sane except every product manager in existence.
- mindcrime 8y agoI want my applications to feel like they belong to the platform and not identical on every platform I'm the exact opposite. I could care less about the underlying platform... I want my apps to behave exactly the same everywhere.
- fnord123 8y agoI want Word and Outlook to honour emacs keybindings that are supported on OS X in every other application (Ctrl-A, Ctrl-E, Ctrl-K, Ctrl-P, Alt-F, etc).
- bryanphe 8y agoThe use case for Revery was to drive development of a text editor - and it turns out a lot of UI is custom in that case. And if you look at the landscape of Electron apps - Spotify, Discord, Code, Slack, etc - most of them are highly customized experiences that are mostly identical across platforms. It seems that style is "in fashion" these days. I agree 100% that it isn't always the proper trade-off, though - there's another ReasonML project called Brisk [1] that is similar in spirit to Revery, but with platform widgets. In fact, we're working together on several infrastructure pieces (the core 'reconciler' - the native React-like piece - is actually developed by the Brisk team). So if you're interested in ReasonML + native app development - that might be one to follow! We see the potential too for some exciting hybrid approaches - perhaps you prototype a cross-platform app in Revery, but then switch to Brisk for platform-specific projects, etc. Or even embed Revery in Brisk. [1] https://github.com/briskml/brisk https://github.com/briskml/brisk
- ForHackernews 8y agoAs a counterpoint, I really do not care about this at all. I routinely use Linux, Mac and Windows systems and I would much prefer software that looked/behaved consistently across them rather than trying to make sure the buttons look the same as the OS-provided apps.
- sonnyblarney 8y agoI don't believe this is a truly valid concern for the most part. The very few 'desktop' apps I use today don't really implement platform UI behaviour, rather, the apps seem fairly consistent across platforms. Adobe products, Android Studio, Ableton, VS Code, Atlassian products - they seem more similar to me than otherwise across platforms. Mobile platforms I think are quite different in this regard, whereupon they have considerably more 'specific' features. But on the desktop - I think as long as the common keyboard binding/shortcuts are respected ... then this is ok.
- kbenson 8y agoFor me that depends entirely on what application it is. For large well-known applications I want them to be consistent across all operating systems. Firefox, Chrome, (MS|Libre) Office, Photoshop, etc are all large enough and ubiquitous enough (depending on computing context) that I want them to behave as closely as possible to each other. For applications that are mostly for that OS, I would prefer they adhere to the tenets of design for that OS. This is less a matter of wanting it to feel a certain way and more a matter wanting familiarity and utility out of the applications I'm most likely to experience on different operating systems when I'm on them. Function is much more important than form for me in this case.
- raddledsplash 8y agoIsn't identical on every platform is good for a consistent user experience?
- ludwigschubert 8y agoThe usual argument goes: consistent user experience means adhering to your users’ expectations, which are shaped by their platforms.
- taude 8y agoThis is something we used to say, but I really feel that since the popularization of the web apps, I'd rather have cross-platform UX working the same or near enough. I know, for instance, that I'm likely the only person on Hacker News that actually likes the Slack Desktop application, and I'm glad it works very similarly on both my Mac and PC.
- Shorel 8y ago> I want my applications to feel like they belong to the platform and not identical on every platform Then use the wxWidgets library. It has bindings for many languages, so it probably has bindings for yours. But more recent applications like SublimeText try a unified look in all platforms, and as long as it is fast enough and crash free, I am OK with that.
- hutattedonmyarm 8y agoI’m okay with sublime, but it does make two major mistakes on macOS: * The wrong keyboard shortcut for redo (Cmd-Y instead of Option-Cmd-Z) * Mixing native tabs and it’s own implementation
- bradknowles 8y agoAgreed. It’s not really “cross-platform” if they take their own platform with them and implement it everywhere, and then all apps built with that toolkit are identical everywhere as a result.