Heisenberg Keypress

Breakpoint in JavaScript on keydown. When hit, focus shifts to debugger. The keypress never comes.

I can't observe both the keydown and the keypress event. If I observe the first one, I can't observe the second one.

Good to know. Bad to have to know.

Trying WebStorm

In JavaScript Development Sucks, I detailed some things that make it so. We can consider this a tools issue; at least as far as the language makes tool-making feasible. And it's easy to imagine pretty good tools for JavaScript. Refactoring may be largely out of reach with such a language, at least without assumptions or whole-program analysis. But that's not impossible either.

Am in the process of trying out WebStorm, an IDE in the IntelliJ family. So far:
+ autocompletion seems to be good; looks into at least files in same dir (probably also whole project)
+ it's aware of JS-specific features like 'arguments' -- if 'arguments' is used, an otherwise unused argument is no longer considered to be unused.

Well that's about it. I haven't understood how IntelliJ 'works', so it's pretty slow going. Maybe I'll end up with an expired trial period, as last time when I tried IntelliJ for JEE, forgetting about the period since I have work to do.

Double Period Brings Completion

Context: Eclipse JS Editor. 

The "|" in below examples is the caret. Cmd-Space in this situation: 

list_elem.|

does not bring up any proposals. But in this situation: 

list_elem..|

...useful proposals are shown! Wt*?

JavaScript Development Sucks

I'll try to be constructive. First, I'll collect a list of things that are ...bothersome. Then, each problem can get its own blog post, at least the non-trivial problems, with discussion and hopefully some solutions or work-arounds.

This list is about developing using a browser, not about running Node.js or something like that.

Here we go...

JavaScript Development Issues

Tool Issue:

Issue: Fake read-only files in browsers. I often edit the source code in the browser by mistake; and then I can't save the edits.

Issue #2: Staying stopped at breakpoint uses two cores (in Chrome). Slows down the whole computer. Also makes fan noise, burns energy, creates heat.

Issue #3: Debugger not active on some reloads.


Issue #4: Chrome crashes when my Java server is terminated. (Solution: close affected tabs, so that the connections close. Without connections, Chrome seems to do fine.)

Issue #5: Sometimes getting stuck before anything at all is shown: no page, no debugger, nothing but whiteness.

Issue #6: Dependency management.

Issue #7: Editors/IDE.

Issue #8: Eclipse Java + JS == not true. a) When a JavaScript view is open, you can't do Open Type. Very annoying. b) 'Run' command on JS file gives me: 'Not on JS build path'. Damn annoying.


Issue #10: Too dynamic. No type system. No constants. No block scope.

...to be continued.

Chrome Debugger Multithreading

This is what multithreading means in the context of the Chrome Javascript debugger:

1023 Google Chrome Helper 81.9 5 111.9 MB  Intel 1025 Google Chrome Renderer 70.3 6 78.5 MB   Intel

So it makes use of multiple cores: 

This, when halted at a breakpoint. Well, winter's nearing, and it's probably going to be a cold one, so we may need the extra heating. And maybe Chrome 23 will fix this...right. 

I'd really like to know what it's doing with these cycles.