261–270 of 322 posts
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?
Earlier quoted context omitted.
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.
> Qt? Proprietary Trolltech tech. ... is this a comment from 1997 ? Qt is licensed under both GPLv3 and LGPLv3 - and Trolltech as a company hasn't existed for more than a decade...
And trolltech is very alive and publicly traded in fact. It has just been renamed to Qt company: https://en.wikipedia.org/wiki/The_Qt_Company
Earlier quoted context omitted.
15 years - so only four years less than MS-DOS ('81 - 2000) by which point it was considered hairy and terrible? I'm no big fan of Google, but 15 years is plenty long enough. And really, Android is definitely struggling and showing its age by this point.
There is no sense in which MS-DOS died in 2000.
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.
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). Ho…
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? Chris Sells csells@google.com
My (perhaps idiosyncratic?) priorities in order:
- 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..
I guess I just talked myself in to using JavaFX
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.
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…
Can you imagine trying to explain to a developer in 1995 what you need to use to produce an app feature equiv in 2019
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
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.
Earlier quoted context omitted.
Context: I was a Qt developer in a past life. The alternatives for cross-platform GUI are 1. Electron 2. Frameworks like C++/Qt C/Gtk 3. Bindings to (2) 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…
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.
Earlier quoted context omitted.
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). https://github.com/dart-lang/language/issues
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+…
Earlier quoted context omitted.
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.
What's stopping you from forking and making changes you want? Literally nothing
Forks are nice for small patches or development teams with a plan, no one outside Google cares enough about Dart fwik.
Earlier quoted context omitted.
> 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. They also used to use GWT, did that hold on?
It did for nearly a dozen years.