Hi,
so my Threejs App works fine on zthe latest browsers. However, since I want as many people as possible to use the app, it would be nice to have it downwards compatible as much as possible.
On Mac Safari it stops working on version 14.1
On Firefox it works flawless until Version 85 and starts giving non Show Stopping Errors on older Version…
Some Browser do not load the app and tell me they failed to create the WebGL context…
I guess is is due to a newer Version of Webgl is not supported.
And so ond and so on… similar to other browsers.
No the question is… should I use an older version or is there a Fallback mechanism build in Three or a custom one?
I honestly wouldn’t worry about it if you can avoid worrying about it. Writing extra code to support 0.01% of the market is just adding technical debt and cruft to your project that will make it grow slower and more gnarled over time.
If you’re feeling super generous about wasting your time supporting dead platforms/browsers, just open source your thing and let people fork it/adapt it to what they need. That way you can keep your codebase clean, but people can still make the tailored version that will probably by definition wither away as their broken platforms disappear over time.
Unfortunately the caniuse.com statistics are not accurate here – this tells us only that most users have a browser that is capable of supporting WebGL 2, not that most users have a device that supports WebGL 2, and (unlike most Web APIs) both are necessary. I wish they included a note on that.
While it’s perhaps less of a “random sampling” statistically, Web3D Survey - WebGL 2 Results measures real WebGL 2 support, and I’d trust it more here.
In any case, new versions of three.js indeed do not support WebGL 1 — only WebGL 2 or WebGPU. I would recommend testing explicitly for WebGL 2 support when your app loads, as “failed to create the WebGL context” could mean other things, and some (rare) devices still do not support WebGL at all. If you must support WebGL 1 you’ll need to stay on a previous version of three.js, or perhaps to coordinate maintaining a fork of WebGL1Renderer if others have similar needs.
ok so 1 out of 20 users generally doesn’t have webGL or some broken form of it.
1 out of 4 android users don’t have it or some broken form.
That 1 person is shrinking over time… seems to me not worth development effort to chase that shrinking percentage…
vs just having a static page/video fallback.
Like… the fallback should be to not use webGL and just use a static page.
Not try to use pretend canvas gl, or cssrenderer, or software rendering or put limits on the standard extensions you use etc.
Like… if you’re paying a dev 70 an hour… and you’re paying them to support this 1-20 percent of the pop… you’re effectively paying them 4x to 100x an hour in terms of the bang you get for their development hours.
Is it worth paying a dev 7k an hour to reach that market segment? Adding technical debt the whole time?
And that time is being taken away from developing actual compelling features…
Then, there is the detection problem… figuring out what browser is running/fingerprinting the browser (gdpr) deciding what to do on device+browser+gpu driver etc.
I know the world isn’t a perfect place, but our lives are also short, and carpal tunnel is a thing… and also part of being a good/healthy developer is pushing back strongly against unreasonable business decisions.
No objection to your conclusions @manthrax! I think it’s just a decision a project needs to make — if you’re building a mobile-only app for customers in a country where 98% of users have Android (e.g. India), the numbers will look very different, so maybe don’t make three.js a requirement for users to access their bank account or something. But you probably shouldn’t do that even if WebGL had 100% support (see a11y). Have to make an informed decision on the numbers, the product, and the fallback scenario.
For maintenance of three.js, though … developing ongoing support for WebGPU + WebGL 2 + WebGL 1 was just too much. Trying to support WebGL 1 held back features in the other APIs. Like any project, three.js has to make decisions about where to put resources.
And, yeah … I think the set of use cases where it makes sense to require WebGL support, but not to also require WebGL 2 support, is now pretty narrow. Maybe something like Google Maps.
I hope I live to see the day when we learn why threejs does it like this. What are the downsides of Three v1 supporting webgl 1 and Three. V2.0 supporting webgl2 etc.
The way i understand this, the OP is using the same version of there as autodesk forge for example, that may still be stuck on 0.78. But 0.168 doesnt work for him anymore.
I understand that. Looking and working towards future proof technoloy is best.
However… Many people use Iphones, for example, and don’t buy a new one every year.
So I think it is not the worst scenario, when some apps are still running on “old” Iphones or Androids.
three.js r162 is the version that supports WebGL 1, if you prefer. The main thing is that this version isn’t getting more updates moving forward. If it’s unclear why updating two divergent branches of three.js would make things very difficult for maintainers over time, I’m happy to suggest a “fun” exercise to find out.
Instead of examining the code … would it be faster if you just switch to a slightly old Three.js release (and old addons) and check whether your app is working well? If not working, you could easily find what functionality is causing a problem, or downgrade to an even older release…
A real problem would be if you rely on a library that explicitly uses the latest Three.js release.
If it’s unclear why updating two divergent branches of three.js would make things very difficult for maintainers over time, I’m happy to suggest a “fun” exercise to find out.
Please, anything that would help understand this.
@dubois with apologies, I was making a bad joke here. More literally, any volunteers are welcome to pick up the old WebGL1Renderer code and to maintain that separately (whatever amount of work that might require) moving forward.
