web-server no longer available as device in Flutter web under Catalina

[emmanuelcohenlaroque]

Steps to Reproduce

This is under OS X Catalina (otherwise working under Ubuntu 20.04)

flutter run -d chrome is working (ie web conf enabled) flutter run -d web-server : web device not available flutter devices => no web device reported

Expected results:

web-server should be a device available

Actual results:

Logs

Logs

flutter devices
1 connected device:
Chrome (web) • chrome • web-javascript • Google Chrome 88.0.4324.96

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel beta, 1.25.0-8.3.pre, on Mac OS X 10.15.7 19H114 darwin-x64, locale en-GB)
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
[!] Xcode - develop for iOS and macOS
! Xcode 11.7.0 out of date (12.0.1 is recommended).
Download the latest version or update via the Mac App Store.
[✓] Chrome - develop for the web
[✓] Android Studio (version 4.1)
[✓] VS Code (version 1.52.1)
[✓] Connected device (1 available)

[ferhatb]

/cc @jonahwilliams

[jonahwilliams]

cc @timsneath

[timsneath]

Hi Emmanuel, we deliberately removed web-server as a distinct option, because we felt it was confusing to have two distinct options for web development. The intention is that you can just run flutter run -d chrome and then connect to the presented URL via any supported browser.

We considered keeping web-server as a hidden option for specialist usage scenarios, but I don't think that's currently supported. I'd love to understand more about how you've been using web-server and whether the single web target serves your needs or not.

Separately, I see that the web FAQ hasn't been updated, and we'll see about getting this fixed.

[mariamhas]

Hi Emmanuel, To add to what Tim said, we recommend using Chrome for an improved development workflow, many of our debugging tools such as Dart DevTools work best with Chrome as the device target.

Although we hide web-server as a default device option, you can still use it on the latest Flutter version 1.26.0-17.8.pre --show-webserver-device to see it as a listed device option and run your app with -d web-server .

Please try updating to the latest and let us know if those flags don't work for you.

[omatt]

Hi @mariamhas, running flutter device --show-webserver-device does show web-server in the list of devices for a moment. However, the command still doesn't make 'Web Server' in the list of available devices on the run options pulldown. Is this an expected behavior? Is the 'web-server' run option only available by running flutter run -d web-server?

I'm running on Flutter channel beta 1.26.0-17.8.pre, Android Studio 4.1.2 (stable)

[mariamhas]

Hi Omar, Could you try it on the stable channel with version 2.0?

I just tried flutter run -d web-server for my own app with intelliJ terminal, using both latest beta and stable versions, and it provided me with the local host url that I then pasted in firefox and safari to see my app.

By default we have hidden the web-server device from showing up in the IDE, its not truly a browser target and we believe developers will get a better development workflow with Chrome. (if the web-server provides something Chrome doesn't we would love to get understand the gap and file an issue to resolve it , but as of now we aren't sure what that gap is.)

I believe visual studio has a way around it to let you set up your launch config with device ID = web-server.  But again I'd recommend using Chrome as the device and if you need to see the app in other browsers, you can copy paste the local host URL shown in the Chrome browser to other browsers like Firefox/Safari.

[rmtmckenzie]

There's a few issues I see with this.

1. It is very unfriendly to anyone who doesn't want to development in Chrome. And I do realize that you're promoting Chrome as the main development platform, but I'd really hope that flutter is (eventually) stable enough in other browsers to be developed there as well... That being said I do realize that development vs production are two different things and that being stable in production would have to be the first target.

2. If you want to change any of the settings in the browser, or use browser extensions, or anything else like that, you have to do it all over again when you run the browser. And some settings like flags require a browser restart, which means you can't use them at all.

3. It opens up a whole new chrome application with its own memory footprint and process when you run it. I already have many programs vying for that memory; why should I need to have another... especially when if you close that browser, the flutter application stops running!!! So I can't just switch to another browser (even my own chrome instance) without having that additional memory/batter drain. And opening chrome from scratch each time has to have some impact on startup time for running the flutter app.

4. Because the browser is new each time you run the app, good luck with trying to use LocalStorage or anything like that between run sessions. That makes it really difficult to test things like returning to the page after having closed the browser and having it reload settings. Once again, I do realize that I could use another browser at this point, but why should I have to? It is a bad development experience, and that's one of the primary things Flutter is trying to sell developers on.

All in all, I don't see why you needed to remove an option that worked just fine and allowed for much more flexibility in terms of how I did my development. If you were to replace it with an option to select from any currently running browsers, I could see that as a viable alternative which would meet the needs I've listed here, but I could also see that being much more difficult to maintain.

[emmanuelcohenlaroque]

I both agree with Morgan and disagree with deliberately hidding this option. My understanding is that by doing so, you are clearly planning for its removal which would be a serious deal breaker. I have switched from Ionic to Flutter when it was still a beta product. I have developed numerous apps and PWA some highly complex with great UI and Flutter has proven being a good choice so far. Imagine my work environment: in an agile approach, I give access to my customers to the developing product thru an https url that is proxied to my machine. While they are testing on whichever browser and OS they need to use, I can check what happens in the log and other dev tools and modify the code on the fly. This offers a great development experience. If you remove the web server device, then my whole environment breaks and Flutter will get out of the equation. Is there any specific reason you want to hide this option? Thanks for the great work so far btw! Emmanuel

[emmanuelcohenlaroque]

@mariamhas

But again I'd recommend using Chrome as the device and if you need to see the app in other browsers, you can copy paste the local host URL shown in the Chrome browser to other browsers like Firefox/Safari.

This is not true: opening the url provided by the Chrome device option won't work on other devices or behind a proxy web server has Flutter expects a number of initialization and resources that are only available in Chrome. At least this is my experience hence the need for the web server device

[timsneath]

This is great feedback, thanks.

There are a couple of minor misconceptions I'd like to address here:

"My understanding is that by doing so, you are clearly planning for its removal which would be a serious deal breaker."

Genuinely, this is not the plan. We agree with you that there are some more advanced use cases where having this option is of great value. But it's easy to overwhelm new users with complexity, so we hide a number of options by default. We didn't like the old scenario where the web showed up as two devices and users had to figure out which one they wanted. (This isn't the only hidden command, by the way: compare the output of flutter devices --help and flutter devices --help --verbose.)

If you run flutter devices --show-web-server-device, you'll see this command just like before.

It is very unfriendly to anyone who doesn't want to development in Chrome. While... [users] are testing on whichever browser and OS they need to use, I can check what happens in the log and other dev tools and modify the code on the fly.

The command shows all supported development browsers. So for example, if you're on a Windows machine with Microsoft Edge, you'll see that instead of (or in addition to) Chrome. You shouldn't have any major problems using Safari or Firefox as clients, but since they don't have the same devtools protocol, they're not quite on the same level. But the scenario you describe should work and continue to work regardless of which web target device you choose.

[TheKLARKEN]

I appreciate that the web-server option is still available! 😁 However, there are a few issues I have come across:

• This is not documented. This option is referenced but otherwise gone. While it might still technically be available, it might as well be removed if devs cannot figure out how to enable it from the docs.
  • (I was lucky to have used this feature before--enough to know I wasn't crazy when I couldn't find it. I was on the verge of giving up after half an hour of searching, and a new user might not fare better.) 🙁
  • The only official place I could find it is in flutter devices --help --verbose, but only after seeing that in this issue thread. I have never thought of a web-server as a "device" like a browser and may never have guessed.
    • EDIT: In addition, as mentioned, this still does not allow for the usage of editor debugging tools and requires manual reloading on both the command line and then the browser.
• If users try to do the only easy alternative (launch using chrome instead of webserver), this is not a smooth experience for several reasons:
  • Yes, the port can be copied into someone's original browser session, and the app will open, but closing the original window will end debugging sessions launched by editors.
  • Yes, it is possible to launch from the command line, but then devs will lose debugging features present in the editor such as consoles, call stacks, variables, etc. 😓
  • Auto-reloading only works on the original window, not any new ones, requiring devs to move to the new window and refresh it for any changes.
    • Refreshing in VSCode causes a weird message to appear: Reload already in progress, ignoring request., nothing happens in the new window, and the restart status pop-up never goes away. 😕

All in all, I believe restoring the web-server option to its former state might be beneficial to users like me. It allows for the usage of installed extensions, locally stored data, and many other non-tooling benefits, such as being more intuitive to web developers used to other front-end frameworks like Nuxt, Angular, React, etc. I don't believe it overwhelms users. Tools overwhelm users if they're poorly designed or--more commonly--poorly documented. If users can be given options like pre-cache or symbolize front and center on flutter -h, they can handle web-server. 😁

Flutter has grown a lot this last year! 🚀 Flutter for web becoming "official" was a massive achievement. I hope to see it continue to grow, and I think this feature could help it be adopted by experienced web teams. 😁

[atrauzzi]

This really degrades the developer experience. The web-server option needs to be in this dropdown:

It's not "confusing", people will just figure out that they want one or the other. Why do we have to treat developers so poorly?

[lukepighetti]

I was having trouble with Chrome causing massive memory leaks during development due to this bug https://github.com/flutter/flutter/issues/69949

I also have issues with Flutter tooling explicitly quitting chrome when detaching, which ruins my macOS fullscreen layouts. I want the window to remain open.

Someone suggested I use the server option, but I couldn't find it anywhere. Had to find it through this issue.

I think it's OK to not offer it in the device selection window when executing flutter run, but it should be visible in flutter devices... OR there should be a documented flutter devices --all flag

[zambetpentru]

To add, this is a very useful option to be able to use web debug on a remote device so I think it's important that we keep it available.

[codingiswhyicry]

Adding that I've had a hard time finding any information about this but am in support of keeping web-server indefinitely.

I am working with a web app that uses the camera that blocks off the rest of the app until a photo is taken. I get random camera failure issues in Chrome, which is a separate bug elsewhere, but run web-server is the only workaround I've found for it. I forgot the flag and spent a couple of weeks looking for it, only to find unrelated content more along the lines of backend hosting. I found this thread on my 3rd search.

I hope we keep web-server, as it's the only way I can test camera functionality on Flutter web, and that it's documented a bit more clearly as an option for future reference. I know we want to abstract stuff for beginners, but the lack of recent reference and SEO on this / unable to see it in flutter devices has pretty much almost convinced me I hallucinated it in a dream.

[cmjordan42]

I cannot understand why this continues to be hidden as a target device. The web-server is a distinct platform and build process... there are clearly many people who wish to use it as a target device, myself included. If there are really imaginary users who are harmed by its presence, allow the IDE to run flutter devices with the --show-web-server-device argument. I guarantee there are fewer people using the Edge or Linux device than there are using web-server, and yet everyone works around those being in the list.

Flutter Web is already a red-headed step child... why would you want to do anything to further reinforce this sentiment in the community?!

[cmjordan42]

Also, why is it that the guy who removed this feature in 2021 is an Apple employee? Come on, Google.