4 ms·
> Buying or developing technologies that rely on weird proprietary quirks of free versions of software isn't very sane. There's not even a business model in pla
by lucaspiller 11y ago
> Buying or developing technologies that rely on weird proprietary quirks of free versions of software isn't very sane. There's not even a business model in place you can rely on to continue to want to support you since it's free.
It's all very well saying this now, but I wouldn't be surprised if at the time these technologies were seen as JavaScript is now. I remember Adobe Air was when it came out...
- kbenson 11y agoJavascript has a standard (or more accurately, current javascript is the implementation of a version of the standard). It's a much safer bet that either there will be backwards compatible implementations later or that you will have other options. To my knowlesde, IE's feature set was always "what's supported by the current release". It's sort of like having a codebase which you can't change which makes use of a bunch of weird proprietary C extensions from some old compiler, and the compiler itself not only has the capability to introduce bugs and security flaws, but has a track-record of doing so. You know it's a ticking time bomb now, and you should have seen it in the beginning (although so many didn't :/ )
- orionblastar 11y agoEven back in 1997 JavaScript worked differently based on what OS and web browser you had. I had open sourced this script to detect the OS and web browser so that it would run JavaScript code using if statements for each platform to solve compatibility problems. It should still work today but the ActiveX detection is broken because of the way JavaScript changed. http://www.javascriptsource.com/repository/javascripts/2005/09/721471/UserDetail.html http://www.javascriptsource.com/repository/javascripts/2005/...
- kbenson 11y agoI understand there were plenty of non-standard features, but keeping to standard features should have been possible, and JS didn't change that much between browser versions (and where it did fixed could be implemented, as your detection script would have helped with). It took quite a while for some standard JS features to be added[1], but a mostly stable subset was possible (as evidenced by the sites that worked in all the major browsers of the time). The real problem was companies not wanting to devote the time to doing this and taking the shortcut of using the non-standard IE features MS had included at the expense of browser interoperability (which would have provided some protection against using features that would be dropped). 1: https://msdn.microsoft.com/en-us/library/s4esdbwz(v=vs.94).aspx https://msdn.microsoft.com/en-us/library/s4esdbwz(v=vs.94).a...
- orionblastar 11y agoThe problem with Internet Explorer at the time I worked with it is that it had a version of JavaScript called JScript that ran in the background that had differences with the JavaScript used in Netscape and other web browsers. https://en.wikipedia.org/wiki/JScript https://en.wikipedia.org/wiki/JScript In my experience I had to write JavaScript code that detected the OS the web browser type and even the processor so that I could use if statements to run the correct JavaScript code for each platform that worked. I've been out of it for a decade due to a disability, but I see that Microsoft has updated JScript and has used some form of JavaScript in Windows 8 Apps as well. I never really liked Metro/Modern UI and Windows 10 kind of changed it to Universal Apps. I like that they have made improvements to JavaScript like Node etc and even run JavaScript in the OS and the backend as well as the frontend.
- kbenson 11y agoYeah, I'm familiar with jscript, and have used it in the past. You should check out the "Comparison to Javascript"[1] section of that article. JScript was just MS's way to get around Sun and the trademark issue. In a lot of ways, it's the same as Google and Dalvik compared to Java. Same language, different name to get around legal issues. Now, I know MS's version of javascript (JScript) had it's own quirks and issues (such as no trailing comma allowed in objects and array syntax), but it shouldn't have been too hard with a minimum of testing to make sure it worked on both IE and Netscape and/or Firebird (before it was renamed to Firefox). The problem is that many didn't both at all, and didn't even attempt to figure out which bits that they used were standard parts of Javascript or the ECMAScript standard and what were MS extensions. That said, there was a major benefit to people forging ahead with MS specific extensions. The wide acceptance and update of XMLHttpRequest was spurred by MS's introduction of that type of call through custom ActiveX objects[2]. 1: https://en.wikipedia.org/wiki/JScript#Comparison_to_JavaScript https://en.wikipedia.org/wiki/JScript#Comparison_to_JavaScri... 2: https://en.wikipedia.org/wiki/XMLHttpRequest#Support_in_Internet_Explorer_versions_5.2C_5.5.2C_and_6 https://en.wikipedia.org/wiki/XMLHttpRequest#Support_in_Inte...