Hacker News Reader

Comment by overgard | Hacker News Reader

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!"

View on HN

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.

The next logical step is Diablo in CSS3.

That made me giggle. I'm sure someone is working on it.

This is done in canvas, but a lot of games are done in CSS3 - using 3D transforms and CSS animation, it's very feasible.

Of course, it's much harder to do a game in pure CSS, like this crazy thing http://jsdo.it/GeckoTang/4rXg

Agreed. The worst part is that, as far as I can tell, this isn't actually Diablo. So we can't even claim a foothold on 1997.

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.

This link wasn't submitted by the author, FWIW

Well that IS pretty neat that a browser can do what a 1997 desktop can do. Browsers are much more portable than a 1997 desktop.

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".

This works pretty nice in the most used browser in the world (Chrome last release), that is a win in my book.

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 do believe that Windoze stopped being most used operating system in the world (hint: android)

Dead Space 3 wasn't created by 1 person in their spare time. But by all means, don't let that temper your cynicism.

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"

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.

To keep on rolling and flip the statement again, it seems closer to "look, I can build Tetris on my wristwatch":

in order to make your statement, you have to ignore the state of a web browser running on a 1997 vintage desktop.

And the "purpose" that the "web" was serving back then.

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.

The me in 1997 would be pretty happy to know that the game would be playable by virtually every computer user in the world by clicking a link.

Well, every user using Chrome.

With a reasonably modern computer and internet access.

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."

/postmodernity

I was doing that in Smalltalk in 1995.

Or that javascript has caught up with what you could do in flash about 10 years ago. ;)

If this isn't a comment about the project, then maybe you could step off the soapbox.

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?

The desktop equivalent, CU-SeeMe, was working in 1994.

Even older, perfect for devaluing JS! The similarity is truly shocking.

http://en.wikipedia.org/wiki/File:CUcollaboration.gif

http://www.teknoblog.com/wp-content/uploads/2012/07/gmail-go...

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.

> speed, lag and buffering was horrible at the time

That has nothing to do with the software and everything to do with the network, no?

Of course not.

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.

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.

The latest comparative performance of 2D drawing in one runtime vs another doesn't have anything to do with my argument.

> 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.

Reply on news.ycombinator.com