4 ms·

If you are developing for the web what difference does the OS make? Web technologies work the same on any OS

CapsAdmin 4y ago
While the final output should be the same, the development tools are not and that's really where all the subtle problems are. One of the reason WSL exists is to solve this problem. (assuming bun doesn't work on native windows but works under wsl)
- vips7L 4y ago
  WSL has its own pain points. It’s not the catch all solution everyone claims it to be.
pmontra 4y ago
Sometimes the target OS for deployment matters. Obvious case I run into: a deploy broke because a developer using Windows didn't realize he had some MiXeD case file name with the wrong capital letter. The Linux OS on the production system noticed. Sometimes it's the availability of native modules. They tend to exist for Linux, because it's the target for deployment, and sometimes not for Windows.
- davidmurdoch 4y ago
  Basic CI tests should catch those cases.
  - pmontra 4y ago
    The file names yes, modules are catched at development time. "We can't use PackageX because it doesn't exist for Windows and Joe won't be able to run the project anymore." A VM first and WSL2 now solved much of those problems, which leaves us at why bothering with Windows in this kind of business tough.
542458 4y ago
As a web dev, my choice of OS influences: * What IDEs/editors I have access to * What image editing tools I have access to * How easy it is to get my server’s backend running on my local machineas a dev environment The last one is most relevant to this conversation. If I’m working on a bun-based project, not being able to run a local dev copy on Windows easily is a nontrivial obstacle.
flohofwoe 4y ago
Mainly subtle differences around command line tools and the file system. There are UNIX cmdline tools collections for Windows (like busybox) running in the vanilla cmd.exe or Powershell, but they don't quite fit in (for instance the way how string escaping and cmdline argument parsing works). You can use bash in a mingw 'UNIX emulator', but then you can just as well switch to WSL. And those little things propagate and amplify upward into toolchains and workflows. It's possible to create command line tools that work across Windows and UNIX-oids, and I appreciate this, but it's a lot of additional work (even 'cross-platform' solutions like Python don't fully wrap this stuff, even though they do their best).
- ripley12 4y ago
  > it's a lot of additional work FWIW, I have been remarkably impressed with Rust for this. The stdlib and package ecosystem are unusually good at building abstractions that work across *nix and Windows, and so the average command line tool written in Rust usually has good Windows support. Of course, the additional work hasn't really gone away - it's just been relegated to libraries unusually effectively :)
tyingq 4y ago
Lots of little gotchas if you don't at least do a fair amount of testing on Windows, since that's what most of your end users (usually) will be on. Things like "www-authenticate: Negotiate" in an SSO environment, people pasting rich text into web forms, handling environments with private certificate authorities, and so on.
searchableguy 4y ago
You cannot install safari on Windows and Linux. If you want to support apple users, you need to get a mac. Safari often has bugs and rendering issue which aren't present on Chromium or Firefox and need fallback.
- password4321 4y ago
  Not Safari, but WebKit: https://build.webkit.org/ https://build.webkit.org/
Zardoz84 4y ago
Windows it's painful slow to do anything.

While the final output should be the same, the development tools are not and that's really where all the subtle problems are. One of the reason WSL exists is to solve this problem. (assuming bun doesn't work on native windows but works under wsl)

vips7L 4y ago
WSL has its own pain points. It’s not the catch all solution everyone claims it to be.

pmontra 4y ago

Sometimes the target OS for deployment matters. Obvious case I run into: a deploy broke because a developer using Windows didn't realize he had some MiXeD case file name with the wrong capital letter. The Linux OS on the production system noticed. Sometimes it's the availability of native modules. They tend to exist for Linux, because it's the target for deployment, and sometimes not for Windows.

davidmurdoch 4y ago
Basic CI tests should catch those cases.
- pmontra 4y ago
  The file names yes, modules are catched at development time. "We can't use PackageX because it doesn't exist for Windows and Joe won't be able to run the project anymore." A VM first and WSL2 now solved much of those problems, which leaves us at why bothering with Windows in this kind of business tough.

542458 4y ago

As a web dev, my choice of OS influences: * What IDEs/editors I have access to * What image editing tools I have access to * How easy it is to get my server’s backend running on my local machineas a dev environment The last one is most relevant to this conversation. If I’m working on a bun-based project, not being able to run a local dev copy on Windows easily is a nontrivial obstacle.

flohofwoe 4y ago

Mainly subtle differences around command line tools and the file system. There are UNIX cmdline tools collections for Windows (like busybox) running in the vanilla cmd.exe or Powershell, but they don't quite fit in (for instance the way how string escaping and cmdline argument parsing works). You can use bash in a mingw 'UNIX emulator', but then you can just as well switch to WSL. And those little things propagate and amplify upward into toolchains and workflows. It's possible to create command line tools that work across Windows and UNIX-oids, and I appreciate this, but it's a lot of additional work (even 'cross-platform' solutions like Python don't fully wrap this stuff, even though they do their best).

ripley12 4y ago
> it's a lot of additional work FWIW, I have been remarkably impressed with Rust for this. The stdlib and package ecosystem are unusually good at building abstractions that work across *nix and Windows, and so the average command line tool written in Rust usually has good Windows support. Of course, the additional work hasn't really gone away - it's just been relegated to libraries unusually effectively :)

tyingq 4y ago

Lots of little gotchas if you don't at least do a fair amount of testing on Windows, since that's what most of your end users (usually) will be on. Things like "www-authenticate: Negotiate" in an SSO environment, people pasting rich text into web forms, handling environments with private certificate authorities, and so on.

searchableguy 4y ago

You cannot install safari on Windows and Linux. If you want to support apple users, you need to get a mac. Safari often has bugs and rendering issue which aren't present on Chromium or Firefox and need fallback.

password4321 4y ago
Not Safari, but WebKit: https://build.webkit.org/ https://build.webkit.org/

Zardoz84 4y ago

Windows it's painful slow to do anything.