5 ms·
Please do argue javascript. How else could you do dynamic and logical operations in the browser presently?
by calibwam 12y ago
Please do argue javascript. How else could you do dynamic and logical operations in the browser presently?
- cm2187 12y agoI think like Flash and Java, javascript should not be removed from the browser. Some websites do have a need for flash (for streaming for example). I think the problem is rather that flash, java and javascript are all enabled by default, allowing any site and all the associated advertisement websites to execute code without the user consenting or being aware. This is a major security and privacy problem. The model should rather be per-website opt-in of javascript if required (and most websites don't need it). And even in that scenario enforcing a same source policy, ie only javascript hosted on the domain visited would be enabled, not third party javascript. To me the current model is like windows XP's autorun. It is just designed to be a perpetual source of security and privacy breaches until someone finally takes the decision to kill it.
- LukeB_UK 12y agoThe problem with disabling javascript by default and making it opt-in, is that most users expect things to just work. If you want to disable javascript yourself, fine, but don't degrade the experience of the web for everyone.
- cm2187 12y agoBut there is an over reliance on javascript to make up for the shortcomings of html and css. Most websites should not need javascript. If you look at your own browsing history, how many of these websites genuinely need to run client side logic? If a user ends up on a webmail or an online gaming website, I don't think he will be surprised if he is asked whether he would like to allow this website (not third parties) to execute javascript (and to keep that setting). If that same user goes on any blog, forum, news or ecommerce website, there is really no good reason to execute client side code. Auto completion in a text box (or server validation by input without a full POST) should have been embedded in html a long time ago. And it took 20 years before they finally agreed to add a datepicker tag, not exactly a new problem. Because of the glacial pace of evolution of html, we became used to javascript tricks to make up for what html doesn't do. And flash is mostly used for the same reason. That doesn't mean that flash and javascript don't have any use.
- NathanKP 12y agoI'd rather have our current lighter, generic HTML spec that can be enhanced by running code in JS than a heavy HTML spec that tries to do everything in pure HTML/CSS just so that way we can avoid running JS by default. The more complicated HTML/CSS gets the less efficient it will be and the harder it will be to get all the browsers to maintain compatibility with each other. In a way the current scenario where a lighter, shallower HTML and CSS are enhanced by custom code in the form of JS is better for the ecosystem because it allows creative freedom in development without overloading the core engine with cruft. If you choose to do so you can create a bloated abomination of an HTML page powered by tens of thousands of lines of JS, but since the core engine itself is very light it is also possible to make a clean and simple page that is extremely light and which uses no JS at all. On the other hand baking lots of functionality into the core engine would force everyone to experience the bloat and cruft, even if you were trying to make a clean and simple website.
- NathanKP 12y agoI'd rather have our current lighter, generic HTML spec that can be enhanced by running code in JS than a heavy HTML spec that tries to do everything in pure HTML/CSS just so that way we can avoid running JS by default. The more complicated HTML/CSS gets the less efficient it will be and the harder it will be to get all the browsers to maintain compatibility with each other. In a way the current scenario where a lighter, shallower HTML and CSS are enhanced by custom code in the form of JS is better for the ecosystem because it allows creative freedom in development without overloading the core engine with cruft. If you choose to do so you can create a bloated abomination of an HTML page powered by tens of thousands of lines of JS, but since the core engine itself is very light it is also possible to make a clean and simple page that is extremely light and which uses no JS at all. On the other hand baking lots of functionality into the core engine would force everyone to experience the bloat and cruft, even if you were trying to make a clean and simple website.
- NathanKP 12y agoI'd rather have our current lighter, generic HTML spec that can be enhanced by running code in JS than a heavy HTML spec that tries to do everything in pure HTML/CSS just so that way we can avoid running JS by default. The more complicated HTML/CSS gets the less efficient it will be and the harder it will be to get all the browsers to maintain compatibility with each other. In a way the current scenario where a lighter, shallower HTML and CSS are enhanced by custom code in the form of JS is better for the ecosystem because it allows creative freedom in development without overloading the core engine with cruft. If you choose to do so you can create a bloated abomination of an HTML page powered by tens of thousands of lines of JS, but since the core engine itself is very light it is also possible to make a clean and simple page that is extremely light and which uses no JS at all. On the other hand baking lots of functionality into the core engine would force everyone to experience the bloat and cruft, even if you were trying to make a clean and simple website.
- nkozyra 12y agoNeither flash nor java are "enabled by default.". I think that's a poor analogy. JavaScript engines are built directly into the browser.