7 ms·

Does anyone else feel that there's a huge hole in the UI world? I like the electron/react/react native ecosystem - I really do, and this is coming from someone

Does anyone else feel that there's a huge hole in the UI world? I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place. I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack. Maybe Python? It's got lots of competent developers in the market to support it. Maybe Rust or Go, if something lower-level was desired. Or language-agnostic, though sticking with one might be valuable.

eropple 9y ago
It sounds like you're just describing React Native (which, for example, has a UWP target, although it's still janky). React Native doesn't have a "web stack".
_pdp_ 9y ago
You will most likely come up with a sub-par rendering engine that is better implemented by Mozilla and Google. My hope is in Servo.
pjmlp 9y ago
No, XAML, QML, JavaFX, Android, Cocoa are much better, with guaranteed hardware acceleration, and offer RAD GUI designers that are much more powerful than hand-editing HTML/CSS. As funny anecdote, CSS Grid was originally proposed by XAML team. Google apparently is pushing for the low level rendering control that native UI APIs enjoy on their Houdini project. Right now, it is yet again a Chrome only feature.
- greenhouse_gas 9y ago
  The big problem is that out of the 5 technologies you mentioned,only two are cross-platform, and only one builds an exe (yet). Oh, and that one is practically designed around a hybrid C++, so if you don't like C++ (last time I tried C++ with mingw on Windows I had a horrible time installing libraries), you're out of choices.
  - realharo 9y ago
    >last time I tried C++ with mingw on Windows I had a horrible time installing libraries msys2 (http://www.msys2.org/ http://www.msys2.org/) solves package management quite nicely, at least for the more popular libraries and tools.
  - pjmlp 9y ago
    XAML, QML, JavaFX, Android (since version 5), Cocoa all build exes, so I don't know which single one you mean. QML and JavaFX are cross-platform, XAML is cross platform via Avalonia or Xamarin.Forms. Anyone using C++ on Windows for GUI development should use Visual C++, C++ Builder or the gcc toolchain integrated in the Qt installer.
    - oblio 9y ago
      JavaFX doesn't run on iOS. While your Electron app will be tweaked to make a Cordova app that runs on iOS. Avalonia is at beta level at best, would you bet your startup on it? Xamarin.Forms ok, but XAML is not 100% the same everywhere, anyway. WPF is not Xamarin.Forms.
      - pjmlp 9y ago
        JavaFX surely runs on iOS, just not for the "I want everything for free" crowd. http://gluonhq.com/products/mobile/ http://gluonhq.com/products/mobile/ > XAML is not 100% the same everywhere, anyway. Hence XAML Standard, https://github.com/Microsoft/xaml-standard https://github.com/Microsoft/xaml-standard
      - s73v3r_ 9y ago
        "While your Electron app will be tweaked to make a Cordova app that runs on iOS." And be incredibly shitty. If you care about your users and their experience, you won't write apps in JS to begin with.
        pjmlp 9y ago
        My point of view is that if it is to be done with the Web stack, then by all means it should be delivered to whatever browser the user likes to use on their platform. Anything else should take advantage of the native UI/UX tooling.
- lucideer 9y ago
  If they were "much better", devs wouldn't be flocking to Electron. If there's something amiss, claiming there isn't with hand-waves brushes whatever issues there are under the carpet.
  - pjmlp 9y ago
    I bet the majority of those devs are web devs without any experience in native frameworks.
  - yorwba 9y ago
    You also have to consider where the users are coming from. If you only have experience in web dev, obviously you are going to choose the framework that lets you do what you always did and get a desktop app in the end. If you have been building GUIs in Visual Studio or VBA, you're probably not going to suddenly switch to Electron. And if you have mostly been writing Python scripts for the terminal, you might use something like Gooey [1] to build a basic GUI with almost no additional effort. [1] https://github.com/chriskiehl/Gooey https://github.com/chriskiehl/Gooey
  - s73v3r_ 9y ago
    Devs aren't flocking to Electron. JS developers are.
- realharo 9y ago
  Having done a lot of React development (in TypeScript), and recently dealing more with Android, I disagree. Having to manually mutate the UI instead of describing it with a `render` function feels like a huge step back. Even data binding is often too limited. Trying to get a screen in Android to have the correct layout and style is also way clunkier - even with ConstraintLayout.
- netzone 9y ago
  Really, I agree that there are probably better markup options, but still, there's a reason people choose Electron over the alternatives. For me, personally, that reason is the ease of prototyping - the time it takes for me to have something in front of me that looks good and works easily is so much less using something like Electron.
  - pjmlp 9y ago
    They don't know better. Web stack doesn't have any mature option, besides maybe avril, that matches what something like Blend or QML designer offers.
  - klez 9y ago
    Ok, but from an engineering standpoint I see this as a bit shortsighted. I mean, shouldn't you care more about shipping a good product (i.e. developing something that doesn't thrash your users' resources) than ease of development? I get that if it's too hard to develop there's no product to speak of, but still, aren't we going too far off the equilibrium point?
- sime2009 9y ago
  Web technologies have some unique non-technical qualities which trump the technical arguments: * Standards based with no single entity or company "owning" it. * Multiple mature competing implementations. * Massive support across the industry and a huge ecosystem.
  - pjmlp 9y ago
    You mean like those "Works in IE/Chrome" standards? I am yet to see the huge ecosystem for Web components that matches component libraries like those from DevExpress or ComponentOne.
    - Sawamara 9y ago
      You have to actively ignore the web's landscape in the past 5-6 years to state something like this. Lately, major vendors (with Edge, that includes Microsoft) are agreeing on standards, developing them FAST, and the web moves forward faster than it has ever moved. Long gone are the days where your standards can get stopped for multiple years. And vendor prefixes are less prevalent now as features get implemented properly sooner.
      - pjmlp 9y ago
        Really? https://ishoudinireadyyet.com/ https://ishoudinireadyyet.com/ https://www.webcomponents.org/ https://www.webcomponents.org/ https://hangouts.google.com/ https://hangouts.google.com/ Also, to use those standards, one needs to have access to latest browser versions, which never happens beyond controlled environments. So typical web development always needs Modernizr, Babel, Polyfills (when possible) around.
        sime2009 9y ago
        The vast majority of current web development project don't need to go anywhere near the bleeding edge "still in development" browser APIs. Your argument makes no sense in the year 2018.
- lobster_johnson 9y ago
  Do you know of a Qt app that looks and feels fully native on macOS and Windows and maybe iOS and Android? I'm genuinely curious. Years ago, I used several Qt apps, and they never felt native. They felt like Java Swing or Delphi apps. Clunky and not pretty. Slack, to me, doesn't _look_ quite native, but it still doesn't feel like an outsider on the platform. I imagine that using native Apple kits are easy from C++ thanks to ObjC interop, no idea about Android.
realharo 9y ago
I feel the same way. I even tried starting a library like that (in Kotlin JVM and Native), but never got past a very early stage (https://github.com/peterholak/mogul https://github.com/peterholak/mogul). Hopefully one day I'll have enough time to work on it.
ZenoArrow 9y ago
> "I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack." There are a number of existing UI frameworks that fit this description. As a starting point, I'd suggest checking out QML: https://en.wikipedia.org/wiki/QML https://en.wikipedia.org/wiki/QML
kodablah 9y ago
Yes, I think we all feel it. Every UI lib has something wrong: C++ sucks and is hard to iface w/ other langs (Qt, wxWidgets), not enough widgets (IUP, libui), not native enough in my OS (GTK), carries a full browser (Electron, nw.js), carries a full JVM (JavaFX, Swing), etc, etc. And then every subreddit and community always has people asking what's the best UI lib for language X. We all travel back to awesome-lang-X lists' GUI section every so often hoping someone will finally fix it. Qt or wxWidgets, make a supported C iface (I am aware of some work on both fronts, e.g. wxc that was used by wxHaskell I think?). IUP and libui, thicken your libs (libui guy just got permission from his new company to get back working on the lib, yay). World, don't hate non-native-OS-widgeted apps. Browser vendors, stop being so tunnel-visioned into your my-OS-only, non-embeddable, or must-be-multiprocess shit. And let us trim some fat off at compile time please (waiting on you Servo, but please stay lean and single-process for embeddability). JVM AOT...we're waiting, we know it's coming. And no, I would rather not have an interpreted (or dynamic) language if I can help it. Edit: To clarify before a ton of responses pick apart my specific criticisms, I'm making these points to show there is a void. I could poke a ton more holes in these libs and more (I have used most), but it's hardly worth arguing the nuances here.
- zerr 9y ago
  Both Qt and wxWidgets have bindings for a bunch of languages. Also, in case AOT compiler comes to Java, JavaFX and Swing might become viable options as well.
  - oblio 9y ago
    In many times bindings are: * incomplete * immature * not up to date and definitely out-of-tree, aka not maintained by the folks that make the original toolkit. Would you bet your company on those bindings?
    - akerro 9y ago
      Agreed, Qt binding are only officially supported for C++ and Python is a major player here as well, Golang has quite good bindings but a few minor methods per class as still missing, it's good enough to write a major desktop app tho.
danieldk 9y ago
But is HTML/CSS/JS really the best we can do for desktop and mobile applications? [...] I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack. QML? Or if you want native applications, what is wrong with Cocoa, Qt, and XAML? A cross-platform toolkit will either be the lowest-common denominator between the platforms (this has been tried before, see e.g. AWT, SWT, wxWidgets) or something that is alien to each platform (Electron). Small independent development companies have done applications across multiple platforms by using their native toolkits for decades. And now suddenly, it is too expensive for GitHub, Slack, and others to develop applications with platform UI toolkits? They are just transferring the cost to the users. We get inconsistent shortcuts, widgets, etc. between programs. No automator support, etc. There is only a benefit to people who use multiple platforms and want to applications to look the same on every platform. But the vast majority of users just uses one platform, or two if we include tablets/phones (which have different input methods anyway).
- greenhouse_gas 9y ago
  >Small independent development companies have done applications across multiple platforms by using their native toolkits for decades Really? How many programs supported Linux before electron?
  - danieldk 9y ago
    Usually these companies supported macOS and Windows. I am sure they would have also supported Linux if it had a desktop penetration of more than 1% and if the Linux community was less hostile to closed-source applications. Don’t take this the wrong way (I was a full time Linux/BSD desktop user from 1994 to 2007 and still have one Linux desktop machine at home), but do we really want to significantly degrade the experience of 99% of the users for 1% of the market?
mhd 9y ago
I'm not the biggest fan of this sed reinvention of PostScript we call the browser stack, but my main problem with Electron and the like isn't this, but their design target: Making desktop apps look and feel like web apps. We're throwing away all kinds of HIG achievements since 1984, for the sake of pretty colors and superfluous transitions. Not too long ago, a considerable effort was spent to make web apps behave like desktop apps, now the inverse is true. I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure.
- anticnstrctv 9y ago
  Making desktop apps look and feel like web apps. This is a good point. However, it does seem like web and mobile apps and their ilk are the future for the bulk of software the majority of people use (excluding, let's say, "Pro" apps like photoshop, excel, dev tools). I'm not a huge fan of this, but the times have changed. I'm not sure that traditional desktop apps are really what I'd use the hypothetical framework I described to build. Something like my business expense tracking app, though? If I wanted it to sync and be functionally identical to the app on my phone? I could see this framework being used for that.
- y4mi 9y ago
  > I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure. you can't just drop a sentence like that and not elaborate on it - unless you want to offend somebody. Each resource hungry "DevOps" tool has its place and has its worth. They're just often misused. A small IT firm with <10 Hypervisors won't need openstack for example. Thats only worth its maintenance if you're working with tens or hundreds or hardware machines. And a webapp which consists of <10 services probably doesn't need service discovery and advanced de-/commissioning of containers/vms. Administering hundreds of microservices without that is borderline impossible however.
  - mhd 9y ago
    DevOps as a practice isn't wrong, of course. Sysadmins scripted and programmed since the dawn of the silicon Pleistocene. But if every small company hires someone with that specific job description, well, you have to spend your 80+ startup hours somewhere.
kenhwang 9y ago
Or maybe the other way around: what if a browser was modular down to the feature level? Don't use CSS/JS/HTML feature X/Y/Z? It's removed from the engine at compile time. That way you're only shipping what you're using, not a mini-OS. Or maybe the JVM approach, where there's one electron process on the system, and all the electron apps on the system are run in the same process. That way at least the rendering/JS engine can be shared. It'd be like Firefox before electrolysis. Though, having your chat client crash and also take down your music player and code editor seems like a terrible user experience.
- accatyyc 9y ago
  One big problem with Electron apps today IMO is that different apps cannot share memory, even though 90% of them is the same (Chrome/V8 etc). That would be solved if you had one Electron binary that started each app, much like a JVM. They would still be different processes so one app couldn't bring down another, but at least they would share memory pages and copy on write which would make the multi-electron-app world better. (IMO) It would also have the benefit that you could update once and not run an old chat app with old Chrome security issues, until each developer decides to update Electron. But I guess the argument against that is that it's no longer "truly cross platform" since an Electron app may have to support multiple Electron versions. This is how things always have been though, developers just seem a lot more lazy about it nowadays.
  - realharo 9y ago
    I'm not sure you would save that much memory. It would be a similar situation to having Chrome open with a bunch of tabs (those are separate processes as well) - it's the tabs themselves that consume most of the memory, compared to "bare" Chrome.
    - accatyyc 9y ago
      On my computer, "bare" Chrome with 0 tabs open still uses ~100MB of memory. If Electron would just use 100MB for the base compared to 100 * number of open Electron apps, that's still a pretty big win in my book.
dvfjsdhgfv 9y ago
I very much hope Red finally takes off. Currently the GUI frontend works only on Windows and macOS, not on Linux yet. But once it does, we'll finally have a truly multiplatform tool for creating simple apps (such as the ones Electron is used for). As for more complex apps, this might well be possible as well, but I haven't seen anything really complex created in Red yet.
daxfohl 9y ago
I wouldn't get my hopes up. Javascript is the only runtime allowed on ios. Desktop is no longer worth innovating for. Meanwhile web ui frameworks are going gangbusters with innovation. That leaves a fairly slim line for any real ui innovation outside of the HTML css js triumvirate.
benjaminl 9y ago
It is amazing that React and friends work as well as they do, and for certain applications they make a lot of sense. But there is a fundamental disconnect using web technologies for native apps. The solution I am pursuing right now is Microsoft's Xamarin. The C#\XAML stack supports iOS, Android, MacOS and Android. The only thing it is missing is web. But with a couple serious projects working on compiling C# to WebAssembly perhaps that will happen.
- tonyedgecombe 9y ago
  I thought it was just a poor winforms clone on macOS.
  - oblio 9y ago
    Correct me if I'm wrong, but I think Xamarin just wraps Cocoa.
  - benjaminl 9y ago
    Like the rest of Xamarin's platforms, you can use modern XAML with MVVM patterns or you can use XCode's Interface Builder to create your views. Xamarin.Forms has no relationship to WinForms.
- pjmlp 9y ago
  Microsoft is serious on the WebAssembly part. https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-experimental-project/ https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-ex...
mateuszf 9y ago
It's not that simple. You can go three routes: 1. Make the apps look pixel perfectly the same on all platforms - that's what the Java Swing did. Result - all the apps feel "alien" and not native for the users. 2. Make all the apps look and behave native and use UX patterns consistent to the given platform. Result - you will have to program them differently. 3. Somewhere in between - all you get is mediocre GUI with not very pleasant development model. So the problem is not with the GUI toolkits but with inconsistent UX paradigms between the platforms / different input models, interaction models, etc.
- Numberwang 9y ago
  I have no problem with things feeling alien, so that would be my preference. For example I love the Telegram desktop app.
  - adolfojp 9y ago
    Telegram looks native on Windows 10 though. It was designed to look like a flat modern app and it excels at that, hamburger menu and all.
    - Numberwang 9y ago
      Hmm, the header bar doesnt look native to me (it looks amazing)
- pas 9y ago
  Alien would be okay, were it not ugly. Swing is unusable and ugly. Just look at and try to use a Swing file picker. ... Anyway, I'd gladly program them differently for closer to native experience, if it were easy to program. Currently it's either Qt (C++) or GTK (C), or completely useless/out-of-date bindings. And thus any glorified WebView reigns supreme.
  - mateuszf 9y ago
    Yeah, I agree - C/C++ are the reasons why Qt is not popular.
ergothus 9y ago
Are the options the best they could be? Heck no, not even close. Html is semantic enough to be tedious but not enough yo be useful. Css makes the easy things hard and people have entire philosophies around minimizing the "cascading" part. Js is at best stuck with warts to try and maintain backwards compatibility. Meanwhile the tooling to deal with missing pieces or complications that are not missing is complex enough that both new and experienced devs complain. The less said about the security complexity the better. And I'm saying all of that as someone that uses these daily and enjoys it. BUT...is it the best that is practical for the time? Probably. There have been efforts to replace these options...theyve failed. Perhaps wasm will change things, but perhaps not. Until then though, I think it is interesting to ask "Why?" Why, if these other options are superior, do they not catch on? Linux, git, nginx, these are just a few examples of dramatic tech switches that had to overcome an existing base. It isnt just backwards compatibility either - Babel exists for es6+, but I've not seen a non js-like language that can compile to js achieve much success. I suspect there are one or two areas that the current offerings handle well that aren't being credited or understood. Computer UI is a young field, computer interactions with business and marketing over time are all poorly understood. We spend much of our time reinventing our spinning wheels and relearning lessons. Html in js is bad. No, it is good. Inline css is bad. No, it is good. This isn't all wasted time, there is a lot of learning time. So I doubt we even understand yet what would make a better toolset.
ec109685 9y ago
> I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place. React Native doesn't use HTML/CSS at all for rendering.
hooluupog 9y ago
Flutter has the potential once it ported to desktop and even web(with WASM).
- gman83 9y ago
  I think it'll only be ported to desktop once Fuchsia comes closer to release (which could be several years). They really seem focused on mobile only at the moment. Agree it could be a great solution.
- markdog12 9y ago
  Looks like it has started (MacOS for now) https://github.com/google/flutter-desktop-embedding https://github.com/google/flutter-desktop-embedding
zwetan 9y ago
You just described Adobe AIR eg. "something that has consistent, cross platform (desktop and mobile [...]), responsive ui, without the huge web stack"
raquo 9y ago
I really don't mind the HTML / CSS part with new developments such as CSS grid. If you're running it in a controlled environment (embedded browser), you could cut out a bunch of legacy crap, leaving a much leaner engine. Similar cleanup could be done on the DOM API, I guess.
- cm2187 9y ago
  There is something to be said about html being too basic for developping apps efficiently. There is no menu control, contextual menu control, if you want to handle dragging and dropping UI items or creating an overlay modal window you need to do all sorts of hacks. On a desktop UI framework these are often a single line of code and it’s hard to get it wrong. I don’t think html/css is really comparable to the major native UI frameworks in term of productivity and correctness of apps produced. I see so many websites trying to implement their own UI behaviors and getting it wrong, not scrolling smoothly, showing a modal window partially off screen in certain scenarios, preventing you from zooming out on a smartphone while overflowing the text outside of the screen, menus that are either not touch or mouse friendly, etc. Giving UI developpers only html and css is like telling a graphic designer: all you need is microsoft paint, you see you can change the color of each pixel to whatever you want, total freedom! Yeah... No.
  - raquo 9y ago
    Being relatively low level is a feature. HTML / CSS / JS are languages, not frameworks. One liner modals are not a feature a language should have. If you want, you can make a framework on top of it that will behave like a desktop UI framework with standardized elements and behaviours. There are plenty of such frameworks actually. But not having to use such a framework is nice. Besides, the current browser environment has been historically heavily optimized for websites, not desktop apps. If it became a popular choice for desktop app UI we'd have developed more appropriate features for that use case.
    - cm2187 9y ago
      Why do you call html and css a language? To me it’s a UI framework very much like winform, wpf & al.
gunn 9y ago
Yes. I'd like to see a stripped down embeddable browser engine - https://news.ycombinator.com/item?id=9914925 https://news.ycombinator.com/item?id=9914925 Also there are existing projects like https://github.com/ptmt/react-native-macos https://github.com/ptmt/react-native-macos
- jbergens 9y ago
  Like Sciter? https://sciter.com/ https://sciter.com/ I think WPF/XAML could have worked also but there were not much work to port it to anything but Windows.
  - gunn 9y ago
    That's almost exactly what I was thinking of. There does look to be a big caveat with it though - instead of JS, it has an ECMAScript variant called TIScript. I'm sure this was a good choice when it was made, but javascript libraries and tooling are a lot to miss out on now.
- deleted 9y ago
  [deleted]
Sawamara 9y ago
I am sorry, but I honestly do not think that PYTHON of all the things would be the solution to a "UI-problem". To have a good UI system, you need extensibility, you need testing, you need strong types (this one is debatable, but I truly believe this to be true after working with Typescript-based HTML UI-s for the past 6+ months now), and you need performance. I can understand that a lot of programmers got into the mindset of "no, I wont deal with HTML", and I frequently see devs mentioning that they prefer that apps look "native", which is something that has not been a standard in the mainstream dev world for quite a few years now, but the reality is that that "native" dream is gone. People all around the world interact with mobile apps MORE than their dessktop/mobile system'S native ui, so there is no baseline to go back to, there is no good old days to retrieve. We can only move forward with what we have learned, imho. And that might be or might not be HTML, but if something comes along, it better learn all the lessons that we collectively are learning with working through HTML-CSS-JS SPA's.
zserge 9y ago
I agree with you, and I tried my best to change things. A few years ago I made Anvil - a React-ish framework for Android for native UI (reactive, declarative, works best with Redux) and have been using it in many production apps as long as I was doing Android development. But it still is a niche product, most developers prefer visual UI editor and whatever is the official Google way to do Android apps. Still, I'm very proud of Anvil. https://github.com/zserge/anvil https://github.com/zserge/anvil Then, once I had to deal with desktop apps I figured out that HTML/CSS/JS seems to be the best option for custom (no native widgets) and modern (animations, shadows, nice fonts etc) UI. But Electron was a heavy beast, so I made a tiny wrapper over native browser engines (webviews). So far I'm very happy with it, it's much lighter and smaller than electron. And it's very convenient to use from C++ or Go. Some kind people added Rust and Nim support, I'm now working on Python and Node.js bindings. So yeah, it's pretty much language-agnostic, although it's still web UI. I really hope it can take it's niche for small desktop apps that don't need the full power of Electron, yet need to have a good look. https://github.com/zserge/webview https://github.com/zserge/webview
- moosingin3space 9y ago
  Been enjoying your library webview for some small home projects. Thanks!
swiley 9y ago
TCL/TK runs on literally everything except the iPhone.
rebolek 9y ago
Sounds like what Red language http://www.red-lang.org/ http://www.red-lang.org/ is trying to achieve. It is still in Alpha, but already has cross platform GUI for Windows and OS X (with Androind arriving in next release). And without the web stack bloat, it's just single ~1 MB executable.
pier25 9y ago
I've been working in UI for almost 20 years. I've done flash, native desktop, games, web, mobile, etc, and I think HTML+CSS+JS is still the best abstraction for UI IMO. It's certainly not without it's problems though. JS sucks and native performance is way better, but no one can deny it's so much more flexible and powerful than any other thing out there. Here is a great article on this topic: https://medium.com/missive-app/our-dirty-little-secret-cross-platform-email-client-with-nothing-but-html-aa12fc33bb02 https://medium.com/missive-app/our-dirty-little-secret-cross...
mamcx 9y ago
I'm starting a project with a strong need of build the UI in multiple targets (iOS, Android mainly). I try first with html and the native webview. With iOS is totally fine, but Android is SUPER slow. I never imagine that android was this bad, but at least, it force me to do native :) ---- I think that is possible to do what you describe, and I'm working something like. The key is decouple some task (kinda separate "back-end" UI from "front-end" UI): We can do "partial" cross-platform UI, if we think that some stuff can actually cross cleanly: - Layout (the big one, IMHO) with something like https://yogalayout.com https://yogalayout.com - The ELM architecture (https://www.elm-tutorial.org/en/02-elm-arch/01-introduction.html https://www.elm-tutorial.org/en/02-elm-arch/01-introduction....) because a big chunk of the logic is totally cross-platform and "only" need to adapt the render of controls. - Dispatching, events and similar stuff, that is not visual. Then finally, the rest can be fully native: - Controls - Drawing - Animations - Call to native libs ---- The big question is what to use for coding this. I'm using .net but wish to have something more low-level. I know swift and it could work for other targets (Java, .NET, native) with http://elementscompiler.com http://elementscompiler.com Wish to have a coding partner to do this :)
glibgil 9y ago
https://www.youtube.com/watch?v=yOiuJ_Gll_E&feature=youtu.be&t=38s https://www.youtube.com/watch?v=yOiuJ_Gll_E&feature=youtu.be...
rms25 9y ago
Look up QML (Qt Quick) on Qt, its the easiest UI building experience I've ever had Funny that QML looks alot like the JavaFX script that was abandoned

eropple 9y ago

It sounds like you're just describing React Native (which, for example, has a UWP target, although it's still janky). React Native doesn't have a "web stack".

_pdp_ 9y ago

You will most likely come up with a sub-par rendering engine that is better implemented by Mozilla and Google. My hope is in Servo.

pjmlp 9y ago

No, XAML, QML, JavaFX, Android, Cocoa are much better, with guaranteed hardware acceleration, and offer RAD GUI designers that are much more powerful than hand-editing HTML/CSS. As funny anecdote, CSS Grid was originally proposed by XAML team. Google apparently is pushing for the low level rendering control that native UI APIs enjoy on their Houdini project. Right now, it is yet again a Chrome only feature.

greenhouse_gas 9y ago
The big problem is that out of the 5 technologies you mentioned,only two are cross-platform, and only one builds an exe (yet). Oh, and that one is practically designed around a hybrid C++, so if you don't like C++ (last time I tried C++ with mingw on Windows I had a horrible time installing libraries), you're out of choices.
- realharo 9y ago
  >last time I tried C++ with mingw on Windows I had a horrible time installing libraries msys2 (http://www.msys2.org/ http://www.msys2.org/) solves package management quite nicely, at least for the more popular libraries and tools.
- pjmlp 9y ago
  XAML, QML, JavaFX, Android (since version 5), Cocoa all build exes, so I don't know which single one you mean. QML and JavaFX are cross-platform, XAML is cross platform via Avalonia or Xamarin.Forms. Anyone using C++ on Windows for GUI development should use Visual C++, C++ Builder or the gcc toolchain integrated in the Qt installer.
  - oblio 9y ago
    JavaFX doesn't run on iOS. While your Electron app will be tweaked to make a Cordova app that runs on iOS. Avalonia is at beta level at best, would you bet your startup on it? Xamarin.Forms ok, but XAML is not 100% the same everywhere, anyway. WPF is not Xamarin.Forms.
    - pjmlp 9y ago
      JavaFX surely runs on iOS, just not for the "I want everything for free" crowd. http://gluonhq.com/products/mobile/ http://gluonhq.com/products/mobile/ > XAML is not 100% the same everywhere, anyway. Hence XAML Standard, https://github.com/Microsoft/xaml-standard https://github.com/Microsoft/xaml-standard
    - s73v3r_ 9y ago
      "While your Electron app will be tweaked to make a Cordova app that runs on iOS." And be incredibly shitty. If you care about your users and their experience, you won't write apps in JS to begin with.
      - pjmlp 9y ago
        My point of view is that if it is to be done with the Web stack, then by all means it should be delivered to whatever browser the user likes to use on their platform. Anything else should take advantage of the native UI/UX tooling.
lucideer 9y ago
If they were "much better", devs wouldn't be flocking to Electron. If there's something amiss, claiming there isn't with hand-waves brushes whatever issues there are under the carpet.
- pjmlp 9y ago
  I bet the majority of those devs are web devs without any experience in native frameworks.
- yorwba 9y ago
  You also have to consider where the users are coming from. If you only have experience in web dev, obviously you are going to choose the framework that lets you do what you always did and get a desktop app in the end. If you have been building GUIs in Visual Studio or VBA, you're probably not going to suddenly switch to Electron. And if you have mostly been writing Python scripts for the terminal, you might use something like Gooey [1] to build a basic GUI with almost no additional effort. [1] https://github.com/chriskiehl/Gooey https://github.com/chriskiehl/Gooey
- s73v3r_ 9y ago
  Devs aren't flocking to Electron. JS developers are.
realharo 9y ago
Having done a lot of React development (in TypeScript), and recently dealing more with Android, I disagree. Having to manually mutate the UI instead of describing it with a `render` function feels like a huge step back. Even data binding is often too limited. Trying to get a screen in Android to have the correct layout and style is also way clunkier - even with ConstraintLayout.
netzone 9y ago
Really, I agree that there are probably better markup options, but still, there's a reason people choose Electron over the alternatives. For me, personally, that reason is the ease of prototyping - the time it takes for me to have something in front of me that looks good and works easily is so much less using something like Electron.
- pjmlp 9y ago
  They don't know better. Web stack doesn't have any mature option, besides maybe avril, that matches what something like Blend or QML designer offers.
- klez 9y ago
  Ok, but from an engineering standpoint I see this as a bit shortsighted. I mean, shouldn't you care more about shipping a good product (i.e. developing something that doesn't thrash your users' resources) than ease of development? I get that if it's too hard to develop there's no product to speak of, but still, aren't we going too far off the equilibrium point?
sime2009 9y ago
Web technologies have some unique non-technical qualities which trump the technical arguments: * Standards based with no single entity or company "owning" it. * Multiple mature competing implementations. * Massive support across the industry and a huge ecosystem.
- pjmlp 9y ago
  You mean like those "Works in IE/Chrome" standards? I am yet to see the huge ecosystem for Web components that matches component libraries like those from DevExpress or ComponentOne.
  - Sawamara 9y ago
    You have to actively ignore the web's landscape in the past 5-6 years to state something like this. Lately, major vendors (with Edge, that includes Microsoft) are agreeing on standards, developing them FAST, and the web moves forward faster than it has ever moved. Long gone are the days where your standards can get stopped for multiple years. And vendor prefixes are less prevalent now as features get implemented properly sooner.
    - pjmlp 9y ago
      Really? https://ishoudinireadyyet.com/ https://ishoudinireadyyet.com/ https://www.webcomponents.org/ https://www.webcomponents.org/ https://hangouts.google.com/ https://hangouts.google.com/ Also, to use those standards, one needs to have access to latest browser versions, which never happens beyond controlled environments. So typical web development always needs Modernizr, Babel, Polyfills (when possible) around.
      - sime2009 9y ago
        The vast majority of current web development project don't need to go anywhere near the bleeding edge "still in development" browser APIs. Your argument makes no sense in the year 2018.
lobster_johnson 9y ago
Do you know of a Qt app that looks and feels fully native on macOS and Windows and maybe iOS and Android? I'm genuinely curious. Years ago, I used several Qt apps, and they never felt native. They felt like Java Swing or Delphi apps. Clunky and not pretty. Slack, to me, doesn't _look_ quite native, but it still doesn't feel like an outsider on the platform. I imagine that using native Apple kits are easy from C++ thanks to ObjC interop, no idea about Android.

realharo 9y ago

I feel the same way. I even tried starting a library like that (in Kotlin JVM and Native), but never got past a very early stage (https://github.com/peterholak/mogul https://github.com/peterholak/mogul). Hopefully one day I'll have enough time to work on it.

ZenoArrow 9y ago

> "I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack." There are a number of existing UI frameworks that fit this description. As a starting point, I'd suggest checking out QML: https://en.wikipedia.org/wiki/QML https://en.wikipedia.org/wiki/QML

kodablah 9y ago

Yes, I think we all feel it. Every UI lib has something wrong: C++ sucks and is hard to iface w/ other langs (Qt, wxWidgets), not enough widgets (IUP, libui), not native enough in my OS (GTK), carries a full browser (Electron, nw.js), carries a full JVM (JavaFX, Swing), etc, etc. And then every subreddit and community always has people asking what's the best UI lib for language X. We all travel back to awesome-lang-X lists' GUI section every so often hoping someone will finally fix it. Qt or wxWidgets, make a supported C iface (I am aware of some work on both fronts, e.g. wxc that was used by wxHaskell I think?). IUP and libui, thicken your libs (libui guy just got permission from his new company to get back working on the lib, yay). World, don't hate non-native-OS-widgeted apps. Browser vendors, stop being so tunnel-visioned into your my-OS-only, non-embeddable, or must-be-multiprocess shit. And let us trim some fat off at compile time please (waiting on you Servo, but please stay lean and single-process for embeddability). JVM AOT...we're waiting, we know it's coming. And no, I would rather not have an interpreted (or dynamic) language if I can help it. Edit: To clarify before a ton of responses pick apart my specific criticisms, I'm making these points to show there is a void. I could poke a ton more holes in these libs and more (I have used most), but it's hardly worth arguing the nuances here.

zerr 9y ago
Both Qt and wxWidgets have bindings for a bunch of languages. Also, in case AOT compiler comes to Java, JavaFX and Swing might become viable options as well.
- oblio 9y ago
  In many times bindings are: * incomplete * immature * not up to date and definitely out-of-tree, aka not maintained by the folks that make the original toolkit. Would you bet your company on those bindings?
  - akerro 9y ago
    Agreed, Qt binding are only officially supported for C++ and Python is a major player here as well, Golang has quite good bindings but a few minor methods per class as still missing, it's good enough to write a major desktop app tho.

danieldk 9y ago

But is HTML/CSS/JS really the best we can do for desktop and mobile applications? [...] I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack. QML? Or if you want native applications, what is wrong with Cocoa, Qt, and XAML? A cross-platform toolkit will either be the lowest-common denominator between the platforms (this has been tried before, see e.g. AWT, SWT, wxWidgets) or something that is alien to each platform (Electron). Small independent development companies have done applications across multiple platforms by using their native toolkits for decades. And now suddenly, it is too expensive for GitHub, Slack, and others to develop applications with platform UI toolkits? They are just transferring the cost to the users. We get inconsistent shortcuts, widgets, etc. between programs. No automator support, etc. There is only a benefit to people who use multiple platforms and want to applications to look the same on every platform. But the vast majority of users just uses one platform, or two if we include tablets/phones (which have different input methods anyway).

greenhouse_gas 9y ago
>Small independent development companies have done applications across multiple platforms by using their native toolkits for decades Really? How many programs supported Linux before electron?
- danieldk 9y ago
  Usually these companies supported macOS and Windows. I am sure they would have also supported Linux if it had a desktop penetration of more than 1% and if the Linux community was less hostile to closed-source applications. Don’t take this the wrong way (I was a full time Linux/BSD desktop user from 1994 to 2007 and still have one Linux desktop machine at home), but do we really want to significantly degrade the experience of 99% of the users for 1% of the market?

mhd 9y ago

I'm not the biggest fan of this sed reinvention of PostScript we call the browser stack, but my main problem with Electron and the like isn't this, but their design target: Making desktop apps look and feel like web apps. We're throwing away all kinds of HIG achievements since 1984, for the sake of pretty colors and superfluous transitions. Not too long ago, a considerable effort was spent to make web apps behave like desktop apps, now the inverse is true. I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure.

anticnstrctv 9y ago
Making desktop apps look and feel like web apps. This is a good point. However, it does seem like web and mobile apps and their ilk are the future for the bulk of software the majority of people use (excluding, let's say, "Pro" apps like photoshop, excel, dev tools). I'm not a huge fan of this, but the times have changed. I'm not sure that traditional desktop apps are really what I'd use the hypothetical framework I described to build. Something like my business expense tracking app, though? If I wanted it to sync and be functionally identical to the app on my phone? I could see this framework being used for that.
y4mi 9y ago
> I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure. you can't just drop a sentence like that and not elaborate on it - unless you want to offend somebody. Each resource hungry "DevOps" tool has its place and has its worth. They're just often misused. A small IT firm with <10 Hypervisors won't need openstack for example. Thats only worth its maintenance if you're working with tens or hundreds or hardware machines. And a webapp which consists of <10 services probably doesn't need service discovery and advanced de-/commissioning of containers/vms. Administering hundreds of microservices without that is borderline impossible however.
- mhd 9y ago
  DevOps as a practice isn't wrong, of course. Sysadmins scripted and programmed since the dawn of the silicon Pleistocene. But if every small company hires someone with that specific job description, well, you have to spend your 80+ startup hours somewhere.

kenhwang 9y ago

Or maybe the other way around: what if a browser was modular down to the feature level? Don't use CSS/JS/HTML feature X/Y/Z? It's removed from the engine at compile time. That way you're only shipping what you're using, not a mini-OS. Or maybe the JVM approach, where there's one electron process on the system, and all the electron apps on the system are run in the same process. That way at least the rendering/JS engine can be shared. It'd be like Firefox before electrolysis. Though, having your chat client crash and also take down your music player and code editor seems like a terrible user experience.

accatyyc 9y ago
One big problem with Electron apps today IMO is that different apps cannot share memory, even though 90% of them is the same (Chrome/V8 etc). That would be solved if you had one Electron binary that started each app, much like a JVM. They would still be different processes so one app couldn't bring down another, but at least they would share memory pages and copy on write which would make the multi-electron-app world better. (IMO) It would also have the benefit that you could update once and not run an old chat app with old Chrome security issues, until each developer decides to update Electron. But I guess the argument against that is that it's no longer "truly cross platform" since an Electron app may have to support multiple Electron versions. This is how things always have been though, developers just seem a lot more lazy about it nowadays.
- realharo 9y ago
  I'm not sure you would save that much memory. It would be a similar situation to having Chrome open with a bunch of tabs (those are separate processes as well) - it's the tabs themselves that consume most of the memory, compared to "bare" Chrome.
  - accatyyc 9y ago
    On my computer, "bare" Chrome with 0 tabs open still uses ~100MB of memory. If Electron would just use 100MB for the base compared to 100 * number of open Electron apps, that's still a pretty big win in my book.

dvfjsdhgfv 9y ago

I very much hope Red finally takes off. Currently the GUI frontend works only on Windows and macOS, not on Linux yet. But once it does, we'll finally have a truly multiplatform tool for creating simple apps (such as the ones Electron is used for). As for more complex apps, this might well be possible as well, but I haven't seen anything really complex created in Red yet.

daxfohl 9y ago

I wouldn't get my hopes up. Javascript is the only runtime allowed on ios. Desktop is no longer worth innovating for. Meanwhile web ui frameworks are going gangbusters with innovation. That leaves a fairly slim line for any real ui innovation outside of the HTML css js triumvirate.

benjaminl 9y ago

It is amazing that React and friends work as well as they do, and for certain applications they make a lot of sense. But there is a fundamental disconnect using web technologies for native apps. The solution I am pursuing right now is Microsoft's Xamarin. The C#\XAML stack supports iOS, Android, MacOS and Android. The only thing it is missing is web. But with a couple serious projects working on compiling C# to WebAssembly perhaps that will happen.

tonyedgecombe 9y ago
I thought it was just a poor winforms clone on macOS.
- oblio 9y ago
  Correct me if I'm wrong, but I think Xamarin just wraps Cocoa.
- benjaminl 9y ago
  Like the rest of Xamarin's platforms, you can use modern XAML with MVVM patterns or you can use XCode's Interface Builder to create your views. Xamarin.Forms has no relationship to WinForms.
pjmlp 9y ago
Microsoft is serious on the WebAssembly part. https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-experimental-project/ https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-ex...

mateuszf 9y ago

It's not that simple. You can go three routes: 1. Make the apps look pixel perfectly the same on all platforms - that's what the Java Swing did. Result - all the apps feel "alien" and not native for the users. 2. Make all the apps look and behave native and use UX patterns consistent to the given platform. Result - you will have to program them differently. 3. Somewhere in between - all you get is mediocre GUI with not very pleasant development model. So the problem is not with the GUI toolkits but with inconsistent UX paradigms between the platforms / different input models, interaction models, etc.

Numberwang 9y ago
I have no problem with things feeling alien, so that would be my preference. For example I love the Telegram desktop app.
- adolfojp 9y ago
  Telegram looks native on Windows 10 though. It was designed to look like a flat modern app and it excels at that, hamburger menu and all.
  - Numberwang 9y ago
    Hmm, the header bar doesnt look native to me (it looks amazing)
pas 9y ago
Alien would be okay, were it not ugly. Swing is unusable and ugly. Just look at and try to use a Swing file picker. ... Anyway, I'd gladly program them differently for closer to native experience, if it were easy to program. Currently it's either Qt (C++) or GTK (C), or completely useless/out-of-date bindings. And thus any glorified WebView reigns supreme.
- mateuszf 9y ago
  Yeah, I agree - C/C++ are the reasons why Qt is not popular.

ergothus 9y ago

Are the options the best they could be? Heck no, not even close. Html is semantic enough to be tedious but not enough yo be useful. Css makes the easy things hard and people have entire philosophies around minimizing the "cascading" part. Js is at best stuck with warts to try and maintain backwards compatibility. Meanwhile the tooling to deal with missing pieces or complications that are not missing is complex enough that both new and experienced devs complain. The less said about the security complexity the better. And I'm saying all of that as someone that uses these daily and enjoys it. BUT...is it the best that is practical for the time? Probably. There have been efforts to replace these options...theyve failed. Perhaps wasm will change things, but perhaps not. Until then though, I think it is interesting to ask "Why?" Why, if these other options are superior, do they not catch on? Linux, git, nginx, these are just a few examples of dramatic tech switches that had to overcome an existing base. It isnt just backwards compatibility either - Babel exists for es6+, but I've not seen a non js-like language that can compile to js achieve much success. I suspect there are one or two areas that the current offerings handle well that aren't being credited or understood. Computer UI is a young field, computer interactions with business and marketing over time are all poorly understood. We spend much of our time reinventing our spinning wheels and relearning lessons. Html in js is bad. No, it is good. Inline css is bad. No, it is good. This isn't all wasted time, there is a lot of learning time. So I doubt we even understand yet what would make a better toolset.

ec109685 9y ago

> I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place. React Native doesn't use HTML/CSS at all for rendering.

hooluupog 9y ago

Flutter has the potential once it ported to desktop and even web(with WASM).

gman83 9y ago
I think it'll only be ported to desktop once Fuchsia comes closer to release (which could be several years). They really seem focused on mobile only at the moment. Agree it could be a great solution.
markdog12 9y ago
Looks like it has started (MacOS for now) https://github.com/google/flutter-desktop-embedding https://github.com/google/flutter-desktop-embedding

zwetan 9y ago

You just described Adobe AIR eg. "something that has consistent, cross platform (desktop and mobile [...]), responsive ui, without the huge web stack"

raquo 9y ago

I really don't mind the HTML / CSS part with new developments such as CSS grid. If you're running it in a controlled environment (embedded browser), you could cut out a bunch of legacy crap, leaving a much leaner engine. Similar cleanup could be done on the DOM API, I guess.

cm2187 9y ago
There is something to be said about html being too basic for developping apps efficiently. There is no menu control, contextual menu control, if you want to handle dragging and dropping UI items or creating an overlay modal window you need to do all sorts of hacks. On a desktop UI framework these are often a single line of code and it’s hard to get it wrong. I don’t think html/css is really comparable to the major native UI frameworks in term of productivity and correctness of apps produced. I see so many websites trying to implement their own UI behaviors and getting it wrong, not scrolling smoothly, showing a modal window partially off screen in certain scenarios, preventing you from zooming out on a smartphone while overflowing the text outside of the screen, menus that are either not touch or mouse friendly, etc. Giving UI developpers only html and css is like telling a graphic designer: all you need is microsoft paint, you see you can change the color of each pixel to whatever you want, total freedom! Yeah... No.
- raquo 9y ago
  Being relatively low level is a feature. HTML / CSS / JS are languages, not frameworks. One liner modals are not a feature a language should have. If you want, you can make a framework on top of it that will behave like a desktop UI framework with standardized elements and behaviours. There are plenty of such frameworks actually. But not having to use such a framework is nice. Besides, the current browser environment has been historically heavily optimized for websites, not desktop apps. If it became a popular choice for desktop app UI we'd have developed more appropriate features for that use case.
  - cm2187 9y ago
    Why do you call html and css a language? To me it’s a UI framework very much like winform, wpf & al.

gunn 9y ago

Yes. I'd like to see a stripped down embeddable browser engine - https://news.ycombinator.com/item?id=9914925 https://news.ycombinator.com/item?id=9914925 Also there are existing projects like https://github.com/ptmt/react-native-macos https://github.com/ptmt/react-native-macos

jbergens 9y ago
Like Sciter? https://sciter.com/ https://sciter.com/ I think WPF/XAML could have worked also but there were not much work to port it to anything but Windows.
- gunn 9y ago
  That's almost exactly what I was thinking of. There does look to be a big caveat with it though - instead of JS, it has an ECMAScript variant called TIScript. I'm sure this was a good choice when it was made, but javascript libraries and tooling are a lot to miss out on now.
deleted 9y ago
[deleted]

Sawamara 9y ago

I am sorry, but I honestly do not think that PYTHON of all the things would be the solution to a "UI-problem". To have a good UI system, you need extensibility, you need testing, you need strong types (this one is debatable, but I truly believe this to be true after working with Typescript-based HTML UI-s for the past 6+ months now), and you need performance. I can understand that a lot of programmers got into the mindset of "no, I wont deal with HTML", and I frequently see devs mentioning that they prefer that apps look "native", which is something that has not been a standard in the mainstream dev world for quite a few years now, but the reality is that that "native" dream is gone. People all around the world interact with mobile apps MORE than their dessktop/mobile system'S native ui, so there is no baseline to go back to, there is no good old days to retrieve. We can only move forward with what we have learned, imho. And that might be or might not be HTML, but if something comes along, it better learn all the lessons that we collectively are learning with working through HTML-CSS-JS SPA's.

zserge 9y ago

I agree with you, and I tried my best to change things. A few years ago I made Anvil - a React-ish framework for Android for native UI (reactive, declarative, works best with Redux) and have been using it in many production apps as long as I was doing Android development. But it still is a niche product, most developers prefer visual UI editor and whatever is the official Google way to do Android apps. Still, I'm very proud of Anvil. https://github.com/zserge/anvil https://github.com/zserge/anvil Then, once I had to deal with desktop apps I figured out that HTML/CSS/JS seems to be the best option for custom (no native widgets) and modern (animations, shadows, nice fonts etc) UI. But Electron was a heavy beast, so I made a tiny wrapper over native browser engines (webviews). So far I'm very happy with it, it's much lighter and smaller than electron. And it's very convenient to use from C++ or Go. Some kind people added Rust and Nim support, I'm now working on Python and Node.js bindings. So yeah, it's pretty much language-agnostic, although it's still web UI. I really hope it can take it's niche for small desktop apps that don't need the full power of Electron, yet need to have a good look. https://github.com/zserge/webview https://github.com/zserge/webview

moosingin3space 9y ago
Been enjoying your library webview for some small home projects. Thanks!

swiley 9y ago

TCL/TK runs on literally everything except the iPhone.

rebolek 9y ago

Sounds like what Red language http://www.red-lang.org/ http://www.red-lang.org/ is trying to achieve. It is still in Alpha, but already has cross platform GUI for Windows and OS X (with Androind arriving in next release). And without the web stack bloat, it's just single ~1 MB executable.

pier25 9y ago

I've been working in UI for almost 20 years. I've done flash, native desktop, games, web, mobile, etc, and I think HTML+CSS+JS is still the best abstraction for UI IMO. It's certainly not without it's problems though. JS sucks and native performance is way better, but no one can deny it's so much more flexible and powerful than any other thing out there. Here is a great article on this topic: https://medium.com/missive-app/our-dirty-little-secret-cross-platform-email-client-with-nothing-but-html-aa12fc33bb02 https://medium.com/missive-app/our-dirty-little-secret-cross...

mamcx 9y ago

I'm starting a project with a strong need of build the UI in multiple targets (iOS, Android mainly). I try first with html and the native webview. With iOS is totally fine, but Android is SUPER slow. I never imagine that android was this bad, but at least, it force me to do native :) ---- I think that is possible to do what you describe, and I'm working something like. The key is decouple some task (kinda separate "back-end" UI from "front-end" UI): We can do "partial" cross-platform UI, if we think that some stuff can actually cross cleanly: - Layout (the big one, IMHO) with something like https://yogalayout.com https://yogalayout.com - The ELM architecture (https://www.elm-tutorial.org/en/02-elm-arch/01-introduction.html https://www.elm-tutorial.org/en/02-elm-arch/01-introduction....) because a big chunk of the logic is totally cross-platform and "only" need to adapt the render of controls. - Dispatching, events and similar stuff, that is not visual. Then finally, the rest can be fully native: - Controls - Drawing - Animations - Call to native libs ---- The big question is what to use for coding this. I'm using .net but wish to have something more low-level. I know swift and it could work for other targets (Java, .NET, native) with http://elementscompiler.com http://elementscompiler.com Wish to have a coding partner to do this :)

glibgil 9y ago

https://www.youtube.com/watch?v=yOiuJ_Gll_E&feature=youtu.be&t=38s https://www.youtube.com/watch?v=yOiuJ_Gll_E&feature=youtu.be...

rms25 9y ago

Look up QML (Qt Quick) on Qt, its the easiest UI building experience I've ever had Funny that QML looks alot like the JavaFX script that was abandoned