Chrome To Deprecate PNaCl, Embrace New WebAssembly Standard (tomshardware.com) 108
An anonymous reader quotes Tom's Hardware
Google announced that its Portable Native Client (PNaCl) solution for making native code run inside the browser will be replaced by the new cross-browser web standard called WebAssembly... Even though Google open sourced PNaCl, as part of the Chromium project, Mozilla ended up creating its own alternative called "asm.js," an optimized subset of JavaScript that could also compile to the assembly language. Mozilla thought that asm.js was far simpler to implement and required no API compatibility, as PNaCl did. As these projects seemed to go nowhere, with everyone promoting their own standard, the major browser vendors seem to have eventually decided on creating WebAssembly. WebAssembly can give web apps near-native performance, offers support for more CPU features, and is simpler to implement in browsers and use by developers.
All for mobile (Score:1)
None of this matters a bit to desktop users.
Re: (Score:2)
Right, become desktop users don't use browsers.
Re: (Score:3, Funny)
"become"? Don't you mean "because"? Stupid moran.
Re: (Score:2)
Shut up, you're the moran.
Re: (Score:2)
Re: (Score:2)
You've commented on your own posts in the past, so you can shut up too.
Re: All for mobile (Score:1)
Re: (Score:2)
Or you could just code for a mobile app platform and stick to it.
I'll consider it once iOS becomes self-hosting.
Nobody wants web apps.
Speak for yourself, egg.
Everyone is moving away from desktops
The only way I know of to build and package apps for iOS is through the macOS-exclusive app Xcode. So how do you "just code for a mobile app platform" without a desktop Mac or a MacBook, which runs the same applications as a desktop Mac?
Re: (Score:2)
One cannot possibly write and distribute a native app for each and every supported OS.
Correct. That's why you write your native application for one operating system and hire five contractors to port your native application to each of the other five operating systems.
Interesting related reading (Score:4, Informative)
Re: (Score:2)
Browsers have gone too far. (Score:2)
It's time to go back to Web 1.0, back when web sites could be used on Megabytes of RAM and just 56K modems. Modern sites have become so morbidly obese with HTML5 and autoplaying media that even my computer with 16 Gigabytes of RAM slow down. This Web assembly will be used to create even more bloated web sites with adblock defeating adverts and tracking. Firefox has jumped the shark too, with Version 57 being the death of "classic" Firefox.
Re: (Score:1)
Would you prefer to have to install a separate native executable for each Internet-based application you use, provided it's even available for your operating system? How would something like YouTube work? Would you add the cat videos you want to watch to your cart, fill in your address, and then YouTube would burn them onto a DVD-R for you?
Web have gone too far. (Score:3)
It's time to go back to BBS, back when a BBS could be used on kilobytes of RAM and just 300bps modems. Web sites have become so morbidly obese with HTML and images that even my computer with 4 MB of RAM slows down. This Web 1.0 will be used to create even more bloated web sites with ads. Netscape has jumped the shark too, with version 3 being the death of "classic" Mosaic.
Re: (Score:3)
Those who were around in the days of FidoNet and Compuserve will tell you that they handled communication and even some shopping on minimal hardware and very slow data lines substantially more quickly and efficiently than the current shambles.
I'm increasingly finding myself in the "This Isn't working -- Let's back off and try again" camp.
Re: (Score:2)
I think the general idea here is that we have a hundred thousand times better hardware and transmission speeds and yet the whole process is barely ten times faster - except for file transfers of course.
Silent reading is faster (Score:2)
You're telling me I could communicate faster on Fidonet than on the current internet? REALLY? I suppose having a video chat with 8 people was a snap of the fingers?
People with this mentality find text chat superior to video chat. Anyone over twelve without a serious learning disability can read silently faster than he can listen, which particularly helps when eight users are sending messages to a channel at once.
I would bet 1 million time machine dollars that by the time you had finished your modem hand shake I could order something with my voice without even turning on a screen.
It's called a voice call to Domino's over Plain Old Telephone Service.
Nope. (Score:2)
I'm looking forward to the next hit browser that won't support javascript for just any ol' page and when it does, it uses an interpreter engine for increased security. It may require a new standard which means the W3C may have to fall (since they are backed by people pushing increasingly intrusive tech).
Re: (Score:1)
Java applets tried to be an OS rather than a mere UI handler. That made it bloated and a malware magnet.
Re: (Score:2)
Neither the VM or the language are that good actually. The language is probably the least bad of the two.
We have to go deeper: CPU bugs (Score:3)
Virtualization vendors can't manage to keep people from finding new escape vulnerabilities.
Nor can CPU vendors. Despite the engineers' best efforts, some CPUs ship with defects [osdev.org] that allow userspace software to lock the physical CPU. Some examples:
Re:Why secure? (Score:5, Insightful)
The way to do that is to literally pull out capabilities.
If you don't want it to be able to open files, you need to make it impossible to express "open a local filesystem file".
The browser DOMs are quite locked down in this regard, but they are still programs in themselves vulnerable to buffer overflows, etc. but - pretty much - you can't just access my camera, microphone, USB devices, arbitrary memory, etc. from a webpage.
If you're parsing the WebGL into a strict subset of OpenGL and providing virtualising memory etc. addresses that cannot be misconstrued or reveal other RAM, that's as good as you can get. And that's what browsers do.
The problem you describe is really just "I'm running a third-party program to run my other programs", not something different or defensible against.
Try writing a program in WebAssembly, though. Emscripten will compile C to WebAssembly if you want. On any up-to-date browser it's virtually impossible to make it do anything untoward except (maybe) use up CPU time. But you also can't access filesystems (Emscripten fakes a filesystem into a loopback area of memory, pre-allocated in one contiguous block at startup), access the network (Emscripten requires you to WebSocket anything you want to do on the net, and C sockets come out as WebSocket traffic requiring a WebSocet server somewhere - e.g. websockify - for it to interact with and convert the WebSockets back to normal network traffic. Not something you're going to be able to get a user to set up.), access devices or graphics RAM (but you can use WebGL), etc.
The browser is the interface, coupled with not being able to express malicious actions. Try to bypass it. Of course, it's not going to 100% impenetrable but NOTHING has yet proven to be except literally not doing anything useful. Hell, with RowHammer, code can actually interfere with "physically nearby" memory, and you can even detect the RF coming from a chip and intercept encryption by listening to the emissions. You have NO defence against those kinds of attacks.
But a browser running WebAssembly is no worse than a browser rendering plain HTML. An innocent action in a limited space. Until enough attention is garnered to warrant thousands of hours of attention from dedicated hackers trying to bypass it.
The fact is, however, that you still want to go on Netflix and watch your programs, log into your bank account, buy stuff on Amazon. And there's NO WAY to do that without taking exactly the same risks as running WebAssembly, which is contained only by your browser security model (Unlike Java and .NET which had their OWN security model separately and the browser just had to execute their code on the local machine and hope they'd done their job - they rarely had, which is why plugins are dead nowadays).
You think that you can bring all this stuff back to plain HTML, and - what? - Perl on the CGI backend of a server and be immune? We thought that 20 years ago, it didn't work out.
At some point you have to take user input, or input from a remote website, and interpret it in a way that cannot possibly be compromised while letting the user accomplish what they want to (e.g. play a movie, log in securely, etc.). If you find a way to do that, sell it to the world. Because they'd pay through the nose for it.
Limit the attack surface (Score:2)
The fact is, however, that you still want to go on Netflix and watch your programs
No, you would want to cancel Netflix, forgo its exclusive programs, and watch different programs that do not use digital restrictions management [fsf.org].
log into your bank account, buy stuff on Amazon
Which can in theory be done mostly server-side, with the client touching only HTTP, TLS, HTML, and CSS, not the larger attack surface of JavaScript or WebAssembly. Worse comes to worst, it could be done with an even smaller client attack surface over SSH, just as online banking and shopping used to be done over dial-up with a terminal emulator back when CompuServe
Re:NSA will backdoor ANY browser tech (Score:4, Informative)
The 'best' browser apps run literally thousands of times slower than what the native hardware is capable of.
If your computer happens to be something other than a Mac, a Mac app runs at zero speed.
If I lack the funding to develop my application for more than one platform, which of the following would reach the most users?
Re: (Score:2)
Re: (Score:2)
What are the most significant differences in your opinion among Web as interpreted by Gecko, Web as interpreted by Blink, and Web as interpreted by Apple WebKit?
Society needs software freedom, !running anything. (Score:3)
That's a question we can't answer without knowing more about the application and ultimately modern developers do develop for multiple OSes. One approach is to release the program as free software (users purchase the program and get a copy of the program licensed such that they may run, inspect, share, and modify the software) and users may help port the program to other systems and architectures. But ultimately your business needs are not more important than society's needs for not running any arbitrary pro
Re: (Score:2)
One approach is to release the program as free software (users purchase the program and get a copy of the program licensed such that they may run, inspect, share, and modify the software) and users may help port the program to other systems and architectures.
For one thing, in the case of a computer program released as free software, how can the developer recoup the cost of feeding and housing himself over the course of development if the first person to purchase a copy goes on to exercise his rights under the license to share that copy with every single other prospective customer?
For another, many programs are for an audience who are not developers and would have no idea how to begin to build from source code a program that is already ported to his platform, le
Re: (Score:2)
If your computer happens to be something other than a Mac, a Mac app runs at zero speed.
QT, GTK, WXWidgets, & etc solve this problem.
Provided the application's publisher has the staff to build and QA the application in Qt for Windows, Qt for macOS, Qt for GNU/Linux, Qt for iOS, and Qt for Android. Many especially smaller publishers do not. And even if the developer distributes an application as free software and says "here's an app that works on GNU/Linux; feel free to port this", end users who aren't programmers are by and large unwilling to learn to program so that they can spend hours excising the developer's inadvertent platform-depe
The demise of PNaCl is really unfortunate. (Score:5, Interesting)
The demise of PNaCl is really unfortunate.
"WebAssembly" is a virtual machine; it might as well be named "JVM".
PNaCl pushed down partially compiled code so that a compiler backend could localize it to Native code on the local machine. It used LLVM IMF (effectively) to implement ANDF -- Architecture Neutral Distribution Format, which was a promise Apple was never able to achieve -- which is why Apple has "Fat Binaries": single binaries with multiple images.
NaCl, by contrast, targeted a specific binary instruction set in the target, and people would use different wrappers for the actual code itself, via JavaScript, to select the architecture (ARM, x86, etc.) of the actual binaries being downloaded in NaCl form.
The question is whether you do the finalization work on the sender, or the receiver. Both systems, however, had as their primary intent the ability to extend JaveScript with native code plugins.
In the absolute limit, you'd write all your code in native code, and then ship it down with a small JavaScript shim, in order to call into that code's "main" with a thread context, and set it running as native code.
There are a number of Games which did this, and there's a (moderately common) use of NaCl to push down x86 games running in a PC emulator as a packaged lump in NaCl.
PNaCl -- which was platform independent -- and NaCl, which I would say has arguably failed as well -- failed because it was massively difficult to develop applications in it.
This is predominantly because there is insufficient glue code and no IDL in order to define JavaScript interfaces which also described C/C++ code containers for the compilers used to generate the native code on the front end.
This made it impractical to have what is -- in essence -- a browser-level jandboxed "JNI" equivalent for JavaScript.
So people simply didn't use it.
In other words, it was not a complete product, and like Mozilla in the early days, it was nearly impossible to build anything useful out of it that actually did anything that had any impact on anything.
NaCl -- apparently not (yet) deprecated -- still has this problem.
Think of it as having DCE or Sun RPC available as an interface between JavaScript and native code, and having no "rpcgen" and no "xdr" library available to use.
This is pretty typical of some Google products: they go 80% of the way there, and then, because they are organizationally not motivated to do things which are difficult -- because you can pretty much walk to any other job inside Google, should your manager ask you to do something you considered "unfun" -- no one finishes the remaining 20%.
I tried to resolve this in my 20% time at Google, but was rather constantly thwarted in the effort (the 20% time at Google is largely mythical) by providing an IDL in XML that would let you describe the interfaces, and then generate the JavaScript templates on one end, and the C code containers for the functions that needed to be written on the other, along with an "XDR" library for marshaling arbitrary data back and forth between the "C form" and the "externalized JavaScript" form.
Sadly, this project never came to fruition -- I was even, stupidly was writing it in Python, to make it politically acceptable to the people who were complaining the loudest, when I could have cranked it out in C in a couple of days -- Python is really slow/bad at XML, among other problem.
Personally, I think this deprecation and switch is a terrible idea.
Putting a bytecode interpreter into your browser is exactly what malware sites want you to do, when they bitch about you needing to install the Java plugin into your browser.
WebAssembly is exactly that, only renamed from "Java", and not uninstallable or turn-offable.
Massively bad mistake.
The only saving grace is that I have no doubt that it will be "about as popular as NaCl/PNaCl", and it'll stop at 80% of the way to "people are now likely to use this thing to do their projects".
Re: (Score:1)
It's not a mistake if you want applications that do not only run on chrome.
Re: (Score:1)
I think the only people who care about this are Mozilla, Inc..
Are you claiming that this is going to also be implemented in Safari or Microsoft Edge (the only othe browsers that matter)?
Re: (Score:3)
> Putting a bytecode interpreter into your browser is exactly what malware sites want you to do
There is already an execution engine in your browser --- JS. WebAssembly applications can do exactly the same set of things that JS can do, so there's no new problem.
Furthermore, PNaCl was pretty much the same from this point of view, or actually worse because it added quite a lot more attack surface than WebAssembly does (both in Pepper and all the LLVM code).
Re: (Score:2)
Furthermore, PNaCl was pretty much the same from this point of view, or actually worse because it added quite a lot more attack surface than WebAssembly does (both in Pepper and all the LLVM code).
Incorrect. The PNaCl (and NaCl) attack surface was intermediated by what a web site was permitted to do through JavaScript.
It would have been substantially more useful, and dangerous, had that not been the case.
The question is whether the JIT'ed code in WebAssembly is going to be smarter about sandboxing than Crome itself currently is (I don't see how that can be the case; there are already OnClick based persistent DOM's that are created by malicious sites to pop up advertisements -- and they defeat the sa
Re: (Score:2)
Putting a bytecode interpreter into your browser is exactly what malware sites want you to do, when they bitch about you needing to install the Java plugin into your browser.
I feel like this is a stupid question, so this is probably over my head, but why is a bytecode interpreter worse on this front than an a compiler likewise accepting arbitrary code from the Internet?
Re: (Score:1)
Putting a bytecode interpreter into your browser is exactly what malware sites want you to do, when they bitch about you needing to install the Java plugin into your browser.
I feel like this is a stupid question, so this is probably over my head, but why is a bytecode interpreter worse on this front than an a compiler likewise accepting arbitrary code from the Internet?
The issue is the ability to create outbound connections /not/ through WebSockets, and the ability to interpose and modify code on its way down.
The advantage of WebSockets is that it has to connect to a server on the site where the script originated, in order to make an outbound socket connection. This makes it difficult to make a self-propagating attack vector, or a SPAM engine hidden in a game, and utilizing your outbound connection in order to relay SPAM in such a way as to distribute a SPAM engine, or a
Re: (Score:1)
Putting a bytecode interpreter into your browser is exactly what malware sites want you to do, when they bitch about you needing to install the Java plugin into your browser.
WebAssembly is exactly that, only renamed from "Java", and not uninstallable or turn-offable.
Man, you really have no clue what you're talking about. WebAssembly is just a more efficient (as in: more compact) serialization of asm.js, which itself is a subset of EcmaScript.
So everything "bad" you claim you can do with wasm, you can already do with plain EcmaScript, only instead of text, the script source is now binary, so it wastes less bandwidth during page load.
WebAssembly lacks signing (Score:2)
Re:WebAssembly lacks signing (Score:4, Informative)
WebAssembly doesn't allow your code to do anything more than what normal JavaScript can do. It's really just a faster way to run JavaScript. It's not any kind of major shift except for allowing faster apps to be developed. There's really no need for signing as you wouldn't sign JavaScript either.
Re: (Score:2)
Re: (Score:2)
As ActiveX showed, code signing is useless in practice unless you require all code to be signed by some trusted third party. But the whole point of the Web is to avoid having a single gatekeeper.
On the other hand, running untrusted code in a sandbox is a model that has worked for JS, and it will work for WebAssembly too.
Re: (Score:2)
Yes, and Java showed the same thing.
Just because you might know who signed the applet, that does not mean you should let them take over your user account.
The TLS endpoint signs what it sends (Score:2)
Not only does WebAssembly not require packages to be signed
Every response sent over an HTTPS connection is signed by the TLS endpoint sending it. This includes js files and wasm files.
I'm no chemist but... (Score:1)
Oh hooray, a new Flash implementation to break (Score:2)
Chemistry (Score:2)
Re:More vulnerabilities (Score:4, Informative)
WebAssembly is a byte code for a virtual machine. It's not native.
PNaCl is a byte code for a virtual machine, with an interfaces based on an earlier native virtual container (NaCl).
these are secure if virtualization is complete. but all known implementations are still susceptible to row hammer as it's too difficult a problem to solve for VM implementers.
Wasm lacks Oracle control (Score:5, Insightful)
The advantage of WebAssembly over Java is that the former isn't owned by One Rich American Called Larry Ellison.
If there's more than one implementation of a particular platform released as free software, these implementations can compete on security. Chromium is free software, supports JavaScript, and will support WebAssembly. Likewise with Firefox.
But we didn't get that opportunity with Java or Flash. Last I checked, the license of the Java Language Specification prohibited publishing an incomplete implementation. This requirement to keep works-in-progress confidential within an organization in turn had the effect of keeping independent free implementations of Java from existing legally, ultimately leading to Oracle v. Google. Likewise, Adobe's SWF spec was intended for developers of tools that output SWF, and its license specifically banned using the spec to make a third-party SWF player until February 2009 [wikipedia.org].
Re: (Score:3)
" former isn't owned by One Rich American Called Larry Ellison". You didn't state that properly: " former isn't owned by One Rich Asshole Called Larry Ellison"
Re: (Score:2)
.. One Rich Asshole Called Larry Ellison
Who has his own personal Hawaiian effing Island [wikipedia.org]. This is 'Merica. Success in business is the only thing that matters and the ends justify the means.
I have got to get outta here. I'm getting too damn cynical.
Re: (Score:2)
it's pure FUD to bitch that the Java license didn't allow you to call your product 'Java' unless it provided a defined base of stuff. Would you foam at the mouth about Larry Wall if he reacted negatively to a company releasing a language that was only half like perl but named 'perl 4'?
It's not that the license didn't let you call it Java. It's that the license didn't let you distribute it at all under any name.
In the very early days other vendors (OK, mostly IBM) created their versions of Java and they're still at it.
A company as big as IBM can afford to do the entire reimplementation in-house. A group of hobbyist developers, like those who started the Wine project, isn't in quite the position to do so.
Re: (Score:2)
WebAssembly is a byte code for a virtual machine. It's not native.
Eh... Oberon slim binaries format is a byte code for a virtual machine. But the code does run as native, because slim binaries are just a platform-independent and compact Oberon program representation. I presume WebAssembly does exactly the same thing.
Re: (Score:2)
Who cares? If it runs, it's ultimately native. However virtual/interpreted/non-native it claims to be, you have to trust the vm / interpreter / native code it ultimately runs as to enforce the rules of the language and keep you safe. And we all know that's not gonna happen.
PNaCl and NaCl are *not* virtual machines! (Score:5, Informative)
PNaCl and NaCl are *not* virtual machines!
Yes, they are sandboxed, but they are sandboxed by constraining the assembly language generated.
PNaCl differs only in that it sends the intermediate compiled code down to the browser to be processed in the final LLVM stage backend into assembly language within the browser.
The major reason for deprecating it is that a compiler back end is a lot to carry around for little benefit.
The reason the benefit is small, however, has less to do with PNaCl itself, and a lot more to do with how Google handles projects within Google, and my inability to actually pry my 20% time -- that I was promised when I was hired -- out of Google to do work on the problem.
I talk about it in another post.
Sandbox defects (Score:2)
Which means that a defect in the verifier that enforces "constraining the assembly language generated" in NaCl or "the final LLVM stage backend" of PNaCl would lead to a sandbox escape.
Re: (Score:2)
Re: (Score:2)
The MMU doesn't prevent a process from making a syscall that reads all the user's files and opens a socket to disclose them to a computer in a different country with no extradition treaty between the two. Whether to honor such a syscall is entirely up to whatever kernel- or user-level sandbox program is running, and such programs can have defects.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Indeed, it's a virtual machine in the most generic sense. I consider a process in Unix to be a virtual machine too, but my education in CS goes back many years and it's no longer fashionable to use VM in this sense.
Re: (Score:2)
The problem is that NaCl exists.
This was a solution in search of a problem. The problem in theory being "downloading precompiled binaries" like linux rpm's.
The actual problem that NaCl was originally sold to address was the ability to put video decoding and other expensive operations into native code. In other words, it was the equivalent of a JNI escape to native code.
There are performance reasons for this, but the primary one is video distribution with DRM and/or forced interposition of commercials, as a revenue model.
One of the examples they used to demo it was adding "native" mathematics package to the JavaScript in the browser to vaslty accelerate math o
Re: (Score:2)
When I saw the title I first thought that the article was about PhosphorusSodiumChlorate.
Re: (Score:2)
Re: (Score:1)
Should be phosphorus sodium chloride.
Re: (Score:2)
You are right, was a few decades ago I did chemistry.
Assume you refer to vowels by "a,e,i,o,u and sometimes w and y (at be if of up cwm by)", here it's "a,o,u,å,e,i,y,ä and ö" but never w. w and v are the same here.
Re: (Score:2)
Of course, it only applies to English.
I was taught the "sometimes w and y" part in grammar school. I was surprised to discover decades later that w was no longer being taught, at least according to a couple of students I asked. The list is just to demonstrate that all of them can be the only vowels in words, but w is used in m
JavaScript enhances some web applications (Score:5, Informative)
We should be going the opposite direction and eliminating JavaScript altogether.
Though I agree with you and others that JavaScript has been abused, I disagree that the web ought to throw the proverbial baby out with the bathwater. In some cases, JavaScript dramatically improves the user experience in web applications. It makes others possible in the first place.
Say you want to let a user fill out a web form, but you don't want the poor experience associated with having to fill out the entire form and then perform a form submission and full page reload to catch the most common entry errors. The common way to improve the user's experience is by sending a short script that prevalidates the entries before the server validates them authoritatively, letting the user fix things before they're submitted.
Say you want to offer a chat service, where users send short strings of up to 100 characters or so to a channel and other users in the same channel receive them. You might consider putting up an IRC server, but your prospective users lack privileges to permanently install an IRC client on the devices that they use. You might try to do this as a web application without JavaScript, but you'll have to rely on users remembering to repeatedly click a "Check for New Messages" button to reload the iframe containing recent messages sent to a channel, which is a poor experience for users. In this case, the least bad option is a web application with a script that waits for new messages to arrive through a WebSocket and appends them to the list of recent messages.
Say you want to develop a real-time video game and allow members of the public to play it, but Valve, Apple, and the major console makers have turned your game down for one reason or another. So instead, you decide to offer the video game as a web application. The only interactivity possible without script is a form submission followed by a full reload of a page or iframe, but that's not possible for a real-time game. Thus script is again least bad.
If you're not convinced, I have more examples.
Re: (Score:2)
No, I'm not convinced and no further examples are needed. If you can not secure the code -- and there is no chance whatsoever that you can -- the technology is not suited to an internet used for financial, business, shopping, voting, or command and control applications.
If you can figure out a way to limiting scripting to harmless endeavors like entertainment, chatting and gaming, then fine. But depending on the judgment and good sense of web designers not to u
Re: (Score:2)
The common way to improve the user's experience is by sending a short script that prevalidates the entries before the server validates them authoritatively, letting the user fix things before they're submitted.
If you can not secure the code -- and there is no chance whatsoever that you can -- the technology is not suited to an internet used for financial, business, shopping, voting, or command and control applications.
Nothing is perfectly secure. But catching errors early and providing immediate feedback may help make "financial, business, shopping, voting, or command and control applications" easier to use without running the risk of inadvertent incorrect input, as may rich application-specific input controls.
Not everything can/should be implemented on web (Score:3)
I'm not convinced that client-side calculation is a good thing in the cases you list because what you call "a form submission and a full page reload" doesn't strike me as tedious, too long, or generally bad. I think that the most commonly used web browsers have made a horribly bad tradeoff by allowing ad-hoc downloaded code to be executed client-side and have full access to the user's computer. I'm distinguishing between code one has a chance to run, study, modify, and share (free software browser code) and
Re: (Score:2)
I'm not convinced that client-side calculation is a good thing in the cases you list because what you call "a form submission and a full page reload" doesn't strike me as tedious, too long, or generally bad.
Then good luck clicking point-by-point to trace a path in a web-based drawing application that uses a server-side image map, with the entire image reloading after each click.
If you need form validation, bring up your needs to people who discuss CSS and perhaps you can find a way to do regular expression-based validation with a regex parser that's not as powerful as PCRE but sufficiently powerful to tell if this phone number or credit card number is likely to be valid.
Once you make an input schema language rich enough to handle all possible interdependencies among fields in a form, such as "state/province/region" being required only for certain values of "country", you will probably have almost reinvented JavaScript.
Programmers have always accepted that not every program can run in every environment or be implemented with every programming language. It's time privacy and security get higher priority and people learn to say no due to considered tradeoffs. Technical limitations of this sort can be right and proper to have.
I disagree with your claim that it is "right and proper to have", for example, users
Re: (Score:1)
So the real problem is that the device is so locked down that the user can't install IRC. Shouldn't have bought it if you wanted any rights like that. If everyone knew better, eventually they would sell one you could install IRC on. If you are unprivileged because your employer won't allow you to install software, maybe you shouldn't be.
There is already a program or two for chatting. Why do I need it in my web browser?
The real problem is that most of us that know Javascript sucks, are not developing alterna
Re: (Score:2)
So the real problem is that the device is so locked down that the user can't install IRC. Shouldn't have bought it if you wanted any rights like that. If everyone knew better, eventually they would sell one you could install IRC on.
The problem is that someone who offers a service and wants more than a negligible share of paying users has to interoperate with devices purchased by people who did not know better at the time they purchased their respective devices. Their prospective users are unwilling to buy a new device and a new Internet access subscription for said new device just to run one application. That or they bought a device to do something else, and because it also includes a web browser, anything that runs on the web platfor
Re: (Score:2)
An increasing amount of JS is now machine generated - transcompiled from something else. That might be something light like Typescript but it could also be Dart, GWT, C/C++ via Empscripten etc. Even with asm.js the performance still sucks and since it's machine generated code there is a de
Re: (Score:2)
JavaScript dramatically improves the user experience in web applications.
If pages were to just validate data or swap out same-sized elements, then it might be okay. What they usually do is dynamically load content and perform transitions, which WRECKS the experience.
My biggest beef with dynamic content is that it almost always changes the size of the page, screwing up your scroll bars, reading position, and generally just resulting in things jumping all over the place. I usually scroll pages by clicking and dragging the scroll bar, and with so much dynamic content all over the
Re: (Score:2)
Why would anyone want JavaScript to run natively in assembly? Sounds like a ton of vulnerabilities waiting to happen. We should be going the opposite direction and eliminating JavaScript altogether.
I infer that the desire for native bytecode is so that malware from websites can run more efficiently and not hog our CPUs.
I don't know why you've been downmoded, You're absolutely correct. Expanding internet attack surfaces is possibly the worst idea since the US decided to fix the Middle East by invading Iraq. Getting rid of ALL scripting would be one modest step toward getting the digital world under control. Sometimes I think mankind has a deathwish.
Re: (Score:2)
Getting rid of ALL scripting would be one modest step toward getting the digital world under control.
This means every form of interactivity on the Web that cannot be efficiently performed through form submission and full page reloads would have to move to a native app, and native apps are specific to one operating system. Good luck running a native Mac app on anything that's not a Mac.