Bug: importmap isn't suppored by Firefox and Safari

Fun is life, fun is good - and God is a DJ bundling stuff via Webpack to run Three.js on us all, but don’t tell anyone about it. :shushing_face:

Indeed. Complexity is not a problem for me personally (if it were, I wouldn’t have got into this in the first place), I’m more concerned from the point of view of the regular user - who might just simply try to run things or begin to develop them. At this rate, somewhere in the future we could look to try and find workarounds to “solve” existing workarounds, and realize the internet became a place for “experts” instead of a place for “everybody”…

yes lets ask all visitors of the website to pretty please “simply” set the dom.importMaps.enabled flag in about:config , and let me immediately apologise for the sarcasm.

the problem is that >script type=“importmap”< is not supported so you can never refer to ‘three’ as a shortcut in imported files where there is reference to ‘three’ that it will interpret as an url, which should start with ‘./’ or ‘…/’ etc , which is because without it will interpret as the reference from >script type=“importmap”<, so the validation is there already but the implementation not , sigh

These examples will simply never work until safari and ff are supporting it.

ps I solved all issues by a find/replace ‘three’ with ‘/three/build/three.module.js’ in all threejs files that export, it was a 1 minute job and I don’t really understand the need for shims in this context. As soon as import maps is supported it can be adjusted, just as the shim thing will be removed then in all files, same effort. I am sure there is a good reason for it :wink:

another perspective: the web is easier to deal with than ever before for everybody because of said tools.

web dev used to be a manual chore, required deep, explicit expert knowledge. there was no shared common ground, no eco system, handling assets with zip files, “debugging” meant a browser refresh for every change, no modules, we concatenated a stack of javascript files in explicit order, publishing meant bombarding the poor user with megabytes of uncompressed, often unused, data.

this doesn’t exist any longer, web dev as a whole has moved on from that years ago. everything has been consolidated into tools that work ootb. from handling assets, debugging, compressing, publishing. you don’t worry or think about tools or build steps, you run npm create vite once and just develop.

No need to apologize for the sarcasm, I’m one of the people who likes it and understand its utility. On the rest, I agree with you - at the time of posting that reply the issue wasn’t yet clarified to emphasize the fact that some things are not yet supported in certain environments, so I thought it was just a matter of setting a flag differently, hence the reply contents. In the meantime, I understood that it wasn’t quite the case. :wink:

Well, it’s a matter of perspective alright, but I have serious doubts that web is easier to deal with for “everybody”. Folks used to do things the older way (that it’s true had its quirks and such, but the user could fully control the process from start to finish) will find it harder to do things the modern way (where lots of stuff are done by others, i.e. the “experts”, yet the user still has to know what to install, how to configure, what he can and cannot do, before writing his actual code). Many people just get tired of having to relearn continuously evolving ways (and contraints) of doing the same thing, and prefer the KISS way - that’s why IE compatiblity is still a thing to this day.

In other words, a set of “know how” that was under the user control was replaced by a similar set where even if you don’t have to bother with the techniques in certain areas you still have to know what you need to do before writing your webpage. If everything was so simple in that regard, we wouldn’t have so many questions about how to make things work properly all over the web. Also, even if Vite and similar handles some things, those things (and others like handling CORS and the security concerns, modules, imports, etc.) are still a part of the process to make something that can be just a “Hello World” work.

I have my reservations on things like consolidation or the debug and compression area too. Having to use N tools do do something simple is only on the surface different from having to use N tricks to do the same earlier. Debugging doesn’t need an IDE or other fancy tools to do it, I still use the goold old refresh button and Notepad++ and the result is the same. Compression is only temporarily solving problems, because all the assets, tools and features that are involved in a project keep (and will continue) to get more complex and bigger (e.g. Visual Sudio used to be under 1 GB in its first version, now it’s 40 GB, Javascript projects used assets of 1 or 2 MB and now it’s ten times than that and more since you have sites that take ages to load even on fast computers and net connections, etc).

To put in a simple way, it’s true that now you can “just” sit in a Ferrari and drive, but the know how and the money to build and buy that Ferrari is still needed, and you need specialists for that as you can’t do it yourself anymore. By comparison, you can easily build and ride a bicycle yourself. It may not be fashionable nowadays, but it will still take you from one place to another and is preferred by some people.

the result is not the same. this is sticks and stones in a cave. why make assumptions, just install it, try it for a month, see if you feel that bitter about it still (i doubt you will). if you do, would be nice to hear back from you, good and bad.

I meant that it won’t make your code better if you already know what you’re doing. Sticks and stones in a cave might be less efficient but again, the end result is the same: we survived then, we survive now, only the means have changed. I’m not for sticks and stones, I’m for efficiency - the kind of efficiency that goes from the ground up through good structure, not patching structure flaws via successive tools.

Anyway, you make an absolutely valid point about trying it. I might do it, but I know myself: I will probably like it, yet it won’t change the conclusion. All new tools promise better, but eventually they end up not able to keep up with growing demands, becoming obsolete and replaced by others selling the same idea. This is what happens when the system itself is not built with efficiency in mind in the first place.

Used to need an OS and a browser to write code for web, now you can’t get away with less than half a dozen tools and a bunch of complicated settings to do basic things. It doesn’t matter if you get lucky and Vite does some of them for you, they shouldn’t be needed to begin with.

1 Like