skatepark

18 ms·

1.
by skatepark 14y ago
The big difference is that nobody insisted that ARM stay instruction-level compatible with x86.
2.
by skatepark 14y ago
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 actually a pretty terrible
3.
by skatepark 14y ago
Open-source doesn't make the problem go away, but it does make the problem surmountable.
4.
by skatepark 14y ago
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.
5.
by skatepark 14y ago
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 at standardization a
6.
by skatepark 14y ago
> 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 inefficient solutions
7.
by skatepark 14y ago
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 still quite high. This
8.
by skatepark 14y ago
> 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 to tackle this, Mozi
9.
by skatepark 14y ago
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 known. A world in whic
10.
by skatepark 14y ago
> 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 that one of the chief
11.
by skatepark 14y ago
> ... imagine where we will be in another 15 years time. We'll be 15 years behind the PCs of 15 years from now[1]. [1] Unless something changes drastically in the web stack.
12.
by skatepark 14y ago
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.
13.
by skatepark 14y ago
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 that's where it's used.
14.
by skatepark 14y ago
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 Mozilla should try wri
15.
by skatepark 14y ago
> 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 apps? > What
16.
by skatepark 14y ago
At the expense of battery life and performance as _compared to native applications_.
17.
by skatepark 14y ago
> 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 user-visible performance (
18.
by skatepark 14y ago
'Very acceptable' speed isn't what consumers are looking for when comparing battery life and wall-clock performance between competing platforms.
19.
by skatepark 14y ago
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 for what amounts to i
20.
by skatepark 14y ago
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.
21.
by skatepark 14y ago
Bad is the enemy of good, too. Mobile platforms have being pretty successful, too.
22.
by skatepark 14y ago
We'd also need a full widget toolkit, set of foundation/standard libraries, and all the other functionality we take for granted on other platforms. With all that in place, then I'd use whatever reasonable (JS isn't) language existed as a no
23.
by skatepark 14y ago
Now I'm very curious what you think that purpose is.
24.
by skatepark 14y ago
Instead, it's a small bit of complexity levied against every single link in the chain, including the user (performance). Which basically describes the entire stack of hacks that have been built on top of the web.
25.
by skatepark 14y ago
You're a web developer, yes? In my circles NaCL is looked at with interest because there's no way possibly for us to produce apps to the level of quality we do elsewhere -- and without a huge amount of pain -- while using the web's organica
26.
by skatepark 14y ago
The web is the most widely used document platform in the world. And no, it's not a robust application development platform. Working with it is an exercise in constant compromise between bad technologies and the quality of the user experienc
27.
by skatepark 14y ago
> But asm.js is usable in all browsers immediately. asm.js is just JS. A magic JS-based bytecode that's usable in all browsers immediately isn't useful if it isn't fast. Which it isn't, because it's a JS-based bytecode executing under
28.
by skatepark 14y ago
> Because backwards compatibility is really important. x86, the Windows API, TCP, IPv4, and Unix (compared to Plan 9) are all examples of things that are full of cruft, but they persist because they have the right survival characterist
29.
by skatepark 14y ago
Meanwhile, you web guys are throwing away the last 30 years of progress on consumer application development, and starting from scratch. Web apps are not documents.
30.
by skatepark 14y ago
> In reality, that goal was achieved ;-) This ... has not been my experience. And I write a lot of high-performance native and Java code. > For dynamic languages, if you want decent performance, all the known techniques require J

More ›