Googles new app sdk flutter

Hardware Librem 5
1

I recently found Flutter which is done by Google. For me it boils down to:

  • Incredible simplified Android app development.
  • Compiles apps for IOS too

They go back to have everything in code (Dart designed by Google as well). So there arent separate xml files for layout anymore, no incredible complex state machines and weird events an app has to react on.

Nice to see how simplified the whole app-development can get. I have to dive deeper into it but as a gui development platform it seems to be quite nice (i’m not a google fanboy, just looking at others ideas :wink: ).

Maybe one should get some ideas from that thing to make gui-development for Librem5 simple too?

3 Likes
2

There is one platform available with tons of great options for front end development already… It’s the Web, and it would attract so much more developers than Gnome and KDE.

Not focusing on providing a great integration of web content would be a major mistake for the developer adoption of the Librem 5.

4 Likes
3

There is one platform available with tons of great options for front end development already… It’s the Web, and it would attract so much more developers than Gnome and KDE.

Are you referring to something like Javascript as an option? Since that would require the integration of a Javascript engine and other parts into the DE (read: an entire browser). The DE shouldn’t have to integrate such things because… it’s a DE, not a web browser. The DE shouldn’t be able to access the internet. The DE shouldn’t be able to get the location of the current device because a bug in the browser allows it to give Javascript to the DE. The DE shouldn’t be able to run Javascript if it’s given some, simply because it is anything but a platform for executing code.

By implementing the features of the ‘modern web’, you are in the same way implementing all of the downsides (Javascript drive by downloads, malicious code being run by the user because it is loaded, 20+ scripts being loaded to give people targeted ads, persistent cookies, etc.).

From a security standpoint, the web sucks. Why would you want to implement it into your desktop environment?

(There are DEs that are built upon Javascript already, like JADE. If you want to use Javascript, use it, just don’t implement it into the largest desktop environments used by GNU/Linux distros today.)

4

You are entitled to your opinion, but here are a few facts:

  • Yes, you can build a full OS UI in web technologies (see Firefox OS, which didn’t fail for technical reasons, and is actually successful in the KaiOS fork).
  • When you build with a web runtime as a base, you actually have less to do than what I see being planned for the Librem 5. A web runtime is itself a compositor, you don’t need an extra one. A web runtime is a very good sandbox for running untrusted code (your remark on security is ridiculous).
  • There is a lot more manpower focused on making the web platform performant and secure than Linux desktops.
  • The homogeneity of the platform is a huge benefit, as shown by extensions that work on any web site. Try doing that with native apps.
  • Writing responsive apps is not a new, breakthrough thing on the web. The state of responsive UI with Gnome/KDE is so far behind it’s not even worth talking about it.

But even if you don’t want to go as far as building fully on a web stack, you will need a web browser. And since many useful apps/services will be available only the web, you will need a browser with proper integration in your DE: adding bookmarks to the homescreen, managing notifications, permissions, etc. It’s a large task to write a good browser, and there is nothing readily usable for mobile linux that I know of (no, Firefox or Chrome UIs are not a good fit).

I’m a happy backer of the Librem 5 because this is the right choice of hardware for privacy minded people. But the software choice is not the one that will massively attract developers, and thus users. That is likely a conscious choice from Purism and in some way it’s fine, but this will stay a niche product without a better app ecosystem.
I think it’s sad because it’s a missed opportunity to build something really groundbreaking: fixing the HW issue, and use the only viable alternative to the iOS/Android monopoly. But hey! I can actually fix the software side myself :slight_smile:

3 Likes
5

you mean the html/js/css bundle, not the web, right? i don’t like that aproach out of various reasons but i did not want to kick off a development platform discussion here.

i just wanted to show that others incredibly simplify app development. i see a movement away from complex stuff in flutter (still i dont like the fact that it introduces a new programming language).

1 Like
6

When you build with a web runtime as a base, you actually have less to do than what I see being planned for the Librem 5. A web runtime is itself a compositor, you don’t need an extra one.

There already are compositors/DEs available, KDE and XFCE, which Purism are using.

A web runtime is a very good sandbox for running untrusted code (your remark on security is ridiculous).

Something like 80% of the remote code execution CVEs for firefox are related to malicious Javascript. Here is an example:

Use-after-free vulnerability in the DOMSVGLength class in Mozilla Firefox before 49.0 and Firefox ESR 45.x before 45.4 allows remote attackers to execute arbitrary code by leveraging improper interaction between JavaScript code and an SVG document.
“execute arbitrary code by leveraging improper interaction between JavaScript code and an SVG document”
https://www.cvedetails.com/cve/CVE-2016-5281/

Why should a web browser, arguably the most used piece of software other than a TCP/IP stack be running arbitrary code from the Internet? Heck, most of the scripts being run when you go to a webpage in a vanilla browser you aren’t able to audit before you run them.

There is a lot more manpower focused on making the web platform performant and secure than Linux desktops.

Completely dependent upon what you mean by ‘Linux desktops’. See this as well as to why we should be focusing on computing the user does and not what some web server does.

The homogeneity of the platform is a huge benefit, as shown by extensions that work on any web site. Try doing that with native apps.

XOrg and by extension wayland do the same.

Writing responsive apps is not a new, breakthrough thing on the web.

Nah, it’s more of a security concern when you add javascript into the mix. Remove the browser running arbitrary code (eg. JS) and it’s not. CSS and other technologies (read: PHP) can make the page responsive by having code run on the server side (Also notice that Javascript being run by the user is bad simply because it is untrusted and does not come from a party that we can verify, where as the compositor in KDE is sort of trustworthy because it comes from a software repository).

The state of responsive UI with Gnome/KDE is so far behind it’s not even worth talking about it.

That’s a pretty good strawman.

But even if you don’t want to go as far as building fully on a web stack, you will need a web browser. And since many useful apps/services will be available only the web, you will need a browser with proper integration in your DE: adding bookmarks to the homescreen, managing notifications, permissions, etc.

I don’t see why that should be handled by the DE. If anything, the DE should be sandboxed away from most information about the user, only to serve it’s purpose – to composite windows and manage workspaces.

And since many useful apps/services will be available only the web

See this as to why that should be reduced.

1 Like
7

Not sure what you mean by “not the web”? Is that about not serving the apps from a remote server? The core stack indeed is html/js/css.

Maybe it’s simple, yes. Only building large apps will tell. I agree with you about the Dart choice, but that’s “classic Google” :slight_smile:

8

from https://puri.sm/posts/librem5-progress-report-7/ : “we set out to develop a compositor and shell based on Wlroots and Rootston.”

And you cite a CVE which is not a JS issue, but a classic UAF in the c++ code: https://bugzilla.mozilla.org/show_bug.cgi?id=1284690#c5

Next you will blame plain text input for buffer overflow bugs? :stuck_out_tongue:

Because web browsers are sandboxed runtimes. They are designed to run arbitrary code from the Internet. This is different from eg. Gnome Shell extensions or Atom ones which are dangerous.

Show me examples of how you eg. improve an app layout / readibility with that?

It is just a different trust model. Instead of trusting the KDE people, you trust people designing and implementing web browsers. You have to delegate trust, and you do that in many other aspects of your life, not just software.

Well I guess we don’t think about the same thing when we say “DE” then. To me it’s also responsible for things like managing notifications, the “system UI” even if this is done through plugins. You don’t want to have notifications from native apps appear differently from notifications from web sites, and you really don’t want web sites notifications all grouped as “browser notifications”

Just saying “don’t do that” doesn’t work. Thankfully some people are fixing that by making it easier to self host a lot of services (eg. Yunohost).

2 Likes
9

image
image2048×2636 1.37 MB
its in the campaign Page and todd clarified in the librem 5 matrix room that this means PWAs so any pwa app one cn use on librem 5 which is a good thing for thse who beed such apps

2 Likes
10

Hi maybe you would like to checkout MauiKit https://mauikit.org/ is open source and similar to flutter.

Would be interested in some thoughts.