I really want to like Flutter, but I someone really don't want to spend the time to learn Dart. I can't really quantify it--some mix of yet-another Proprietary Google Technology, yet another ecosystem, yet another X. I'm tired I just want to build stuff that solves problems.
Using frameworks like Qt in native C++ sucks because C and C++ are just terrible languages for GUI development, even with the bolted on object systems and language extensions (Qt extends the C++ language).
Using bindings to those frameworks is nice in theory because you don't have to manually manage your own memory or use their type system, but in practice you still need to understand how their types bridge to your language's types and how their memory management bridges with your language's memory management (typically a GC). So while you're dealing with C types and manual memory management less frequently, when you do have to deal with it, it's more complicated than dealing with it in standard C/C++. So (3) is hardly better than (2).
Electron is probably the most cost-effective option, but it has its own problems (notably the high resource consumption that comes from bundling a whole web browser).
With those considerations in mind, learning a new high level language is the least of all problems, especially if the GUI framework is high-quality.
As someone developing GUIs with Qt bindings for Python daily, and has been for the past 8-9 years, I respectfully disagree.
Understanding of the underlying types and memory management is rarely an issue (e.g. once every 3 months), and when it is it's incredibly straightforward (e.g. maintaining reference to a window you've just created else Python garbage collects it for you).
Topics like these appear every now and then and remind me how there are still developers out there that still struggle to find the right combination of language and framework, some resorting to Electron because of assertions like this. This is a solved problem for my line of work - VFX and workflow related tools.
Python probably does eliminate a lot of problems of QT, much of its being the static typing of c++. However you are still bound by qt's internal widgets. Creating custom widgets requires reasoning about the renderer and qt's internal code.
The styling system of qt is also quite limited. Their 'css' is a small set that does not work well on everything.
HTML+CSS allows for creating almost anything, it's the same on all platforms if the renderer is right. It's seperate from code and easily viewable and debuggable within a browser program. I have yet to see anything similiar with Qt, or a style heavy program like Discord made in Qt without becoming spaghetti.
I think Python is a poor choice for UI because it doesn't have a history of handling asynchronous things well. It leans on Qt a lot.
But I also disagree that the styling is quite limited. Yeah, css in Qt is pretty limited, but creating a custom widget doesn't require all that much intimate knowledge (depending how custom we're talking). You can tweak the behavior of default widgets easily, you can draw a completely new one by painting and following the rules (for sizing, redrawing, etc). For new interaction models you'll need to be more familiar with the internals, but that's the case if you're stretching the limits of any framework.
Qt works really well for cross-platform apps that adhere to the OS' style and behavior. I think way too many apps waste time and frustrate users by reinventing the wheel. QML seems to be their approach to UIs untethered to the host OS (I don't have any experience) and seems to be their focus for the past handful of years. Their Qt (Widget) demos always show a bunch of cool features I rarely use, but I do pilfer their code for examples when I need something.
For a Discord like example; Maya, Nuke, and Houdini were all originally developed using their own UI toolkits and have migrated to Qt while maintaining each of their distinctive behaviors. They are all cross platform and require relatively low overhead and high performance with heavily customized UI behaviors.
These apps did fork Qt5 when they moved from Qt4 to Qt5, but it was mostly Qt4 regressions and did it in a way intending to contribute their changes back into Qt mainline.
Putting aside the many resource problems with Electron apps, can you achieve the level of user experience that the Electron folks do?
I see Electron devs being asked to match the slickness of an existing website with similar delivery time and productivity. You don't seem to be able to get close to that with native APIs, API frameworks, or higher-level tools without a lot of work. When you remove these UI and delivery requirements then almost all other frameworks seem to have a fighting chance.
My experience is that every Electron app I’ve ever tried has a terrible “user experience” compared to average competently made native Mac apps. Their core UI widgets are non-standard for the platform and are full of bugs and inconsistencies. Latency is through the roof on all sorts of common interactions. They don’t integrate well with standard expected OS features/services. They burn massive amounts of system resources.
From my perspective as a user, Electron apps are for companies who don’t really care much about quality and are too cheap and lazy to write native apps. YMMV.
I’m a company of one and I care about quality. I’ve shipped native apps for Mac, iOS and Android.
About a year ago I began work on Label LIVE, an Electron app to interface with thermal label printers. It’s not perfect but it fills a niche. It wouldn’t exist if it wasn’t for Electron. Check out the video or download and give it a try. http://label.live
My argument is that the UI requirements are almost always nonsense. I hate launching a new app and trying to figure out a new interaction model or fighting a themes/fonts that fight my needs (font sizes, contrasting colors, etc). Basic stuff is often broken and there's a long tail, if ever, for them to get fixed. They're also the best candidates to break during an OS or other library update.
The whole reason OSes give you reusable components is so its easy to implement the conventions users are familiar with. Those are the things that are supposed to be fast and easy.
This likely violates the delivery timelines, but Maya, Nuke, and Houdini are all professional, heavily customized apps that were written in their own UI toolkits but were ported years ago to Qt and are cross platform.
FreePascal with Lazarus, the true cross-platform GUI framework is similar to Delphi's VCL or .Net's WinForms, it's been in active development for over a decade, and you compile your program into native machine code to a lot of platforms.
Why is Electron so popular, but PWAs have seemingly failed to take off? Everyone was beating the PWA drum for a while, but I've almost never seen it implemented.
What's the reason, lack of discoverability? I'd rather run one Chrome instance than a dozen apps that use varying versions of Electron.
My guess is that teaching users a different way to install a desktop app limits adoption.
The dependency on Chrome is a turnoff for people who don't already use Chrome. An Electron app just depends on the operating system (apparently), so the install is much like other desktop apps.
What matters to developers is not the same as what matters to users.
Users: Does it run and do the things I want and It's obvious how to access it?
PWA's are a sandboxed environment, where devs do not have control of browser version, cannot modify chromium, and cannot bundle necessary binary code. Even Spotify bundles in faster JSON parsers, and probably a number of other things.
I've given up on Electron-based apps and just use the corresponding webapp in a tab in Firefox (and if they don't offer one, I usually just do without the app). I got here because I got tired of running several extra browsers that ate up my RAM and killed performance.
An average user might not be able to connect the dots this way and realize what's going on with their machine. They'll just complain "my laptop is slow all the time and I don't know why". As developers, I feel like we have a responsibility to take better care of our users in this manner. Using a solution that will consume a GB or more of unshareable memory for something that doesn't need it (which is mostly everything) is a poor choice that puts the developer's needs (write-once-run-anywhere; faster, cheaper development time; fewer developers needed) over the user's.
So I fundamentally disagree that users only care that the app does the things they want, and nothing more.
Is this part of what Microsoft is doing with Chrome being pre-installed (via Edge)? I can't find a source, but I heard that using the existing chrome on the machine would reduce disk size for applications and possibly even allow them to share memory.
A lot of PWA features aren't implemented everywhere, and that depends entirely on browser vendors' decisions. i.e. a lot of API's are not supported in Mobile Safari, and in general, it takes a pretty significant amount of time for a Web feature to appear in all major browsers.
Because with Electron the "app builder" decides which extensions are ran. With a PWA, the user. Like 33% of all users use ad blockers, so its all about $$$. That (no incentive), and Electron was first...
QML is in the category of "learning a new language", although last I tried it it was very much a work in progress. Can't speak to how good it is today.
QML is a declarative language; it has curly braces like JS, but that's about it. It also allows you to extend it with (some old, possibly noncompliant version of) JS, but the declarative markup is a distinct language.
That's like saying every YAML or JSON dialect is a new language. Sure, but not a full-fledged "programming language". QML is quite nice to work with, and well suited to the problem at hand.
Granted, it's not a general purpose programming language, but it has a comparable learning curve. Certainy many times steeper than YAML or JSON or other markup languages.
To add to this, if you like concept/portability/cost-effectiveness of Electron but don't want to mess with the Node/npm ecosystem, there are chromium embedded frameworks out there for Java and Python[0][1][2].
Another alternative, I think is D-language bindings to QT (or betterC which is a subset of D allowes to use D with C runtime library, while retaining D-s class system, templates and memory safety).
D's team is doing an incredible job of matching C++ compiler specific ABIs, name mangling/etc -- just so D users can use C++ libraries (including templates) directly from D without loosing the features of the language.
Embarcadero Delphi Community Edition lets you compile to Android, iOS, macOS, and Windows with it's FireMonkey framework using a single UI and single codebase. It's free for hobbyists. The paid version plus a third party component adds Linux desktop support as well.
I've tried dart back in the Angular 2 beta days with Angular Dart and after using it I have the exact opposite feeling about it.
It's a thing that solved a lot of very real problems that are still halfassed by NPM and Node ecosystem - package manager, build system, tooling around it - it was all a step above the quality of TypeScript/NPM/JS. Saner object semantics, good standard library, good tooling - it just got me to solving the problems I had. DOM wrappers it had were very nice, came with their own wrappers for Observable events (from standard library). They had proper async/await implementation working waay before TS.
Dart feels like a better TypeScript and for me the learning curve was really low.
One issue I had with it was using Dartium to debug the code - Chromium build that ran Dart VM naively to avoid transpiling to JS all the time - it was buggy as hell back then. Supposedly the dev compiler for JS is fast enough now that this isn't an issue - and in the case of Flutter you're running Dart natively so it's irrelevant.
I'm looking forward to doing a new project in Flutter this weekend - I've played with a hello world app when it was in beta and I was very impressed with the dev experience - hopefully it lives up to it in practice.
I concur. I've never tried it with Angular, but I have written it for Flutter, and after a couple decades with JavaScript, I much prefer Dart (and it took no time to learn and I simply Google for the API as much or less than any other new language I learn these days). It was easy to start building a Flutter app with it immediately--not much of a learning curve to speak of. Whether or not I know it super well is beside the point--after a short time with it, I can use it productively and found it alongside the Flutter classes to be easier to get going with than Swift, Objective-C, Cordova, and even Rubymotion (Rubymotion is also pretty quick and friendly compared to the other options, but Dart/Flutter is a bit faster if you're a native mobile noob mainly because with Rubymotion you need to dig into the Apple APIs a bit, but with Flutter it's more abstracted).
That's only if you use Typescript as a class-based OOP language. If you're more used to functional programming and prototypal inheritance, then Dart will bear no familiarity.
Due to its adherence to classical OOP, it feels way more like Java than Javascript.
As someone who never did any serious programing in those classical OOP languages, I struggled a lot to find the right abstractions to implement any kind of clean business logic. It was the first time I had to actually read up about "design patterns" and unironically consider writing factory factories.
It seems that due to Dart's rigidity and adherence to classical OOP, any library which needs to deviate from this paradigm has to hook into an additional build step (e.g. built_value for immutable types, has to use build_runner). That's an acceptable compromise for lib users, but adds a huge burden to actually writing those libraries, let alone incorporating those in your app's code.
Yes, Dart is a fairly standard object-oriented language, but this exaggerates a bit. Dart has first-class functions (unlike Java) so you shouldn't need a factory-factory in the simple case. That's just a function that returns a function.
Ok, but to parent’s point... is it going to last? Is it yet another thing Google will abandon? Is it worth learning, because learning another language has a real cost imo. If Google walks at any point, does Flutter or Dart survive?
I’m with him, I want to like the idea, but I think the adoption has been slow and it doesn’t appear like it’s going to suddenly take off. I could be wrong, I just don’t see any successful indications yet.
> is it going to last? Is it yet another thing Google will abandon?
It's apparently the primary language for Google Ads. As such, I expect it to be maintained as long as Google continues to sell ads and if they do move away from it you'll have plenty of warning.
But this isn't a framework alone. It's a framework (flutter) and a language (dart). And at this point both are entirely dependent on each other, if I'm not mistaken.
I don't know what you mean? Google has many large ad customers who use the web UI to manage their campaigns.
Common Lisp was rarely used at Google when I was there, though it's a big company and you do see a little of everything, sometimes due to acquisitions. You might be thinking of ITA software, which is (was?) used for airline reservations.
>It's apparently the primary language for Google Ads.
That's Dart, not Flutter.
And even so, Dart transpiles to JS for the Google Ads. They could switch to plain JS, or Typescript, or even move to a whole new implementation of Google Ads, and pull the plug.
I think it got enough adoption so far that it's not going away overnight and should be usable since people already published apps with it.
From my point of view learning Dart/Flutter isn't really a big investment so the downside of it getting abandoned soon is not as large as the payoff if it actually delivers - quality cross platform UI framework with great dev experience that I can use on my projects.
Except if Google gets bored with Fuchsia, like it has with tons of projects.
Heck, from what you say, it already got bored with Android -- if Fucshia is to replace it in say 2022, it means that Android just lasted around 15 years as a platform.
>Android is definitely struggling and showing its age by this point
I have the opposite viewpoint on this. I've worked on mobile the last 5 years or so, and dedicated native Android the last 2.5 years. The last year or two have been dramatic revolutions in the Android developer experience, from my perspective. Things like ConstraintLayout and full Kotlin support with ktx have opened up a new world for me compared to the state of the art several years ago.
Then you look at companies like Peloton using large form-factor Android devices in their core products, and Samsung DEx using Android as a seamless mobile<->desktop computer.
To me it seems like Android is just hitting it's stride. Who knows though, it's Google.
Wikipedia lists the last release of MS-DOS as version 8.0 in 2000, linking to the page for Windows ME.
This is what the comments above were alluding to, a "final release" before the project is abandoned. Installations still continue, in the same way there's probably places still doing the books on a C64, but it's no longer supported.
In general it's just really disappointing that in 2019 the development frameworks we have available are still objectively worse in terms of developer productivity, reliability, and documentation than what we had with Microsoft Visual Basic or Borland Delphi back in 1996. I totally understand that these modern frameworks are superior when it comes to cross-platform compatibility and easy application distribution, but everything else seems like a step backwards, or at best sideways.
Compare a 1980 compiler with the optimizations GCC and LLVM make.
Or v8 with the best interpreter in 1990.
Or video codecs (almost non existent then). Or cryptography code (immensely improved). Or the capabilities of InDesign compared to a 1990 DTP. Or Photoshop compared to crude editors in the 80s. Or modern GCs versus crude 80s and 90s GCs. Or a modern DAW compared to 1990s midi apps...
If you want what you had with Visual Basic in 1996, you're in luck: you can just use C# with winforms, which is like a much better version of VB6.
Unfortunately, in 2019 cross-platform compatibility for native apps has only gotten harder (good luck supporting windows, mac, linux, android, and ios), which is why people tend to default to making web apps (or hybrid solutions using frameworks like React Native) rather than native apps, and this has perhaps also created a vicious circle by reducing interest in what cross-platform options there are (QT and javaFX).
> which is why people tend to default to making web apps (or hybrid solutions using frameworks like React Native) rather than native apps
Not sure why people keep making the claim that native is dying. More and more people are doing their computing on their smartphones and the vast majority of the top 100 apps on both iOS and Android are built in Objective-C/Swift/Java/Kotlin. It seems to me like the main people pushing the whole web app/PWA renaissance are web developers who resent the fact that the web is dying.
Check the Lazarus IDE (https://www.lazarus-ide.org/), it's very similar to Delphi with an integrated code editor, visual GUI designer and debugger - you can debug on the target platform including Linux, Windows, Mac, Raspberry Pi, and so on.
I learned Visual Basic 6 from a cousin when I was 8 years old. It was such a joy to use, and made me fall in love with programming. It was so intuitive to use as an 8 year-old. And while Dijkstra might disapprove, the Basic language of VB6 was really simple and easy to grasp as a kid.
The coolest part was distribution. Under the File menu, you had an option to build a .exe file. I would build it and put the .exe file on 1.44 MB floppy disk, and share my little VB6 programs with friends. Such wonderful memories!
Dijkstra had issues with the older BASICs where the only way to control flow was with GOTOs and people flinging them all over the place. Visual Basic 6 (and QBasic before it) has Algol-like structures like subs, functions, while/repeat loops, etc so it would satisfy the issues Dijkstra had with older BASICs (if he'd dislike it for other reasons is another matter though).
Most people just repeat Dijkstra's headlines without having even read his text, let alone understanding it.
To which I can reply 'come back in 20 years and tell me about your experience maintaining something based on npm and friends'. At least those old crufty systems had the good grace of not having a best-before date measured in weeks. They might lack many other graces but for maintainability there is something to be said for a modicum of temporal stability when it comes to development environments.
One of the things that we sacrificed was what today we would call "end-user programmability" but which should really just be called "using a personal computer." Hypercard was a UI builder, a way for regular people to program beyond the strict limits of the software given to them, and a hypermedia platform whose "applications" could be easily distributed. To do most of the things that Hypercard could do on a personal computing system of the early 90s on a system today requires someone to learn a full fledged programming language
To me Dart is pretty disappointing. Modern languages like Swift and Rust have shown the power of incorporating functional features like sum types and pattern matching. Dart just feels like the same sort of OO language we've been getting since Java became popular.
Edit: Also the continued existence of null in new programming languages is a baffling choice to me.
I don't blame you for being underwhelmed. The original goal was an easy to learn language. But since Dart 2.0 was completed, they are working on adding many other language features, including NNBD (Non-null by default).
It’s just hard to be productive in Dart. The Flutter IDE and simulators were so resource intensive, they literally locked up my laptop the last time I tried using them.
Dart is objectively a terrible language to be productive in for app development. The abstractions provided by the language are clunky to use for window elements on a device screen. Don’t get me started on Material Design, either.
Swift, Objective-C/C++, or even Java is way easier to start building apps with, in comparison. The tooling is mediocre for Dart as well.
> functional features like sum types and pattern matching
"Functional features" means different things to different people. Dart (like most modern languages) has a lot of the core functional features: first-class functions, closures, lambdas, higher-order functions. Our built-in collection libraries are heavily oriented around functional-style transformations. You don't need an external library to map() and filter() your lists to your heart's content.
At the type system level, we also have function types, generic functions, and even first-class generic functions, which is a really unusual, powerful feature.
Sum types are a slightly different beast. Sum types are basically a functional language's answer to subtyping and runtime polymorphism. But object-oriented languages already have full subtyping and polymorphism using classes. There's a sort of zen koan here where algebraic datatypes are a poor man's subclasses and subclasses are a poor man's algebraic datatypes.
The way most multi-paradigm languages like Scala and Kotlin handle this is that sum types are just syntactic sugar for defining a little class hierarchy. Likewise, pattern-matching becomes syntax sugar for instanceof checks and field access. I like that sugar and hope we can add something similar to Dart, but I don't find it's omission to be a profound oversight. It makes some kinds of code nicer, but doesn't significantly affect the expressiveness or capability of the language.
> Dart just feels like the same sort of OO language we've been getting since Java became popular.
Yeah. The original designers of the language designed something very conservative. I think they wanted to make a VM with certain features (single dispatch, static class structure, no static initialization, etc.), and designed the safest language they could come up with to let them do that.
There is a lot of benefit to familiarity. I like classes and C-family syntax, and we see very clearly that Dart is really easy for people to learn and become productive in. We've done user studies where participants have been able to write correct Dart code without knowing what language they were using. It's hard to underestimate the value of that.
But there is also value in providing the modern tools people want in order to write clean, beautiful, correct, maintainable code. Dart has some catching up to do there. We're making a lot of progress. With Dart 2.0, we replaced the old unsound optional type system with a real, modern, expressive, sound static type system. It was a ton of work to do that while dealing with millions of lines of existing code.
We didn't get all the type system features we wanted, but we have a foundation we can build on now. The optional type system had some nice properties, but was effectively a dead end. When your types are optional, you can't hang any language semantics off them. That takes lots of features off the table: implicit conversions, extension methods, etc.
> Also the continued existence of null in new programming languages is a baffling choice to me.
I have always believed [0] that not having non-nullable types was a mistake in Dart 1.0. We are fixing it now:
There's a lot of work to do, but I'm really excited with the design. Unlike many other languages, we have something that becomes fully sound with respect to null errors. This means that once a program is fully migrated, a compiler will be able to take advantage of non-nullable types for performance optimizations. It will be quite a while before we get to the point where we can do this, but it's cool that that's on the table.
> It makes some kinds of code nicer, but doesn't significantly affect the expressiveness or capability of the language.
Sum types and exhaustive pattern matching aren't about expressiveness, they're tools for aiding code comprehension by increasing the locality of code that has no business being distributed into completely different classes, and decreasing the cost of making changes by heavily reducing the amount of test code that needs to be written to make sure a closed set of options is handled appropiately; in OOP languages you can get this by using interfaces but to make use of it you'd have to use huge classes with methods pertaining to every usage of this closed set.
I would never willingly pick up another language that doesn't provide me with them after experiencing the productivity gains. I really like the direction Dart is moving towards and the steps taken demonstrate there's a team behind it that cares about correctness and productivity over being just a familiar Java-like, but this is the one hard blocker for me.
> they're tools for aiding code comprehension by increasing the locality of code that has no business being distributed into completely different classes
That's true for some kinds of code but not others. This is the classic Expression Problem [0]. For some things, it makes sense to keep all of the code for a single operation together. For others, it makes more sense to keep all of the code for a single datatype together. ML-style languages optimize for the former, and object-oriented languages optimize for the latter.
In practice, for the kinds of code Dart is designed for, the latter is a better fit most of the time. There's a reason OO and UI have been married together for decades.
Ideally, a language provides both styles so you can choose the one that fits your problem best. You see that now with languages like Scala. I hope we get there with Dart too.
I don't think it's fair to say that subclassing and method dispatch is objectively wrong just because it's a bad fit for some kinds of code. (Though, naturally, if it's a bad fit for the kind of code you need to write, then an OO language might be an objectively bad choice for you.) Class-based method dispatch is annoying for some things (God knows I've written enough Visitor pattern implementations over object-oriented AST class hierarchies), but it's really beautiful for others.
Being able to define a new widget class that bundles its rendering and interaction behavior together and can seamlessly extend a UI framework is something so natural that we take it for granted, but is very difficult to express in a language like SML. In fact, in order to do it, you'll probably end up doing a "design pattern" that reimplements something like v-tables at the application level.
Not sure if I gave off the wrong impression, but I am not a proponent of having only sum types and discarding hierarchies; as you well mentioned each is well-suited to specific usecases.
I do however disagree on subclassing being the best fit for UI code. "The Elm architecture" as well as the model presented by React functional components with hooks offer sets of tradeoffs that I at least have found are better for most of the development I find myself doing when writing (and particularly when maintaining) regular business frontends.
> There's a reason OO and UI have been married together for decades.
People repeat this a lot, that OO goes with UI, but I don't think it's actually true, and I think e.g. React Hooks and immediate mode GUI in general demonstrate that it's not true. OO has been coupled with UI out of inertia, not because OO has unique strengths when applied to UI.
Sum types are a primitive language feature, akin to product types, which absolutely no one rejects the value of. The sum/product analogy to arithmetic is compelling to me: they are the building blocks of complex types and deserve recognition. I think that "zen koan" you mentioned earlier is being very generous to subclassing. You want ADTs most of the time!
> People repeat this a lot, that OO goes with UI, but I don't think it's actually true
It is evidentially true. Thousands of successful applications and a billions of lines of UI code have been written in object oriented languages. It does work and it can't be that bad if that's continuing to happen even after the emergence of other alternatives.
Whether there are better ways is a good question, but I think it's pretty clear that you can ship good apps using OOP for your UI.
> React Hooks and immediate mode GUI in general demonstrate that it's not true.
I'm far enough into my career now — I've been doing UI programming of one form or another since the 90s — to have seen that pendulum swing several times. If there is a silver bullet, we haven't found it. It's probably not immediate mode GUIs because if it was, I wouldn't have seen game teams tear them out to replace them with something more retained several times in the 2000s.
What I think actually happens is that we forget the problems lurking in the solution we are not currently using. The grass over there gets greener and greener until we hop the fence and the cycle starts over. Incremental progress does happen. (I am not keen to revisit MFC any time soon.) But if a given concept (1) has been around a long time (2) has not already supplanted the alternatives, it's pretty unlikely that it is now an amazing solution today. The only time when that isn't true is when the surrounding technology context has changed since then.
For example, neural nets weren't a good solution for AI problems in the 80s because compute was too expensive and we didn't have a lot of data. Now that CPUs are cheap and everyone puts their entire life on the Internet, machine learning is here.
I haven't seen anything around UIs that to me looks like a significantly changed context, so I think we're still orbiting around retained-mode and immediate-mode as both having their own trade-offs and neither being a slam dunk.
> I think that "zen koan" you mentioned earlier is being very generous to subclassing. You want ADTs most of the time!
I really don't think that's true. Just look out there in the world. More code is written in languages doing subclassing every day than in languages with sum types. Despite the fact that sum types have been around since the 70s. You have to have a very uncharitable opinion of all of your fellow programmers to believe they've all been getting this wrong for decades. Heck, the software you are using right now to read this comment is sitting on a stack of several layers of subclass-based architectures! You've got JS running on top of the DOM inside a browser written in C++.
Sum types are really nice. But open-ended subclassing is too.
I wanna hear more open discussion about immediate & retained mode approach.
For one imgui gains traction again, especially among game developers, simply as it gives a lot for the ease of compile, understanding, compactness of code, etc. You can really build complex tools out of it.
But there is one nasty elephnant - the state, and imgui's approach is to hide it somehow - it used be behind your __LINE__ (or __COUNTER__, stack.line in some langs), or maybe part of your label points to your data, and if you've had the bad luck of having same labeled names, then there is yet another workaround, something special hidden in there.
All in all, it seems like it's missing a language feature, and we are suddenly grasping on all kinds of tweaks to achieve that.
That, .. and layout.. Layout is damn hard in immediate language. It works by magic, and then your app might crash, and lock. No I'm not kiddin...
Then again I'm but a simple user of UI toolkits, never fully written one.
First, I just want to say that I use Dart pretty regularly now and enjoy the language. I don't want to come across as overly negative; Dart is a solid language that's made web programming a lot more fun for me. So thank you, and everyone else on the Dart team for the hard work!
I just want to address these lines:
> Thousands of successful applications and a billions of lines of UI code have been written in object oriented languages.
> More code is written in languages doing subclassing every day than in languages with sum types. Despite the fact that sum types have been around since the 70s. You have to have a very uncharitable opinion of all of your fellow programmers to believe they've all been getting this wrong for decades.
I agree that there's a huge amount of code out there using subclassing and not sum types. I'm not disputing the utility of subclassing; I just think the analogy to arithmetic is compelling, in that a closed sum type is a more primitive notion than open ended subclassing. It's easier to describe what a sum type is than what a subclass is; sum types have a smaller impact on a type system than subclassing. Pretty much any metric you can think of, sum types are just simpler, and more widely applicable. Any time you are describing a data structure, an ADT is immediately useful; subtyping may or may not be useful and is always more complicated. It's very difficult for me to understand how anyone could possibly say subtyping is on the same level as a basic operation like addition. Subclassing may or may not be nice but sum types are a primitive in a way that subclassing simply cannot be.
I don't know how to break it down more than this: we already have multiplication of types, and everyone accepts this as a primitive. Well, you can also do addition of types! Multiplication, addition, a neat little pair, just like algebra class[0]. Subclassing is way more complicated than this. That's it, that's a bullet proof argument as far as I'm concerned.
I suppose I do have an uncharitable opinion of mainstream programming languages, because I do think they've been getting this wrong for decades. It's nothing personal, it's just that industry has other concerns besides how clean their languages are. My browser being written in C++ is not an argument in favor of subclassing, though. You can build anything out of toothpicks if you're paid enough.
> I just think the analogy to arithmetic is compelling, in that a closed sum type is a more primitive notion than open ending subclassing.
I agree, sum types have a real beautiful elegance. But I often wonder if that's some sort of "appeal to mathematical aesthetics" fallacy. When I see, for example, painters deciding what brushes to use, I don't see them choosing brushes whose diameter follows the Fibonacci sequence or something.
Simplicity is a virtue because it lowers the cognitive load of a language. I don't know if mapping something to arithmetic tells us something actually profound about the productivity of a language feature, even if it gives me a little shiver of delight when I think about it.
> Any time you are describing a data structure, an ADT is immediately useful
For what it's worth, I often run into problems where I think I can map something to a nice set of ADTs but then it ends up still having ugly corners. As elegant as the language feels, when I use them in practice my code is still awkward sometimes.
> It's very difficult for me to understand how anyone could possibly say subtyping is on the same level as basic operation like addition, one of them is clearly a more basic idea.
Subtyping is set theory, and sets are obviously more fundamental than arithmetic! :D
> we already have multiplication of types, and everyone accepts this as a primitive.
Well, actually, lots of languages don't have tuples and records/structs aren't simple product types.
> I suppose I do have an uncharitable opinion of mainstream programming languages
I wasn't talking about languages I was talking about people. There are languages out there with all of the features you describe. Yet millions of people are choosing other languages. You must have an uncharitable view of those people if you presume that all of them are making a choice that goes against their own self-interest to be happy productive programmers.
> Subtyping is set theory, and sets are obviously more fundamental than arithmetic! :D
In case this wasn't clear, the "arithmetic" in question is being performed on sets (or types). For example, for sum types, the number of inhabitants of the type is the sum of the inhabitants of the components. All three of addition, multiplication and subtyping are operations on sets (types). So this was a strange thing to say.
> Simplicity is a virtue because it lowers the cognitive load of a language. I don't know if mapping something to arithmetic tells us something actually profound about the productivity of a language feature, even if it gives me a little shiver of delight when I think about it.
My real point is this: if you are deciding to build a language, as far as I'm concerned, it is very strange to add multiplication (why don't structs count as multiplication? I would say they do), then not add addition and instead add something much more complicated than addition. It just doesn't make any sense. It's not about the "productivity" (how do we measure this?) of the feature, it's about it not making any sense to do this! You add multiplication, you add addition, that's really all there is to it. I don't know, I guess I'm just repeating myself now and you won't find it convincing, but to me it's like trying to defend Roman numerals after being shown the Arabic system.
> You must have an uncharitable view of those people if you presume that all of them are making a choice that goes against their own self-interest to be happy productive programmers.
I don't think so at all. It's not really a fair choice; people choose languages in order to build things, and it's easier to build things in languages that other people are using. The full range of options is not obvious to every programmer (does the average webdev even know about ML?), and most of the time there are more important concerns than whether your language has a nice theory behind it.
One nice think about Dart I've found is that compile times are very fast (faster than Go) and when editing in VSCode the code intelligence is instant and 100% accurate in my experience.
Compare that to Rust where compilation speed is almost as bad as C++, RLS is slower than e.g. Qt Creator's clang lints, and has auto-completions so innaccurate that they are almost worse than nothing.
Buuut.... I wanted to make a deep copy of an object (a map of maps) in Dart, and one of the suggestions on Stackoverflow is to serialise it to JSON and then deserialise it. Eek. In C++ you just do `auto a = b;`. In Rust `let a = b.clone();`. How do they leave out such basic functionality?
Sure, but does it do what you want? :) If that map contains pointers or other types with "interesting" assignment semantics, then your idea of a deep copy and that author of that type's idea may not be the same. Cloning is a surprisingly hard problem.
The two languages you compare to don't have GCs and prefer value semantics. But in most GC languages, everything is by reference and "copying the bits" isn't as meaningful of an operation.
I looked up how to deep clone maps in some other GC languages:
Python: Import a separate "copy" module. May have to implement some custom methods if you use user-defined objects in the map. The module isn't thread-safe. A comment recommends converting to JSON and back.
As someone who uses dart everyday - it's quite nice language. All I'm missing is case / data classes, non-nullable types and pattern matching, but they're changing the language and all of those will eventually come. For now, I will use built_value and built_collections ;)
> your idea of a deep copy and that author of that type's idea may not be the same
Definitely true that they may have done something weird, but I think the idea of a deep copy is pretty easy to define: It should not be possible to modify the original object using only the deep copy. (Note that this doesn't preclude copy-on-write, etc.)
I think it is quite weird that so few languages (even GC'd ones) provide a proper solution for this. It's clearly a thing people want to do.
You would still have null, but only when asked for and checked explicitly.
In Kotlin, for example, you mark something with a question mark to say that it can be null, which forces you to check for null before using it:
val entityOrPossiblyNull: Entity? = Entity.fetch(id)
if (entityOrPossiblyNull == null) {
doSomething()
}
else {
// The compiler knows that the variable is not null in this branch,
// so this assignment is OK.
val entityForSure: Entity = entityOrPossiblyNull
doSomethingWithEntity(entityForSure)
}
The real problem isn't null itself, it's that in most languages that have it, null inhabits all types (or at least all reference types).
Different languages solve this problem in different ways. Many languages get rid of null entirely, and use option types in its place. Other languages, like Kotlin, fix it in the type system, by differentiating between e.g. String and nullable String (spelled String? in Kotlin) .
I'll chime in as well that learning Dart is totally trivial. I don't like it all that much, since it really feels like your average Java-based language, but I learned it in a day or two while working on a Flutter app. Flutter is a great framework, and Dart gets the job done.
I'm not sure I'd learn Dart apart from Flutter, but if you just treat it as part of learning the framework (think learning ruby along with rails, or Vue's random HTML-esque DSL, which people do), the overall learning curve is not high.
Sure it is, but I can see why OP looks down on it – just like their web rendering engine, it may be open source, but it's Google holding all the cards and ultimately making all the decisions. It may be opensource now while it's useful for them, but it may end up just like Android over the years: more and more closed bit by bit.
A lot of open sources are abandoned in general. Google has a good track record regarding the maintenance of their open source projects. Google has abandoned some proprietary products (Google Reader, Google +, etc.), but it says nothing about their open source strategy.
For a public view it doesn’t really matter if it is proprietary project or not. They have tarnished their own reputation even at the development field with their actions.
Sure Google is worse. A BDFL usually started it as a personal project, has deep interest in making the software flourish in the most places possible. Google interest is their bottom line, and it will base their technical decisions.
Sure, technically. The same way Chromium is technically open source. Funny how everything in the web browser world ends up how Google wants it regardless.
If you are handy with Java, Typescript or Javascript, Dart is a breeze to learn. I didn't invest any time learning Dart to get productive with it while using flutter.
Same here. it feels like a very generic algol family language, and if you're familiar with any of them it's almost trivial to pick up to the point where you can just sort of write it and figure things out as you go.
That was in fact the most pleasant things about Flutter for me, the language was a non-barrier.
So what's your alternative? Java Swing? Proprietary Sun (now Oracle) technology. Qt? Proprietary Trolltech tech. Electron? You're back on square one of using Google technology. And winforms, WPF, application kit, etc are all far more proprietary than Flutter.
My comment was in reply to someone claiming that Dart was "yet-another Proprietary Google Technology". If Dart is proprietary then Qt is, too. Most likely by proprietary they didn't mean license but being controlled by a company, which both are. Dart is open source btw. as well. In fact, you could say that Dart is more open source because in Qt, proprietary ISV developers can't use the open source model if they want to not avoid having to give dynamic linking support and other LGPL obligations.
Dart and Flutter are both BSD licensed, so presumably the discussion of "proprietary" is at least somewhat orthogonal to whether it has an open source license.
Tk is a pretty solid option nowadays, and it's wonderfully cross platform. Thanks to TTk, begone are the olden days when Tk apps stuck out like sore thumbs (the look and feel ain't an exact match even today, but nowadays the differences are more subtle). It also works with a remarkable number of languages. The only reason why I've reached for Qt instead lately is because the last couple projects I've done required an embedded browser window (i.e. because they're wrapping some web-based application) and Tk lacks modern options on that front (though I'd love to fix that at some point).
GTK+ and wxWidgets are other viable and popular choices for cross-platform desktop GUIs.
ReactXP (https://microsoft.github.io/reactxp/) uses TypeScript and targets mobile and desktop platforms using native controls, not emulated controls.
While Flutter doesn't work yet for desktop or web, ReactXP already works for these environments, and is used in the new Skype for Web.
Windows support is done and targets W10, Xbox, and Windows Mixed Reality. MacOS support is experimental, but mostly working. Linux currently needs an Electron wrapper.
There's not much of an ecosystem for multiplatform yet for desktop projects at all. For macOS you have a way of "making a framework you can use" and that's about it.
My sense is that as the mobile multiplatform space gets ironed out, the desktop space will benefit.
Though generally speaking, Kotlin/Native has a _much_ lower level of "institutional" risk, since the Kotlin approach doesn't subvert the control Apple or Microsoft have over their platforms. Flutter, on the other hand, seems to abstract it away.
It actually works really well in IntelliJ Community Edition. There is a template for creating a new Kotlin/Native project, the auto-completion works and there is even unit testing support! Things have come a long way since the early days of compiling your own cinterop stubs and figuring out APIs from the generated wrappers. :)
If you want a debugger you need CLion, though. And the compiler is really, really slow – but they seem to be working on benchmarking things recently, so presumably it will be improved.
The done thing in Java now is JavaFX, and the last time I bothered to work with it (more than a year ago) I remember really liking it. Of course, to me any kind of web tech is a complete non-starter so I am comparing this to using Tcl and WxWidgets.
You could say the same about Objective C, and to a lesser extent Swift. While I respect your opinion, and somewhat agree on it being a weird choice to use Dart, I think there is value in learning it iff it becomes the ubiquitous way to write apps for mobile.
Is it really hard to learn a new language tho? Its not even a hard one, its like a if you mashed java and javascript together. Its pretty simple to pick up.
>> I'm tired I just want to build stuff that solves problems.
I can relate to this. While that's always been part of my motivation, there were other things in play too, like wanting to do something "better" than before. Or using new methods. Or applying X to Y just because. Now, as I get older, I don't want to deal with overly complicated shit, excessive dependencies, or unnecessary bling.
As an example in the GUI space I keep wondering why GTK 4 is getting a scene graph. I've done GFX programming for years and scene graphs are almost never the right answer. Why does a GUI toolkit even need one? No GUI should be that complex. No GUI toolkit should provide one for applications - that's not their job. Don't get me wrong, GTK is my preferred toolkit (in spite of gnome), I just think people keep extending things for the wrong reason. If it works and isn't broke, don't change anything. If the world changed and wants multi-touch, fine, add that. But don't go around doing your science experiments in projects that lots of other people use as infrastructure or building blocks.
> I've done GFX programming for years and scene graphs are almost never the right answer.
Interesting, why would you say that ? I saw a bunch of projects go from "more-or-less smooth at 1080p" to "buttery 120fps smooth at 4k" by migrating to UI toolkits with a scenegraph architecture.
I would've preferred dart to be more opinionated like golang but its not, you can literally write in almost any style and one advantage of that is if you have experience with any modern language, you should be able to write dart with ease.
Dart was actually really opinionated right from the start. Type annotations that has no bearing on execution; reified generics and dynamic typing at the same time; mirrors and noSuchMethod... even having semicolon - as opposed to not having it. These are all strong opinions about language design. They might not align with what is considered "modern" these days, but they are all opinions nevertheless.
I was productive in Dart after few hours, it really fells a lot more solid and thought-out compared to JS or TS. Everything just works immediately and as expected, and the language is super simple yet expressive.
One of the things I love about React and React Native is that it's possible to use them from "plain old JavaScript" (React.createElement and friends). And I work at le Goog; my org has mandated Polymer 2+TypeScript for all new desktop web code.
Sure, maybe in production you want to use JSX and/or TypeScript, but learning a new language and a new framework together is overwhelming, period. Pedagogically, it makes it hard to conceptually separate what is a language feature and what is a framework feature. (To this day, I still have trouble separating what parts are Ruby and what parts are Rails.)
This is a weird comment, Dart is open source and evolves as well, like Swift from Apple, Kotlin from Jetbrains, Typescript from Microsoft etc. What is the difference? Or you don't like any of these?
I would say get used to it. I don't mean that in a degrading way or something, but we're developers. Until the day you retire you will need to keep up with technologies.
I completely agree. I use Flutter a lot, and even after getting used to Dart, I really hate it. It's not a fun language, and I just can't understand why they chose to use it.
I'm personally excited about Flutter largely because it seems the preferred development environment for Fuchsia. People will complain that Google kills projects too soon and too often, but I feel like Google has an MO and when you figure it out you can guess which products will live and die.
I think Fuchsia and Flutter are Google's primary likely plans for the future of their consumer platforms. I don't really know why, it's just a feeling.
A lot of it comes from Google planning 10+ years out a lot of the time. Reader was a mistake to kill, but you could see how Google management thought it would not be a widely useful product in the long-term future (though let's repeat, they were wrong).
I think Flutter+Fuchsia has that 10+ year plan to it. I'm on board with Dart because it seems likely to be a major ease on development along with a likely promising future.
I'm convinced it's going the Google Way™ (i.e. will be abandoned) in 5 years tops. This company has repeatedly shown it can't commit to products that are slow burns and not entirely obvious where revenue may come from. It's part of the reason why I see Go as a fad too.
Same here - its a real shame they picked a niche language for this rather than the now universal Typescript like everything else.
As such, I'll pass since this feels like a dead-end just like polymer was. It felt like polymer had the same hype cycle as flutter - was going to make development so much easier/faster/less error prone etc. It is now a semi-abandoned legacy hulk of a project that people hate working with (anecdote I know, but that has been my experience) because its totally different and alien to how people are used to working, for no/little obvious benefit apart from "this is from google! its got to be good!"
I wish Google would just accept defeat and support existing common tools rather than suffering from "not-invented-here" syndrome and create something totally different and non-compatible, rather than contributing to the existing industry de facto standards to make them better. There may still be a few "google-scale problems", but UI frameworks and HTML libraries are not them.
This is exactly how I feel. The lack of freedom to choose your own language is appalling. I don't want to be locked into a single language. If they targeted the JVM platform instead, would have the choice of Clojure, Scala, Kotlin, JRuby, etc. Also, targeting the JVM makes a lot of sense of Android, since ART complies JVM bytecode down to super-efficient machine code (at installation). I was really disappointed by Google's decision to push those wanting to use Flutter to learn Dart. Fortunately, the Flutter Windows and Linux libraries provide C and C++ wrappers[1]; hopefully these become preeminent, and result in other language bindings for Flutter. I've been tired enough with the web being JavaScript-dominated for a long time that the rise of options like TypeScript, ReasonML, Elm, etc. (in industry) felt like a breath of fresh air to me.
WASM would be a much more suitable platform for Flutter since it's more portable (works on the web) and better matches Flutter internals (C++ can be compiled to LLVM and through that to WASM).
Not to mention that Google might be a bit sensitive to anything JVM / Oracle right now, given the lawsuit they lost.
I have been a full time Android dev for past 5 years, and have really grown to dislike the work. UI development takes up so much of my time. And usually the fix ends up being some small attribute that only has an effect when combining X and Y UI parts.
Had the chance to do some Flutter work, and really enjoyed it. Could knock out the UI and later modify it with ease. Spent most of my time focusing on app logic, and not tons of UI work.
Happy Flutter is spreading elsewhere, I will try this out and spend some time looking into Hummingbird also.
Are you using the ConstraintLayout? Previously, I would have agreed with you. But, I've found the ConstraintLayout to be pretty fantastic when developing UI's.
I just checked out a couple of Flutter’s showcase apps on iOS. The scrolling in the Hamilton app was atrociously stuttery, just really broken. This is on an iPhone X. Then I opened it again and it was fine. Seems like it was doing some initialization work that was blocking the main thread. Not sure if it’s Flutter’s fault but I never see broken scrolling like that on native apps.
The other app I tried was some journaling app. Both of them used unconventional UI. Are there any good examples of native performing and looking Flutter apps?
EDIT: Apparently somebody downvoted this? What’s up with that?
We've done significant work on that particular issue in the past few months (primarily, caching compiled skia shaders). The issue wasn't iOS specific. If you have cases that are still problematic on the master channel (on iOS or elsewhere) please please please file a new bug with a test case so we can track down the issue.
I'm currently writing a test app that exhibits the issue on Flutter master, will get it to you guys shortly. This is already stated in the GitHub thread, but stuttering on open/app switch tends to happen with anything more complicated than a ListView with simple text content.
We logged a similar issue -- iOS keyboard is severely laggy since v1.3.14:
https://github.com/flutter/flutter/issues/31138
My guess is it's related to the other more general jank as well, but a severe example.
Ah, thanks for the links. So jitteriness is a known issue.
FWIW I doubt it’s that Google doesn’t care about iOS.. it’s kind of the raison d’être for Flutter, no? Probably has more to do with it being really hard to reinvent a drawing layer from scratch on an OS you don’t control or whatever it is they’re doing. They could be trying their best and just be hitting a wall. Often happens with cross platform frameworks.
Non-charitably, Google probably has an interest in not prioritizing iOS.
Realistically, I'd imagine that Google prioritizes less there because a lot of preference for iOS dev is to just go full native. I do wonder how much Flutter is used by Google for iOS apps though then.
Full disclosure: I'm a Flutter team member who has focused specifically on iOS development.
There are a number of us dedicated to this on the team internally at Google. It's definitely a priority. Each platform has its own challenges though, and there's a very wide variety of issues that can arise that are platform specific. The more feedback we can get about what people want to do that isn't working, the more we can address it :)
Then they can stop claiming real cross platform solution. To be hones this is exactly the reason I am sceptical to use any of their projects. I never seen something like that from other companies who produce engineering tools like Flutter for example.
Thank you, this is pretty, but it is also non-standard UI so it's not what I mean by a "native looking" app. I understand Flutter has some native-looking widgets so I'm curious how they work out in practice.
Every so often for the past several years I'll go evaluate options for cross-platform desktop app development and I always come back with an enormous handful of options and all of which fall short on some measure.
I would really think that this "problem" would have a great solution by now. But I think most of the developer attention is on web for obvious reasons (more ease, more conducive to mistakes/novices/etc).
However I think there should be way more desktop apps. I hate using services and having my data all on some remote service w/ little options for privacy and safety/backup, etc. I also like the general speed of desktop apps (though I know the web is trying to pull on more desktop/os resources) and I like the way desktop apps can interact with the host OS (creative windowing/sidebar/docking/etc and utilization of system tray/menu bar/etc.)
I would much rather see my needs addressed by suites of standalone/private desktop apps than by a bunch of URLs and Saas's.
Interestingly, the HN zeitgeist seems to recently be turning its awares back to this topic (it seesm to me from recent HN threads). Is it? And if so, I wonder why? What's in the air now?
There's aspects of Flutter I don't like, but the cross-platform seems to strike a fairly compelling middle ground vs. what you've probably had experience with. It's almost like the C approach. There's the common stuff abstracted that's not particularly platform-specific (here's how you draw a red box, here's how you load a jpeg, etc...), and then all the really platform-specific things, like theming, is handled by just a handful of basically #ifdefs
So much so that you literally have platform-specific widget implementations to go along with the platform-specific themes. Which sounds worse than it is, but defining new widgets is super easy.
Not a write-once-run-everywhere but more like a write-1.2x-to-support-2-platforms type of thing. It risks being uncanny-valley at times, and implementation can drift from platform needing re-alignment, but it should let you do those really platform-specific stuff in sane enough ways.
I'm the PM for the Flutter developer experience. I'm currently digging into the next steps for our desktop experiment with Flutter and I'm very interested to hear how your xplat desktop app dev options fall short. What do you need from an xplay desktop app dev framework and toolchain?
- a ui programming model that is thoroughly thought-through. to be honest i think javafx fits this bill, it took long- hard-learned lessons from Swing but rebuilt things up from that learning. the scene graph api model imo is so ideal and then the way they build the widget/controls on top of that...creates a lot of flexibility yet remains simple
- actually works reliably (ie, is production-quality) on all platforms
* this is probably where 100s of these xplat desktop frameworks fall down. many are just so far from reliability
- full support for building binaries (+ installers would make you really stand out! +, heck, streamlined app store deployment would be wow) for all major systems (mac, win, linux) ... ideally producing these all from one same build machine/os
- solid set of optimized core widgets (all the stuff you'd expect in any widget toolkit...and performant...eg, the table widget should be optimized for unlimited records etc.. again javafx seemed to get it right w/ their tableview)
- polyglot (again java/fx ... you can build in clojure, jruby, kotlin, etc etc)
Where I depart from perhaps the majority is that I don't care about native LaF... and I suspect striving for native LaF is sort of at odds anyway with the xplat goal. So in my mind, I'm okay w/ non-native.. of course I do want ability to pixel push and have things look nice and I want things generally fast. (javafx again is doing something cool w/ its ability to style things in its 'css' support...)
I can think of a lot of apps that don't use the native OS LaF and yet look great.. Spotify, for one, and there are many productivity-oriented apps in this list... Another.. I use Jetbrains IDE for developing in Java, Clojure, Ruby, Elm, Javascript, etc... and that app - afaik - is Swing-based and yet they have made a killer user-experience across the board imo..
Really interesting comment! I tried to use JavaFX a while back and was really put off by it (whereas I've had good experiences in Swing).
Some issues (it's been some time so memory is a bit hazy):
- Lack of good documentation, both official and alternative (ultimately found a good reference book).
- Lack of customization on some widget, even compared to Swing (remember being really disappointed at how hard it was to modify the built-in tab-view).
- I really don't like the built not-quite CSS. Remember having trouble finding documentation for it. Also why a different language and not just code — like for the rest.
- Was really put off by some parts of the API design, even compared to Swing. Something that I remember is that there was a half-baked support for "theming" that isn't really usable nor used.
- This is much more debatable, and I won't wish ill on people who dismiss it, but it feels like it's completely out of the zeitgeist. I don't know if people doing unsexy jobs use JavaFX, but very people talk/write about it over the internet. Compared to Swing, the dearth of resources is staggering. It also created a lot of FUD that you can easily find if you google a bit. Don't use Swing cause it might be deprecated in favor of JavaFX (unlikely?). JavaFX hasn't really been updated nor hyped since Oracle took over, it's just rotting. IIRC it's not even bundled with the VM anymore, which is more headaches for distribution.
The closest comparison I have to Flutter is Adobe AIR which I use extensively (scoff all you want).
The premise is very similar (non-native UI on OpenGL/DirectX surface, AOT compiled language, C++ based runtime, near native performance) I would go so far to say Flutter is heavily based on AIR.
When I ran the current Flutter-desktop demo it appeared to have the stability and feature-set of AIR 1.0 beta which was released in 2008 (It is now v32.0 as of 2019).
It's a great jumping off point but I don't necessarily understand the hype when I am seeing something I saw 11 years ago.
Features I would expect Flutter Desktop to provide to match AIR.
- Hardware accelerated Video
For multimedia apps
- WebView
This may seem counter-intuitive but a chromium/webkit based webview component is a must.
- read/write/delete access to files in the app's sandbox.
- saveAs, filePicker dialogues
- Multi window support
- Toast/Notification Support
- Extensibility
AIR has a C lib and header for passing vars between the AIR context and the native plugin. This means the conversion has limited overhead. We can pass bytearrays, bitmapdata and even call methods directly on the AIR vars from within native code.
Being limited to using JSON across the bridge is not ideal, as there is conversion overhead and also you lose type safety.
I have added bindings for Swift, C#, Kotlin in recent years for building plugins with these more modern languages. It also allows building extensions in .NET and not being restricted to C.
I have heard variations of that most of my life. I always wanted to get into the Unix shell business on the coast so that the following would be true: "Chris Sells sells C-shells by the sea shore." Alas, another dream unrealized...
Cross platform desktop app development will always fall short.
Not all platforms have the same user interfaces/paradigms. What is the Windows equivalent of the OSX dock? What is Linux's equivalent?
Most cross platform frameworks solve that kind of problem by letting you write platform specific code. The problem there of course is that you're just writing multiple apps again, often in a non-native or at least second class, language. (By second class I mean it's not what the OS authors intended their apps to be written in.)
> Most cross platform frameworks solve that kind of problem by letting you write platform specific code. The problem there of course is that you're just writing multiple apps again, often in a non-native or at least second class, language.
Isn't this throwing the baby out with the bathwater? Only a very small portion of your code should be platform-specific (10-20%?), which is still a huge win over maintaining multiple native apps. Of course, in practice, there are many other disadvantages of using cross-platform frameworks that may outweigh the benefits, such as the inevitable impedance mismatch between languages, APIs, concepts, etc.
Lazy cross platform development will always fall: no solution will do the work of having to think of how your software will look on other platforms. With a bit of work, though, you can minimize this duplicate effort.
I think the solution is to split in 2: A UI back-end with logic, layout, etc and a UI front-end renders in each UI native toolkit.
So when write Button(title="hello") is NOT a widget, but a struct with data. It must be pushed to UI.Coccoa.render(button) to show up. But not only that, is possible to say:
Form
when(toolkit=UIKit) Field(UILabel="UserName", UiTextBox(PlaceHolder="Write your user")
Field(Label="UserName", Edit(PlaceHolder="Write your user")
Copied from another comment on of mine so you see it:
ReactXP (https://microsoft.github.io/reactxp/) uses TypeScript and targets mobile and desktop platforms using native controls, not emulated controls.
While Flutter doesn't work yet for desktop or web, ReactXP already works for these environments, and is used in the new Skype for Web.
Windows support is done and targets W10, Xbox, and Windows Mixed Reality. MacOS support is experimental, but mostly working. Linux currently needs an Electron wrapper.
> I hate using services and having my data all on some remote service w/ little options for privacy and safety/backup
Ah, but you see, the current crop of developers loves these things because you can make a lot of money when people have to pay you rent. They might talk a good game about open source and empowerment, but they're behavior says they'd rather make money.
Have you tried Rubymotion? It currently deploys to iOS, Android and OSX, but Amir, the new leader, is quite passionate about expanding and just deployed a popular Rubymotion app on the Nintendo Switch, so stay tuned for more platforms!
This is exactly what I'm talking about. There are SOOOO many options and all of them fall short. This one falls short in the extreme. I.e, no Windows support & it seems mobile-focused not desktop-focused.
Not trying to be harsh and I bet this project has cool plans.
But what worries me is that there are 100s of options in this space and _all_ of them are short.
Why can't the passionate community rally behind one effort, and fully solve this problem?
A solution doesn't seem to need to be programming language-specific, either, so that doesn't seem to be a good reason to keep 'forking' this problem.
great news :) Flutter/Dart was a joy for me to code in. As a backend engineer I could pretty much skip all nonsense and just build a simple Android/iOS app in a matter of days. I didn't even have to use Android Studio, built and deploy my app straight from the terminal via CLI.
I have looked at multiple different solutions how to hack flutter to run on desktop but didn't want to invest my time in them as they would probably crash in weird scenarios.
This will make things so much easier! modern tooling + no electron = win for both developers and users.
That's incredible. Flutter seems to have a modern API, a great, customizable look, and a growing ecosystem. My only concern is, what are the executable sizes and performance like?
I want to link to Revery - a native, cross-platform GUI library written in Reason/OCaml.
It brings React's view=function(state) model to native applications, along with CSS box model and Flexbox. It has the developer ergonomics of Electron, but without the need for its heavy runtime.
It is still under development and I'm looking forward to playing with it next time I try writing a GUI app.
"Native" is actually overloaded in the era of hybrid web apps - there are two pivots:
- Native code - does the GUI framework compile to machine code?
- Native widgets - does the GUI framework use platform widgets, or a platform agnostic layer?
In the context of Revery, we used "native" to mean "native code", ie, "compiles to machine code" - and further clarify in the README. It's important for us to make this differentiation - because often people look at the framework and assume its JavaScript.
Do you have a suggestion on how to clarify this?
Note that, if you're interested in using the platform UI - there's a project called Brisk (https://github.com/briskml/brisk) that is very similar to Revery, but uses platform UI frameworks (Cocoa/Win32/etc).
I dunno. Compiled -vs- Interpreted, and Desktop -vs- Browser seem like classic terms that gives 4 quadrants.
It's probably just Mac-heads that are particularly bothered by this topic, given that MS seems to create and sunset their native GUI frameworks fairly regular, and Linux has no single officially blessed one that everyone is attached to.
For native, there is Brisk[0], "A cross-platform set of tools for building native UIs with Reason/OCaml.
The goal of the project is to allow developers efficiently create fast, native apps for all major platforms. It's the best of both worlds: speed and portability, simplicity and great APIs."
> Revery is like flutter in that it does not use native widgets. This means more work for us, but also that we have more predictable functionality cross-platform!
Very excited, this is the fast & productive non-electron native Desktop Apps UI I've been waiting for.
Most people use Electron because most native GUI's suck as they're antiquated APIs are unproductive with slow dev/iteration times. Flutter lets you build beautiful Material Apps using a refreshingly modern Reactive UI with built-in hot reloading.
Dart is like a cleaner Typed version of JavaScript, a bit more static and restrictive in someways but still really easy to pick up and learn if you have any 'C-like' language experience.
This is the kind of thing that leads to an "uncanny valley" app, where things feel slightly off, or they look good until the OS changes something and Flutter doesn't keep up.
That's why ReactNative is my preference. There are forks of it that target Windows and MacOS using their native controls. Microsoft maintains the Windows ReactNative fork (https://github.com/Microsoft/react-native-windows) and they wrap React, ReactNative, and the desktop forks in their ReactXP project.
I don't trust Google to emulate a perfect UI among all platforms. I feel like they're generating too big of a workload for no reason, it's a big red flag. I think eventually they'll give up on emulating native controls and choose a unified appearance for all platforms (forcing Material design for everyone) as well as giving the option to customize. I think their endgame is to push Flutter as much as possible so they have Fuchsia developers, then let the other target platforms go unmaintained. Their language, their OS, their devices.
matters a lot more than getting inconsistent rendering and behavior that you have to continually test cross platform when trying to wrap native controls behind a leaky abstraction.
Generally, it matters more than you’d think. People can get subconsciously used to things (often in ways they cannot vocalize) and may feel that your software is “off”.
We finally have an answer to "how do I write GUI apps that work on all three major desktop OSes, both major mobile OSes and the web?" that isn't just run a web browser instance per application. Nothing wrong with Javascript these days, but it's hard to get consistency and the performance just isn't there. Something that compiles AOT and renders its own controls directly through OpenGL sounds great. Technically Qt can do this, but then there's licensing and C++ and it's all just kind of heavy development-wise.
Shameless self-promotion: There's also https://hover.build, which builds a Go binary that runs the flutter engine to run your app. Can be used to easily deploy a Flutter app on desktop, and allows for cross platform plugins written in Go. It works, but is in early release. It is based on https://github.com/go-flutter-desktop/go-flutter
I tried this a couple of weeks ago, and to my surprise, it actually delivered! Except that the resulting apps didn't render quite correctly yet, so in the end I couldn't justify using it, yet.
<rant>
Hover probably suits my needs, but I think the Flutter engine could be separate from the app, on the desktop, as the Dart jitted VM seems to have enough performance to do so. That could fully remove the need for a toolchain for the majority of apps. Just feed it Dart, in source form.
In the case of Go, a library could enable communication with such a Flutter VM through channels. The resulting executable could be much simpler, and would merely focus on extending the VM with platform features. Concretely, it shouldn't be necessary to recompile the Flutter engine, just to add serial port access, for example. Likewise, the Flutter engine could be upgraded by simply replacing the binary.
The thing is, your language of choice, any, could be used to extend such an engine. Fundamentally I don't believe in monolithic apps which compile in the kitchen sink, as they don't allow me to use the best language for the task. Most languages try to be everything to everybody. Why not communicate better, between processes? Some of these processes may run on the other side of the world. That kind of stuff should be easy, so no DLL's please, instead a kind of broker.
</rant>
Cool! Does flutter do web apps/frontends yet? I think when/if it does it’ll be really interesting for small tech teams in non-tech businesses.
I work in a municipality and we simply can’t keep up with different frontend stacks for web, mobile and desktops or even the pace of which modern JS framework versions become obsolete.
I think this is the real killer feature of Flutter, and something I'm waiting for as well. They are implementing it with their Project Hummingbird, but the process is a bit opaque at the moment.
> Work is ongoing to extend Flutter to support desktop as a target environment, allowing developers to create macOS, Windows, and Linux applications with Flutter.
OMG I wait for this so much... Finally a modern, high-level, really cross-platform JavaScript-free GUI framework...
Most users prefer an app over the web on mobile. If installing apps on desktop can become as painless as on mobile, perhaps users will also prefer an app over the web on desktop? Maybe then we can let browsers just render documents and stop trying to shoehorn apps into HTML/CSS/DOM.
Currently using dart and flutter full time, some c++ background.
Can say that the docs are really well written and an addition to have native desktop is just another plus. Dart itself is very familiar to c++ and feels quite natural.
Is it possible to work with Flutter using Typescript, or is it Dart only?
It really feels like Typescript won the war to be something of a JS replacement a long time ago - I like the look of Flutter, but I really don't want to learn another language that I won't use for anything else.
BTW, I realise Dart is likely similar to Typescript in many respects, and I wouldn't expect a big learning curve - but I already have enough languages under my belt and don't want anything else to add to the occasional syntax confusion I get.
> Is it possible to work with Flutter using Typescript, or is it Dart only?
You might be thinking that Flutter underneath is using JavaScript - to which Dart compiles. However this is not how Flutter works, there is no JavaScript involved anywhere in the stack.
Dart is its own language - and it can run natively, unlike TypeScript - which is just a type system over JavaScript and needs to be compiled to JavaScript to actually run.
There is bytecode, but the story here is kinda complicated - there are actually 2 different versions: one is called DBC and is used during development of Flutter applications on iOS, there is another called KBC - that one is more like a classical bytecode, it is currently in development.
> And is there a place where more details are available?
DBC is an interesting beast, the way it was implemented in Dart VM was not like a normal interpreter (e.g. you interpret and then you tier up into JIT which generates native code), but kinda like a pseudoarchitecture. DBC tiers up into... itself. An optimizing JIT in DBC mode would generate optimized DBC bytecodes, not native code. This all kinda makes sense in the environment for which DBC was created - iOS, where you can't JIT. However in environment where you can generate native code this makes no sense - and even prevents you from reaching peak performance.
KBC is an experiment in this space where you have a more classical interpreter which tiers up into native JIT. In KBC mode bytecodes are also given to VM rather than generated internally inside the VM like DBC does.
Theoretically KBC should have better startup latency than just JIT (because you can start executing code immediately, rather than spending time to generate native code) and peak performance that matches JITs - because it tiers up into JIT.
I found flutter very fascinating. I recently start a small side-project with a friend and it's truly fun. Dart is pretty smooth most of the time (except the TypeSystem which is a bit weird, IMHO). This idea of `Flutter all the things` anyway is pretty ambitious even for Google, but for some specific use case might be a good solution especially for kickstarting prototypes on different platforms in order to validate the market as fast as possible. This are my 2 cents.
You can do either. You can compile a snapshot and run that on the JIT VM. This basically gives you faster startup because it doesn't have to do all the source parsing, resolution, type-checking, etc. but gives you the general runtime performance of a JIT VM (think V8 or the JVM).
Or you can AoT compile your app all the way to native code. It's similar to how a shipped Go or OCaml works where it compiles your code and the language's runtime together into a single executable.
I was more referring what Flutter would do out of the box for desktop, but yeah, the question didn't mention Flutter.
By the way, is there a good performance breakdown between Dart's AOT vs JIT? I've read some tweets/comments that JIT is still generally faster. Not including warm-up of course.
I don't know of any good canonical references. The perf story is always changing since a lot of this back-end work is pretty new. Also, the type system changes in 2.0 are still fairly new and I'm not sure how much the back-ends take advantage of those types yet.
I'm going to wait a few years for this to settle down in case Google drops it like other projects, its web-component polymer project which I spent some cycles on did not take off, Angular is not in good shape these days either, and the PWA... Flutter might be just another new try.
For me, React, ReactNative, Electron, even Vue, is enough for now, I can not trust Google on yet another web effort anymore, life is too short to trust a giant who behaves unpredictably sometimes.
I'm a web developer, but I would like to learn Flutter. However, I haven't found a good resource to get started with. Everything seems to assume that you're a mobile developer already, except for a few very basic tutorials, which only half-assume that.
Does anyone know of something that will take you from zero mobile knowledge to building some simple apps?
Coming from a decade of app development experience. Both iOS and android have the capability of inlining styles as well as abstracting it into reusable bits. Flutter certainly supports it very well
As another comment said calling this 'native ui' might be misleading. It's native performance, but the UI will (probably) look non-native. It's a move in the right direction, but just understand what you are getting when you sign up. I have some experience using Xamarin which is true native controls for each platform, but has other drawbacks.
While VSCode is great in a lot of ways, it does not have good performance. What is has is adequate performance and great extension support. It regularly stutters quite badly on my beefy Dell Precision when running on the integrated GPU.
I use it as my daily driver, but its performance pales in comparison to something like Sublime.
You can poke through this bug https://github.com/flutter/flutter/issues/18208 and the referenced skia bugs. There's a Metal backend in the works already, but if you really for some reason refuse to use OpenGL even though it works fine Skia's Vulkan backend works fine and MoltenVK exists now.
But deprecated just means "start moving off of this please" not "it's already broken"
Who's to say Google's plan isn't to make this become big, then purposely give iphone a shittier experience just a few ms of more jank to make android look better? Think long, long term. I wouldn't trust this.
I don't know if they'd do that but Google does treat iOS users pretty shitty. Their apps are always a decent bit behind the upgrade curve. Like they didn't support the new iPhone X display for a good few months after it was released.
It's weird how perception differs based on the platform you're on, because me as an Android user I'm often a bit annoyed that Google seems to treat iOS a bit better by either launching earlier on iOS or taking better care of the User Experience and stability.
Yes, but on a desktop, running a web app as a native application is tolerable, not great. On mobile, it's frequently a performance and battery problem and interacting with native APIs is hit or miss. This comment is similar to someone seeing the web stack used to build an application and saying "We already have something like this. It's called Win32 or Cocoa or GTK+ or Qt or writing directly to a frame buffer ..." Different technologies for customer demands, timelines, teams...
Nah. The number of issues on any project is not an indication of project quality but community activity and imagination for improvements. This is the wrong number to point to if you're trying to make this point.
Weird. Till other day the Web was the platform to rule them all. Who would do desktop apps in 2019? If you need a web page, and hybrid app is still best option.
