Does this method let you move instances “under the hood”?

yes

Yes, Flutter is “sponsored” by other money making teams inside Google. It is why resources have been spent on Flutter for Web, which no one asked for - the Ads team essentially bought the feature for their usage. This was also how React Native got its start in Facebook.

So my read of Flutter is it’s a way for talent to “ship and get promoted” inside Google or to support other Google product teams. Everyone else is a secondary priority.

> It is why resources have been spent on Flutter for Web, which no one asked for - the Ads team essentially bought the feature for their usage.

“the Ads team at Google” is a very strange thing to treat as equivalent to “no one”.

> DO App platform

Can you expand this reference please, Google/Github search didn't give me any obvious results.

DO == Digital Ocean

Very useful in my opinion, given the decline of Google

Edit: Referring to ways of discovering non-mainstream content

Atlassian's Confluence (Cloud). A showcase for the decline in web based software forced by the move to make everything a SPA. A terrible new editor experience. Slow JavaScript heavy page loads. No persisted markup editing.

Yes, a common reaction, until newbies (like myself) find configurations like Doom Emacs and Spacemacs and come to realize the opposite. For myself it's only missing a slightly better "rending experience" like VSCode.

I love Spacemacs but due to varying configurations per build on different OS' Emacs either doesnt work at all OOTB with Spacemacs for me, or it works just enough to show up broken. Without cross-platform consistency I'm better off using Neovim + Spacevim which sometimes fails on me due to fonts, but its less broken.

I tried both of them and just gave up. Emacs for me has nothing on a modern IDE and a light weight vim config for file editing. When it comes to reading email, browsers are far better option.

Looks visually pleasing, but I found their more complex diagrams harder to read compared with something more plain.

Some history and downsides to the `io` domain: https://www.thewebmaster.com/hosting/2016/feb/27/io-tld-top-...

I could see both working well when depending on the situation and audience. In my role I'm seeing a need for plain diagrams that need to be kept up-to-date and a "pretty" diagram for showing the bosses for 30 seconds in presentations.

I've been looking at draw.io and PlantUML - what has worked well for others? draw.io is much easier to get into, but I can see declarative diagrams making maintenance easier for long-lived docs.

Being a person who doesn't typically want to draw diagrams, I opted to go with draw.io as it looked very simple and easy. However, I was nudged to try PlantUML and to my surprise it was a lot simpler and faster to create diagrams. A point which you mentioned is maintaining the diagrams for long-term. We have a docs folder in our repository which includes all our PlantUML. It's quite easy to pick up as a language, and because it generates the diagrams for you, you don't waste minutes fiddling with getting the arrows all matched up. I would definitely give it a try - makes life so much easier!

Plus, there is a VS Code extension for it as well, which auto generates the diagrams when you save.

This [1] is the extension in question. I combine it with the extension template [2] for the C4 model [3] for easy architecture diagrams.

[1] https://marketplace.visualstudio.com/items?itemName=jebbs.pl...

[2] https://github.com/RicardoNiepel/C4-PlantUML

[3] https://c4model.com/

Great to hear your experiences. I've played with the VS Code extension and even run PlantUML server locally in Docker which worked very well.

Do you create actual UML diagrams or just use the shapes and constructs available in PlantUML to create a more ad-hoc diagrams?

> waste minutes fiddling with getting the arrows all matched up

I can resonate with this!

I prefer PlantUML when possible as it allows me to version control my diagrams effectively.

However sometimes PlantUML does not lay things out optimally (for a person) and the layout can only be tweaked so much.

That being said, for most of my purposes non-optimally laid out PlantUML diagrams were effective enough for the communication I needed to get through.

After having used both Draw.io and PlantUML, I prefer the latter. Far easier to get consistent drawings from the whole team without fiddling. And updating the drawings later is also easier because the language is much better than Draw.io's XML.