Not a commentary on this project per se, but I can't help but think when I see "X in javascript" voted up that the implicit frame is: "isn't it impressive what you can do in javascript now?"
But if you flip that statement on its head, the equivalent is "The web has finally caught up with what we could do on a 1997 desktop!"
I've had this sentiment from 1996 on. I worked for a company creating Internet materials for use in classrooms (Internet-on-CD, books, etc.). I remember seeing a "frog dissection" thing on a website and everyone seemed to impressed with it. Why? You'd click a gif, it'd run a CGI and deliver a new image. Just what you could do with actual clients, just slower, more limited, and lower resolution.
There's something neat about "X in Y" for some technical novelty (like emulators) but I don't get the excitement in general.
This has been stated a million times, and I'm not even a "web developer" like the majority here seems to be, by my take is this: not needing a client is the win.
There's a huge amount of value, as perceived by "users" of the services/applications/games, in not having to care about and install a specific client for each service/application/game.
That's why it's noteworthy when something that used to require a heavliy specialized client, such as a game, no longer does for delivering the same experience.
I like the Github description: 'Isometric minimal-code style game at html5 canvas and javascript'. I guess Diablo is being used as a shorthand for that.
In theory they are but most "Look what we can do with JavaScript now!" posts are quickly followed by "only works correctly in Chrome Canary" or "only works correctly in latest Firefox nightly".
And the original worked pretty nicely in the most used operating system in the world (Windows), when it was released. But pointing this out just proves my original point that the openness of web standards isn't all that it is cracked up to be.
The code is pretty much open (even commented and well organized) and It can fairly easy be changed to SVG to support pretty much every modern browser. Open enough for me.
I meant it as a commentary on celebrating javascript in general, not on this person's project.
It's not cynicism I feel, it's dissatisfaction. I /want/ to use the web for powerful things, but the limitations of javascript make many of those things impractical. Hence my ambivalence towards "x in javascript"
Java applets, Native Client, and ActiveX all (imperfectly) address this problem.
We have long had trouble agreeing on a standard for web-based native code. But that doesn't mean that it's a senseless request. The exalted status of Javascript is merely a convenient local optimum.
What exactly makes it impractical to do powerful things? You may have disdain for certain language features but I don't understand how that makes it impractical.
Most of the tech demo's we're seeing coming out of the JS crowd are from people who have only just started using the WebGL API (which is still experimental). I'm extremely excited to see the things that experienced OpenGL developers will be able to do as the API becomes more mainstream.
Neither was this. Let's face it a clone is much different from creating a game from scratch. Not only that, but Dead Space 3 would be a far more complicated game to create than Diablo, even starting from scratch.
The implicit frame of the implicit frame might be "so let's move everything into the browser".
Look at it from the perspective of someone who just wants to use a computer for something a computer could do in 1997. Doing it in a browser today would still sometimes be a downgrade from doing it in a (well written) native application in 1997.
I am eager to seeing how much of a difference asm.js can make.
I totally agree that doing something ins browser today would be worse than the 1997 era native app equivalent....
... but to agree with a sibling comment: wow-- you can just download the code in, like 10 min? And I can read/modify it it because it doesn't even have to be compiled to run?
These were both two very big limitations on my user experience in 1997...
I'm not saying that we should move back to having everything run on a mainframe, but I suppose that in response to the "so what" I was responding to I offer "wow, man: there is something way different going on in a port of a technology than there is in the original."
Yeah, only now with javascript we can transmit HD videos in realtime via webcam with Chrome or Firefox, just like in 1997... no wait... the cherry picking of an example went wrong on that one. But maybe we can still devalue Javascript by saying HD videos is a separate thing and that speed connections is more important than Javascript in that example?
That argument works for anything, as long as you can convince the browser vendors to implement support for it and provide it as an api. So I would argue that's much closer to the definition of cherry picking an example.
So I guess I can't talk about the DOM; many functions are just an API for it; and canvas is just an API for drawing accelerated by the CPU; so... Javascript is nothing and nothing can be blamed on it?
I'm just saying that the provision of video streaming as a web api is not a particularly technically interesting development. It's just a gradual beefing up of the browser as a thin client. And until support for the features are widespread, it's not really a commercially interesting development either.
I would class many of the other things you mention as incremental improvements of the rendering engine as a universal runtime. It's great that it's happening but it's not technically that exciting to me to see reimplementations of 16 year old games since we've had the flash runtime in the interim anyway.
Broken argument; flash is way too slow compared to the current version of Canvas; recently I made a full conversion of flash to canvas (was painful but) the performance is outstanding and the ability to interact natively and play nice with the DOM is invaluable.
> I'm just saying that the provision of video streaming as a web api is not a particularly technically interesting development. It's just a gradual beefing up of the browser as a thin client. And until support for the features are widespread, it's not really a commercially interesting development either.
You mean P2P connections? Oh we have that now in Firefox and Chrome. You mean video chats? Oh we have that. You mean thousands of libraries to create and develop videogames for the web? Oh we have that. You mean easily extensible browsers via plugins/extension? Oh we have that. I need you to be very specific about what we are lacking.
What the html platform is lacking? My last project was built around QT, OpenGL, CUDA and made extensive use of various C based linear algebra libraries and was ~20kloc of C++. I'm sure it could be reimplemented as a web app but it would be a strange decision to do so.
But that wasn't my point. My point was that just because the web allows you to do things that were possible on the desktop 10+ years ago doesn't make it interesting to me. And the fact that you can always add specific functionality to the runtime like video conferencing doesn't really address that.
I don't have to wait for browser vendors, I just start coding.
I tried it circa 1998. I wouldn't call it "working" even then.
Not to mention it needed installation (Javascript just needs people to go to a specific page), and the speed, lag and buffering was horrible at the time.
Even on the same network, different conference apps have different characteristics. It depends on the compression and coded they use, how they handle changes in network performance, etc.
Plus the GUI and UX of that app was simply horrible.
But if you flip that statement on its head, the equivalent is "The web has finally caught up with what we could do on a 1997 desktop!"