131–140 of 143 posts
Earlier quoted context omitted.
Now we just need to wait for someone to run Rhino on this so we can have Javascript hosting a JVM which hosts Javascript.
Nashorn would be more appropriate once it is released. It leverages the JVM dynamic invocation instructions better IIRC.
Earlier quoted context omitted.
>we're stuck in a perpetual game of filling up spare CPU cycles with nothing in particular. There are lots of CPU cycles, and plenty of cases where trading a few for increased flexibility makes a ton of sense.
Not to the users who sit around watching swirlies and beachballs. They don't care what rad, flavor of the month framework you used to build your software. Websites and desktop apps were more responsive in 1998 than they are today* *In general and not supported by facts of any kind other than my own anecdotia.
You should not use virtual runtimes for everything your application does but using them in overnight cronjobs is ok.
Right now we are working on some middleware because the customers wants to use existing reporting tools(c#/windows only) with our product(perl/linux).
>Look how fast and simple this is! > >Yeah nice so how do I genearte my reports? > >Well we can do the same with our reporting service! > >No I want to keep my based reports can you integrate those?
Really cool hack, and yet I can't help but think that the mile-high software stack between the developer and the CPU continues to grow meaning we're stuck in a perpetual game of filling up spare CPU cycles with nothing in particular. I'm sure I'll see a demo showing off something that barely runs on modern hardware that we were more than capable of running with good performance in 1990. sigh I feel like I'm being suc…
Now we just need to wait for someone to run Rhino on this so we can have Javascript hosting a JVM which hosts Javascript.
Really cool hack, and yet I can't help but think that the mile-high software stack between the developer and the CPU continues to grow meaning we're stuck in a perpetual game of filling up spare CPU cycles with nothing in particular. I'm sure I'll see a demo showing off something that barely runs on modern hardware that we were more than capable of running with good performance in 1990. sigh I feel like I'm being suc…
Really cool hack, and yet I can't help but think that the mile-high software stack between the developer and the CPU continues to grow meaning we're stuck in a perpetual game of filling up spare CPU cycles with nothing in particular. I'm sure I'll see a demo showing off something that barely runs on modern hardware that we were more than capable of running with good performance in 1990. sigh I feel like I'm being suc…
Why can't this be used to replace all of the java applets or allow java back into the browser? I know there were security issues before with native Java, perhaps JS sandboxed Java could solve the security issues.
Earlier quoted context omitted.
Seems like the "reimplemented" portions are bits that need to interact directly with the script environment -- String is implemented in terms of V8's native strings, etc... That seems like a feature, not a bug -- you wouldn't want the interpreter needlessly doing bytewise diddling of an abstraction that is already very robust in the host environment.
In the Java Class Library, any function that needs to interact with the environment outside of the JVM itself (OS/file system/network/threading/etc.) is implemented in C and is marked as 'native'. Those are the functions that we explicitly implement for the JavaScript/browser environment. You are right that we could extract more performance by mapping particular classes directly onto efficient browser functionality -…
Earlier quoted context omitted.
This question on this kind of topic needs to stop being asked on Hacker News. It's fair to ask whether or not there was a material usage intended for the project, but if isn't one, we really need to stop implying that there should be.
that's not a chance I'm willing to take. This is how PHP started. It was a reject experiment that escaped the lab. Then some poor souls took it seriously. Now all of humanity suffers.
Earlier quoted context omitted.
Why can't this be used to replace all of the java applets or allow java back into the browser? I know there were security issues before with native Java, perhaps JS sandboxed Java could solve the security issues.
Java applets are more powerful than any web browser API (you can't get at USB devices from the web browser except through a plugin, for example). BankID (used for banking and electronic payment in the Nordic countries by almost every bank) makes use of this to do validation with a USB device to authenticate based on bank card.
Not yet, we can't. Mozilla is working on the WebUSB[0] API that'll allow access to USB devices via javascript as part of their ongoing WebAPI effort. They need this for FirefoxOS at some point, and these APIs are being implemented in desktop Firefox as well.