0

I'm writing scripts which I want to split into several modules. The "baseline" modules will support older browsers, which do not support new syntax such as === and promises.

The "advanced" modules will be loaded if the browser passes a feature-check.

My question is, how do I check if browser supports === operator and .then(function(){}) promise syntax without actually using them first, and causing a syntax error in older browsers?

if (/*what goes here*/) {
    var script = document.createElement('script');
    script.src = '/advanced.js';
    script.async = false;
    document.head.appendChild(script);
}
i-g
  • 69
  • 4
  • 22
  • 1
    What browser doesn't support `===`??? – Charlie Fish Jan 19 '20 at 19:26
  • 3
    `===` is in JS since the beginning, and promises only require a polyfill - they don't have special syntax – Bergi Jan 19 '20 at 19:36
  • @Bergi Actually, it was added in the [3rd edition](https://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf) of ECMAscript in December 1999. See section 11.9.4. However, I agree with your advise practically. [source](https://stackoverflow.com/a/53111225/217867) – Lonnie Best Jan 19 '20 at 20:04
  • @LonnieBest I honestly question if the OP is really targeting browsers from pre December 1999. Going from `===` to Promises, is a pretty large leap. Which is one reason this question was very poorly written. Chances are if you are concerned about `===` support, you have a lot more problems and things you should be thinking about before Promise support. So although a fun piece of trivia, I'm not sure how relevant it is to the question. Also, just a simple assignment (`=`) was only added in the 3rd edition. So the code the OP originally wrote wouldn't even work there either. – Charlie Fish Jan 19 '20 at 21:43
  • 1
    @CharlieFish The question is not poorly written to my level of comprehension. The OP is asking how to detect support for two things in browsers: the `===` operator and promises. The inception date of the '===' operator into the specification is a pertinent fact on which to evaluation whether that concern is justified. That fact also corrects a slight exaggeration made in a previous comment (making it even more pertinent to its context). Lastly, `=` and `===` do NOT share the same inception date into the specification as the last part of your comment argues. – Lonnie Best Jan 20 '20 at 00:17
  • 1
    @LonnieBest In my opinion, if the OP truly intended it as written, it should be two separate questions. `===` and promises have nothing to do with each other in the context of the OP's question. Chances are if you are concerned about promise support AND `===` you have a lot of other code that is not compatible. You are correct tho, according to (https://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf) it listed `=`. I'm used to having those documents only discuss change sets vs the entire spec. My bad. – Charlie Fish Jan 20 '20 at 00:27
  • @LonnieBest It's also important to keep in mind that any implementation that supports promises natively will support `===`, by a LOT. So comparing two things that are separated by almost 2 decades seems very strange to me for one question. – Charlie Fish Jan 20 '20 at 00:29
  • I'm still super curious what the OP's use case here is, and which browsers they are required to target. – Charlie Fish Jan 20 '20 at 00:31
  • 1
    For those wondering why I am targeting browsers pre-1999, it is for an exercise in "ultra-compatibility". In part to show that progressive enhancement is possible, and in part for retro-computing interests. So yes, this does mean classics like Netcape 3 and IE4, neither of which support ===. For those saying it's been in JS since the beginning, learn the history of your craft, you amateurs. – i-g Jan 20 '20 at 07:36
  • @CharlieFish I appreciate your comments about === and promises being far apart. Those are just the two main obstacles I've run into in my testing so far. If you can suggest any other milestones I should test for, I will appreciate it. – i-g Jan 20 '20 at 07:37
  • @i-g Makes sense. I’m super curious how you are testing it on those browsers. Do you just have old devices you are using or? I’d also be careful about calling people who weren’t aware of it not being in JS since the beginning “amateurs”. It’s for sure a fun fact that effects VERY few JS developers day to day. I’ve never had to target browsers that old before so not sure what other milestones you should test for. Kinda over my head at this point. But I’d be kinda surprised if there weren’t more. There might not be, but it seems like there likely could be. Good luck!! – Charlie Fish Jan 20 '20 at 16:28
  • @CharlieFish I'm mostly using emulators and Wine to run the older browsers. Sometimes I come across old devices and test on those too. – i-g Jan 22 '20 at 06:20

1 Answers1

-1

If a browser supports promises, it will support then. One way (among others) to see if a browser supports promises (without throwing an error) would be to see if window.Promise exists:

if(window.hasOwnProperty("Promise"))
{
  console.log("Promises are supported.");
}
else
{
  console.log("This browser does NOT support promises.");
}

As for ===, I don't think you'll have to worry about that one. === was added to ECMAscript in the 3rd edition in December of 1999 and it is hard to imagine anyone (even a diehard laggard) using a browser today that doesn't support it.

UPDATE:

If you really insist on detecting === support, my conclusion (from my comments below) is to accomplish this by researching which browsers do not support === and using Browser Detection to detect those browsers. I hope someone else offers you an easier way I'm not thinking of.

Lonnie Best
  • 9,936
  • 10
  • 57
  • 97
  • You may not think I'll have to worry about ===, but I actually do, because I want to support pre-1999 browsers. I appreciate your answer regarding Promises, I think that's how I will do that part. – i-g Jan 20 '20 at 09:53
  • @i-g I'll have to give that some thought, I'm not sure how you'd test for the `===` operator, because it seems to me like the just-in-time compiler would throw an error from the mere existence of `===` if the browser doesn't support it. My current thoughts are the you'd likely have to do [Browser Detection](https://www.joezimjs.com/javascript/feature-detection-vs-browser-detection/) instead of *Feature Detection* to accomplish this. – Lonnie Best Jan 20 '20 at 12:07
  • @i-g Another idea I pondered was the to use Try/Catch, but try/catch didn't make it into Internet Explorer until version 5. – Lonnie Best Jan 20 '20 at 13:46
  • @i-g Also, I thought about [eval](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval), yet `eval` made it into Internet Explorer in version 3, so even if you could use it to test `eval("1 === 1")`, eval wasn't there at the beginning. That leaves you with browser detection: the painful process of identifying browsers and doing if/then logic based on whether your research concludes that `===` is supported in that browser or not. I'd say "screw that", and just settle for the code not working in those browsers that no one uses anymore (bottom line). – Lonnie Best Jan 20 '20 at 13:47
  • Thanks for your suggestions, @LonnieBest. Saying "screw that" is not an option in this exercise, so I think I'll just avoid using ===. – i-g Jan 22 '20 at 06:21
  • @i-g : I didn't even think of that. Makes sense. – Lonnie Best Jan 22 '20 at 06:55
  • @i-g Remember, ‘===‘ is basically ‘==‘ plus an additional conditional to check if the type matches. Not sure when ‘typeof’ was added to the spec. But might be something to look into for cases where you need ‘===‘. – Charlie Fish Jan 22 '20 at 15:04