vially

Yes, I've been doing this on sway for a couple of months now without any issues.

This was happening in an Ionic 4 project which was already using the stock tooling of the framework (Angular CLI). But I remember it being worse in Ionic 3 with its custom tooling, so overall things do seem to be improving with time.

My findings at that time (it was a while ago) seem to match exactly the slowdowns described in this issue [1]. Just importing the IonicModule in a new Angular project (without actually using any Ionic component) made the dev server build times jump from around 200 ms to a couple of seconds. And the situation only seemed to get worse as more Ionic features were being added to the app.

Just to make it clear, I understand that this is an open-source project and I don't expect anyone to fix my issues. And I'm also very grateful to you and the Ionic team for giving us Capacitor which is such a big improvement from Cordova.

So I don't like being all negative in here. But I did encounter a fair share of issues with Ionic and I'm only sharing my experience here as just another data-point in case it helps someone make a well-informed decision.

And I have to say, the overwhelmingly positive reaction to Ionic in general did make me question my own abilities several times. Maybe I just don't "get it". I still haven't ruled that out as a possibility.

[1] - https://github.com/ionic-team/ionic-framework/issues/17902

I would not recommend Ionic. I've been using it in a medium sized app for about 3 years now and I get the feeling it's good for getting started, but once your app grows past a certain size it's starting to create more issues than it solves.

Some examples from the top of my head:

- various performance issues (e.g.: memory leaks which haven't been fixed for years [1])

- their push/pop router navigation seems like a really bad idea

- worse developer experience than using Angular directly (e.g.: last time I checked this, the save/compile/reload cycle of an Ionic project was an order of magnitude slower than the same project without Ionic)

[1] - https://github.com/ionic-team/ionic-framework/issues/19242

Spotify is using the Chromium Embedded Framework (CEF) [1] which is similar to Electron in the sense that they are both based on Chromium but it's not quite the same thing.

[1] - https://community.spotify.com/t5/Closed-Ideas/Revert-to-nati...

I don't use any of those apps so I'm not familiar with their underlying technology but it looks like they are all Electron apps.

If that's the case, then yes, screen-sharing should be much easier once they migrate to Electron 12 since they will become native Wayland apps and will be able to use the Wayland protocols for screen-sharing.

> I guess it would be nice to have Wobbly Windows

Wayfire got you covered: https://wayfire.org/

> X works perfectly for me, and there is nothing I would want it to do that it doesn't do now. Why should it change?

I'm not sure whether a program that works for you is a good indication that it no longer needs to change.

> When we have a software that works well and solves our problems, we should celebrate it, not complain it doesn't find new problems to solve.

I think anyone can agree that, at the very least, screen tearing and proper support for mixed DPI setups are problems that fall squarely in the responsibilities of X and yet it still didn't manage to solve them after so many years.

So it's hardly the case that X is just so good that users nowadays have to try really hard to find new problems for it to solve.

> so actual Flutter is just Google NIH syndrome

I'm not sure I agree with this assessment but even if this were true I still think it's a good thing that we have an open-source alternative to Qt considering the recent drama about its licensing [1].

[1] https://mail.kde.org/pipermail/kde-community/2020q2/006098.h...

This is one I follow related to adding multi-window support to Flutter: https://flutter.dev/go/desktop-multi-window-support

I also found some of the chromium design docs quite interesting: https://www.chromium.org/developers/design-documents

> [...] why they don't allow slower, less power efficient, less secure and less private web engines available on iOS

Do you have a source that shows how chromium/edge/firefox/etc are inferior to safari in this regard?

The input redirection pipe is not necessary either:

  jq . json | less

> [...] is not a bad thing for your clients

Except when you have to pass some of the 30% Apple fee on to your clients.

I'm currently working on a Wayland Flutter embedder for Linux (the existing GLFW embedder is using X11 so desktop Flutter apps are running through XWayland in Wayland environments).

Thanks for these great articles. I love your blog and your work on druid. Keep them coming!

This is a space I'm very interested in. Having a high-quality, reactive UI toolkit for developing native desktop apps might make it easier for web developers accustomed to these reactive frameworks (e.g.: React) to develop native apps (without having to resort to hacks like Electron).

Linux in particular could really use more developers developing native desktop apps and I feel the current UI toolkits (QT/QML, GTK) and in particular their language choice (C++, but I'm aware there are bindings for other languages) are not appealing enough to the casual web developer. It could be argued that Rust might not be the answer for these developers anyway, but one can still hope.

Thanks a lot for taking the time to provide some feedback.

> 1. Not sure about that, but the default is that it pushes to the stack. Isn't this what anyone would expect?

If you assume the stacked navigation model is the right model, then yes, I guess pushing pages to the stack is a good default behavior.

However, I'm not completely sold on the stacked navigation concept in general. Let's take GitHub as an example and try to think how the default Ionic behavior of pushing pages on the stack would apply there.

1. You navigate to the homepage. Stack: [homepage] 2. You click on a link to open a repository. Stack: [homepage, repository] 3. You click on the issues tab of that repository. Stack: [homepage, repository, issues] 4. You open a particular issue. Stack: [homepage, repository, issues, issue#1]

Obviously this is not very scalable as you now already have 4 full-blown pages in your stack that are eating away resources (DOM nodes, more change detection computation, etc). So in order to fix it, you now need to decide which pages should be pushed on the stack and which ones are replacing old ones. And then, as your app grows, you also start hitting some edge cases in the Ionic stacked navigation implementation (e.g.: https://github.com/ionic-team/ionic/issues/18197). And at that point you start questioning whether this whole stacked navigation is actually worth it.

> 2. Are you sure that Chrome records the number of currently existing nodes or the number of nodes created?

I've been using the Chrome DOM Nodes counter in the past and in my experience it's been 100% reliable (at least for the use-case that I mentioned in that issue). What I did notice is that the baseline count fluctuates (e.g.: refreshing the same HTML page sometimes gives you a different _baseline_ counter after each refresh; not sure what that's about). But the difference between the initial baseline count and the resulting count always reflects the DOM manipulations performed, so I think it's a good tool for identifying these kind of leaks. However, you might want to spam the "Collect garbage" button (found in the Performance tab) after performing these kind of tests as there's a chance the DOM node was correctly destroyed but it just wasn't collected by the garbage collector (and that's why it's still reported in the DOM Nodes count).

> 3. I use Canvas inside an Ionic app. If you render your Canvas at the right point of your component lifecycle, it works just fine.

Completely agree. Once you find the right hook everything seems to work as expected. However, I feel like Ionic doesn't provide enough hooks for this, and the introduction of Stencil in Ionic 4 only made things worse (actually this started affecting us only after migrating to Ionic 4).

To give you an example, let's say you have this DOM structure:

    <ion-content>
        <ion-grid>
            <ion-row>
                <ion-col>
                    <ion-card>
                        <my-canvas-component />
                    </ion-card>
                </ion-col>
            </ion-row>
        </ion-grid>
    </ion-content>

In one particular instance we noticed that the <my-canvas-component> had to wait for the `<ion-col>` component to be ready (using the barely documented componentOnReady stencil method) before its size was "stable". Which makes it almost impossible to create a reusable `<my-canvas-component>` that works everywhere, because it can't know in advance in which DOM tree it's going to be placed.

> 4. Haven't observed this.

The easiest way to test this is to start a plain Angular project and an Ionic project and do a edit/build/reload cycle. Obviously, it depends on hardware and you need to try match the dependencies as closely as possible, but what I noticed is that the plain Angular project is noticeably faster.

> Instead of using Ionic 4 (I have an app made with Ionic 3), I switched to Stencil with @ionic/core. This gives me very fine-grained control over everything.

That's interesting, thanks. We may give that a try.

I haven't used Ionic React, so I can't comment on that, but I've been working on a medium sized Ionic Angular app and I have mixed feelings about it (to the point where if I were to start a new project today I wouldn't use it).

Some random issues that come to mind:

1. Stacked (push/pop navigation)

This was really bad in Ionic 3 where you didn't actually have a proper router, so this was the only way you could navigate in an app, but it's still an issue in Ionic 4. Basically you can have multiple (stacked) pages in the DOM at the same time which negatively impacts performance (e.g.: more DOM nodes, more computation during change detection cycles, etc). Also, extra cognitive load because you now have to decide for each link whether you want it to push a new page onto the stack, pop it from the stack or replace the root page.

2. Performance problems and/or memory leaks

Simply navigating in an Ionic app is enough to create memory leaks: https://github.com/ionic-team/ionic/issues/19242

3. Trying to use canvas (or size sensitive components) inside an Ionic app

- https://github.com/ionic-team/ionic/issues/17920 - https://github.com/ionic-team/ionic/issues/17940

4. Slower developement edit/build/reload cycle

I don't have the exact numbers right now but last time I checked, just importing the `IonicModule` into an Angular app module (without using any actual Ionic components) resulted in an order of magnitude slower edit/build/reload cycle (I think plain Angular was something like 100-200 ms; after importing `IonicModule` that jumped to 1-2 seconds; not that bad but significant enough that you could actually feel it).

Given the overwhelmingly positive community feedback I hear about Ionic in general, I think there's a good chance I may be doing something wrong, in which case I'd love if someone could point it out.

That being said, huge thanks to the Ionic team for giving us Capacitor. My experience from migrating the same app from Cordova to Capacitor was really positive. I feel like it brings a breath of fresh air to hybrid app development.

This is the biggest issue for me as well, but I've mostly learnt to live with it by not scaling the HiDPI display in sway. What I do instead is scale the XWayland applications when possible.

For me the only XWayland apps that I want to use on the HiDPI display are Chromium and VSCode and both of them have options for scaling (e.g.: "--force-device-scale-factor=2" for Chromium; "window.zoomLevel" for VSCode).

This is what the flutter-desktop-embedding [0] project is trying to address.

[0] https://github.com/google/flutter-desktop-embedding

Congrats for the release but they really need to fix the mobile notifications when using the desktop client [1]

[1] - https://github.com/telegramdesktop/tdesktop/issues/277

I don't know if there is any shared host cheaper than that (I suppose there are but I'm too lazy to check right now), but sometimes the appeal in using a shared host is in some of their features which you don't get in a VPS (e.g.: cpanel).

That still seems pretty expensive. In Romania you get the same service (1 Gbps with IPv4/6) for less than $12 (45 RON).

It seems these images use systemd (a nice departure from the init.d scripts used in the previous container_vms images [1]).

[1] - https://cloud.google.com/compute/docs/containers/container_v...

I don't think it will. Even though most providers offer IPv6 addresses in /64 blocks, the services you might want to scrape will consider any request coming from the same /64 IPv6 block as coming from the same user.

I've been waiting for Fabric to make the migration to Python 3. Fortunately I no longer use Python that much (I jumped on the hype train to Go and I've been very satisfied with it) so I no longer need Fabric nowadays.

I've just checked the output of "bat --help" and currently it doesn't seem to have an option for that.

There's also https://github.com/astaxie/bat which is heavily inspired by httpie but is written in Go so it's distributed as a single static binary.

I can't seem to find a changelog but I suppose this release should include vi-mode? Can't wait to try it out.

What do you think about pass [1]?

[1] - http://www.passwordstore.org/

Read the source code: https://github.com/hashicorp/vault

I love httpie as well but recently I switched to bat [0] which offers pretty much the same thing but is written in Go so is deployed as a single binary.

[0] - https://github.com/astaxie/bat