For compiling JS to be widely used, there has to be a decompiler or interpreter in most major browsers. It's no different than distributing binaries written in any compiled language.
How does this damage the open web?
HN user
For compiling JS to be widely used, there has to be a decompiler or interpreter in most major browsers. It's no different than distributing binaries written in any compiled language.
How does this damage the open web?
It's still an HTML document. Bookmarklets and screen scraping are most certainly doable. The latter, probably easier than it normally is. How is this presenting a problem?
Browser plugins and extensions are entirely unrelated to HTML and CSS, but if they were related it'd still be a non-issue since this is still an HTML document in a browser.
I don't think there's a clear-cut winner - it's mostly choice. Strong typing generally allows more solid, less-breakable code; weak typing generally allows quick prototyping and small scripts to be done at a faster pace.
This is why I suggested a -strict flag (https://github.com/bendmorris/scotch/issues/3): if you decide that you're done prototyping, and would like to make what you're doing more explicit.
Another method could possibly be being able to specify in-code that it's strict, perhaps something along the lines of "#flags: strict <...>" for flags always applied to that file? (Yes, that's ugly. I'm talking about the idea, not that particular incarnation of the idea)
This would allow the best of both worlds, without trying to force them to play nice with each other in one file.
However, even while avoiding mixing them in one file, that still raises other issues. For instance, if non-strict file "a" imports strict file "b", is "a" strict? I'd vote not (this would allow the entire standard library to be strict for clarity, and not cause any issues elsewhere), but I'm curious what other people's opinions are.