18 ms·

Beyond the unpleasant experience of using it, what is actually wrong with it?

by jdc 11y ago

lqdc13 11y ago
Very easy to have all kinds of memory leaks right now for one. It is really a combination of Javascript and the DOM. Unpleasant to use is definitely a big thing too. If it was easy and pleasant, nobody would complain.
- zbyte64 11y ago
  Given any abstraction on a turing machine you will find it is easy to have memory leaks.
- bzbarsky 11y ago
  Is it really easier to have memory leaks here than in any other garbage-collected language with first-class functions and closures? If you stick references to objects somewhere permanent, you will leak them. If you don't, you won't....
  - lqdc13 11y ago
    Ok, it's not that simple: http://www.javascriptkit.com/javatutors/closuresleak/index3.shtml http://www.javascriptkit.com/javatutors/closuresleak/index3.... The last example is a good demonstration that. Sure, at the end of the day it's all about not cleaning the references. All I'm saying is that it is super easy to accidentally not clean the references. In other languages or even in javascript itself without the DOM, it's not nearly that easy.
    - bzbarsky 11y ago
      The exhibits on that page seem to be quoted from https://msdn.microsoft.com/en-us/library/bb250448%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/bb250448%28v=vs.85%... which is a 10-year-old article that was marked as obsolete 4 years ago. And it's specific to old IE versions; the problems are fixed in newer IE versions. And even in IE6 as of 2012; see https://support.microsoft.com/en-us/kb/929874 https://support.microsoft.com/en-us/kb/929874 Back in 2005 Gecko (Firefox) had issues like this too, but a cycle collector was added in 2006 that handles this sort of problem. For DOM nodes issues like this basically don't happen in modern browsers. There _are_ still some existing bugs of this sort in browsers for objects other than DOM nodes (especially WebKit and Blink; modern IE and Gecko are way ahead here, though Blink is actively working on fixing this in their implementation). But you typically have to work quite a bit to hit these cases; all the common cases are handled correctly because otherwise pretty much any web site you left open for an hour or two would use up all the RAM on your machine. I do agree that if you have to worry about compat with old/unpatched browser versions then you run into some serious problems with this sort of thing. If you have to deal with that, you have other serious problems too, of course. And, again, the source of all the "leak while the website is live" behaviors I have seen recently is websites doing things like sticking more and more stuff in global arrays. That's just a basic no-no in a garbage collected language, obviously.
      - tracker1 11y ago
        IIRC it was particularly hard for MS to improve on (got much better starting with IE8)... I worked on an extjs app around 09 that would just eat itself in IE6 (the corporate browser at the time) if the app was open more than 3-4 hours. It was pretty bad.. FF didn't have any issues at the time, and could run open all day. Even then, still much better than the late 90's, when the NN/IE4 browsers were still hanging on, and needed to be supported... that was anti-fun.
bzbarsky 11y ago
The main problem with the DOM API is that when used from JS it's a pain, because it was designed largely by people wanting to do DOM in XML documents in Java on the server side; the use on the web was considered less important at the time. Many of the resulting issues (e.g. lack of use of options objects when it would be appropriate, numeric "enums" etc), flow from this historical accident.

Beyond the unpleasant experience of using it, what is actually wrong with it?

by jdc 11y ago

Beyond the unpleasant experience of using it, what is actually wrong with it?

Very easy to have all kinds of memory leaks right now for one. It is really a combination of Javascript and the DOM. Unpleasant to use is definitely a big thing too. If it was easy and pleasant, nobody would complain.

zbyte64 11y ago
Given any abstraction on a turing machine you will find it is easy to have memory leaks.
bzbarsky 11y ago
Is it really easier to have memory leaks here than in any other garbage-collected language with first-class functions and closures? If you stick references to objects somewhere permanent, you will leak them. If you don't, you won't....
- lqdc13 11y ago
  Ok, it's not that simple: http://www.javascriptkit.com/javatutors/closuresleak/index3.shtml http://www.javascriptkit.com/javatutors/closuresleak/index3.... The last example is a good demonstration that. Sure, at the end of the day it's all about not cleaning the references. All I'm saying is that it is super easy to accidentally not clean the references. In other languages or even in javascript itself without the DOM, it's not nearly that easy.
  - bzbarsky 11y ago
    The exhibits on that page seem to be quoted from https://msdn.microsoft.com/en-us/library/bb250448%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/bb250448%28v=vs.85%... which is a 10-year-old article that was marked as obsolete 4 years ago. And it's specific to old IE versions; the problems are fixed in newer IE versions. And even in IE6 as of 2012; see https://support.microsoft.com/en-us/kb/929874 https://support.microsoft.com/en-us/kb/929874 Back in 2005 Gecko (Firefox) had issues like this too, but a cycle collector was added in 2006 that handles this sort of problem. For DOM nodes issues like this basically don't happen in modern browsers. There _are_ still some existing bugs of this sort in browsers for objects other than DOM nodes (especially WebKit and Blink; modern IE and Gecko are way ahead here, though Blink is actively working on fixing this in their implementation). But you typically have to work quite a bit to hit these cases; all the common cases are handled correctly because otherwise pretty much any web site you left open for an hour or two would use up all the RAM on your machine. I do agree that if you have to worry about compat with old/unpatched browser versions then you run into some serious problems with this sort of thing. If you have to deal with that, you have other serious problems too, of course. And, again, the source of all the "leak while the website is live" behaviors I have seen recently is websites doing things like sticking more and more stuff in global arrays. That's just a basic no-no in a garbage collected language, obviously.
    - tracker1 11y ago
      IIRC it was particularly hard for MS to improve on (got much better starting with IE8)... I worked on an extjs app around 09 that would just eat itself in IE6 (the corporate browser at the time) if the app was open more than 3-4 hours. It was pretty bad.. FF didn't have any issues at the time, and could run open all day. Even then, still much better than the late 90's, when the NN/IE4 browsers were still hanging on, and needed to be supported... that was anti-fun.

bzbarsky 11y ago

The main problem with the DOM API is that when used from JS it's a pain, because it was designed largely by people wanting to do DOM in XML documents in Java on the server side; the use on the web was considered less important at the time. Many of the resulting issues (e.g. lack of use of options objects when it would be appropriate, numeric "enums" etc), flow from this historical accident.