> A nice-looking bytecode doesn't seem worth the loss of backwards compatibility. The encoding is ugly, but compatibility with existing browsers seems like such a huge win for something that really just amounts to a…
Laziness. It, like all other non-public services, should be hidden behind a VPN that reduces the attack surface to the absolute minimum. Ideally you should use something like OpenVPN's PSK HMAC support, which reduces…
I'd say Firefox is a pretty good example of how open-source can counter the issue of monoculture by providing the industry a viable platform from which they can challenge the incumbent browser.
The big difference is that nobody insisted that ARM stay instruction-level compatible with x86.
That's also not what I said. You have a reading comprehension problem.
When I started, there was no web. The historical context is quite a bit broader, and it helps to understand what the state of the technology was. When the browser war was fought (and won): - Netscape Navigator was…
Open-source doesn't make the problem go away, but it does make the problem surmountable.
No, I'm saying that open-source solves most of the issues with a monoculture, while also being more effecient than vendor standardization when it comes to pushing forward innovation.
Open-source counters most of the issues around monoculture. Remeber that the first browser wars occurred between two closed source products. In fact, I think that a single OSS project is far more effecient than attempts…
> Do we need all the power a PC provides natively to make great games? I think the market has declared this to be a definitive "yes". Users don't want to waste their hardware dollars so that you can spend them on…
As a hiring manager for over a decade, I can't recall the last time I received a resume from a qualified female applicant for a full-time software position. Internships tend to be a bit less one-sided, but the skew is…
> We never had access to the use of SIMD intrinsics in browsers in the first place, anyway. For that, use native. Yes, exactly. I want it all: native performance, security, open platform. Google is making attempts…
That's why I said "entire browser". Page rendering, font rendering, <canvas>, et al, are the interesting bits. The use of XUL and the resulting UI clunkiness (speed, responsiveness, nativeness) are pretty well…
> It is not a VM that accepts binary bytecode as input, which is what the person I am replying to wanted. Context matters. And you could have read that yourself.- Er, so? > One could argue quite successfully…
I believe the ideal (for users) would be to target NaCL natively, with a fallback to server-side PNaCL compilation, and an absolute fallback to PNaCL compilation/execution.
I'm not sure what you're trying to prove; javascript runtimes are VMs too. Java was designed poorly, and it performed poorly. It just so happens that its design was well-suited to long-running servers, however, so…
I'm not a fan of a future in which the only people that can do interesting things (including the use of SIMD intrinsics) are the platform vendors (eg, Mozilla), while the rest of us live in a JavaScript sandbox. Maybe…
> You assert this, but you haven't provided evidence. Web application developers are providing great user experiences. Are you serious, or are you really just that out of touch with how we work on desktop and mobile…
At the expense of battery life and performance as _compared to native applications_.
> iOS and Android are successful because they offer a great selection of powerful APIs, not because of the particular binary representation they use for applications. They also provide great battery life and…
'Very acceptable' speed isn't what consumers are looking for when comparing battery life and wall-clock performance between competing platforms.
For a desktop and/or mobile app, on which the consumer is waiting and you are burning battery (laptop/phone) or just simply CPU cycles, 2x-4x slower is 'not fast'. You're simply wasting the end-users time and resources…
Funny you should mention that, given that I just this week had to use NEON intrinsics to eek out better user-visible wall-time performance in a native app.
Bad is the enemy of good, too. Mobile platforms have being pretty successful, too.
Now I'm very curious what you think that purpose is.
> A nice-looking bytecode doesn't seem worth the loss of backwards compatibility. The encoding is ugly, but compatibility with existing browsers seems like such a huge win for something that really just amounts to a…
Laziness. It, like all other non-public services, should be hidden behind a VPN that reduces the attack surface to the absolute minimum. Ideally you should use something like OpenVPN's PSK HMAC support, which reduces…
I'd say Firefox is a pretty good example of how open-source can counter the issue of monoculture by providing the industry a viable platform from which they can challenge the incumbent browser.
The big difference is that nobody insisted that ARM stay instruction-level compatible with x86.
That's also not what I said. You have a reading comprehension problem.
When I started, there was no web. The historical context is quite a bit broader, and it helps to understand what the state of the technology was. When the browser war was fought (and won): - Netscape Navigator was…
Open-source doesn't make the problem go away, but it does make the problem surmountable.
No, I'm saying that open-source solves most of the issues with a monoculture, while also being more effecient than vendor standardization when it comes to pushing forward innovation.
Open-source counters most of the issues around monoculture. Remeber that the first browser wars occurred between two closed source products. In fact, I think that a single OSS project is far more effecient than attempts…
> Do we need all the power a PC provides natively to make great games? I think the market has declared this to be a definitive "yes". Users don't want to waste their hardware dollars so that you can spend them on…
As a hiring manager for over a decade, I can't recall the last time I received a resume from a qualified female applicant for a full-time software position. Internships tend to be a bit less one-sided, but the skew is…
> We never had access to the use of SIMD intrinsics in browsers in the first place, anyway. For that, use native. Yes, exactly. I want it all: native performance, security, open platform. Google is making attempts…
That's why I said "entire browser". Page rendering, font rendering, <canvas>, et al, are the interesting bits. The use of XUL and the resulting UI clunkiness (speed, responsiveness, nativeness) are pretty well…
> It is not a VM that accepts binary bytecode as input, which is what the person I am replying to wanted. Context matters. And you could have read that yourself.- Er, so? > One could argue quite successfully…
I believe the ideal (for users) would be to target NaCL natively, with a fallback to server-side PNaCL compilation, and an absolute fallback to PNaCL compilation/execution.
I'm not sure what you're trying to prove; javascript runtimes are VMs too. Java was designed poorly, and it performed poorly. It just so happens that its design was well-suited to long-running servers, however, so…
I'm not a fan of a future in which the only people that can do interesting things (including the use of SIMD intrinsics) are the platform vendors (eg, Mozilla), while the rest of us live in a JavaScript sandbox. Maybe…
> You assert this, but you haven't provided evidence. Web application developers are providing great user experiences. Are you serious, or are you really just that out of touch with how we work on desktop and mobile…
At the expense of battery life and performance as _compared to native applications_.
> iOS and Android are successful because they offer a great selection of powerful APIs, not because of the particular binary representation they use for applications. They also provide great battery life and…
'Very acceptable' speed isn't what consumers are looking for when comparing battery life and wall-clock performance between competing platforms.
For a desktop and/or mobile app, on which the consumer is waiting and you are burning battery (laptop/phone) or just simply CPU cycles, 2x-4x slower is 'not fast'. You're simply wasting the end-users time and resources…
Funny you should mention that, given that I just this week had to use NEON intrinsics to eek out better user-visible wall-time performance in a native app.
Bad is the enemy of good, too. Mobile platforms have being pretty successful, too.
Now I'm very curious what you think that purpose is.