Linked by Kroc Camen on Fri 2nd Apr 2010 14:01 UTC
Web 2.0 In November last year I stated that it would only be a matter of time before it happened. Also in November Joel Webber, a Google engineer had the inspiration to port Quake II to HTML5 from Jake2--a Java port of Quake II--using Google Web Toolkit; the same toolkit used for writing Google Mail | Maps | Wave in Java and compiling into JavaScript. With the help of two other Google engineers (Ray Cromwell and Stefan Haustein) in "20% time", it works! Just!
Order by: Score:
Security implilcations.
by Bill Shooter of Bul on Fri 2nd Apr 2010 15:02 UTC
Bill Shooter of Bul
Member since:
2006-07-14

That's a lot of new stuff that hasn't been vetted by security gurus. A lot of new attack surface, that's more closely integrated with the host.

Its cool, yes, but it makes me shiver to think of all of the security implications.

Reply Score: 7

RE: Security implilcations.
by Kroc on Fri 2nd Apr 2010 15:14 UTC in reply to "Security implilcations. "
Kroc Member since:
2005-11-10

And you’d rather Apple choose which Apps are “secure” and which ones are not?

I’d rather have all this stuff in the open where anybody can prod and poke it and _find_ and _reveal_ the real security holes.

BTW, the recent Firefox security flaw (for which 3.6.2 was issued) was because of a lack of security testing on the font library that was pulled in, that was never designed to handle files randomly coming off the web; so the concern is definitely legitimate, but then Mozilla let that slip because of weak security testing of a new component and hopefully they will learn from that.

Reply Score: 1

Bill Shooter of Bul Member since:
2006-07-14

And you’d rather Apple choose which Apps are “secure” and which ones are not?


Oh,Hell no. I want that like I want a kick to the groin.


Just hoping that this stuff is being reviewed by security researchers at the design phase.

Reply Score: 4

RE[3]: Security implilcations.
by flanque on Fri 2nd Apr 2010 22:42 UTC in reply to "RE[2]: Security implilcations. "
flanque Member since:
2005-12-15

I think we've seen enough evidence that these reviews don't stand the test of time. It might get passed now but for sure there'll be some form of security breach with any complex technology and this is certainly going to be very complex.

Reply Score: 2

Bill Shooter of Bul Member since:
2006-07-14

Any thoughts of security in the design phase of a spec, are better than none. Nothing is perfect, but that doesn't stop anyone from doing their best.

Reply Score: 2

RE[2]: Security implilcations.
by Mr.Manatane on Sat 3rd Apr 2010 07:50 UTC in reply to "RE: Security implilcations. "
Mr.Manatane Member since:
2010-03-19

Aha ! The same bullshit argument saying that because everybody can see the code, it's more safe.

I have a news for you, as everybody can see the code, it's also easier for a bad hacker to find security holes and don't tell anybody about what he found...

Reply Score: 0

dragSidious Member since:
2009-04-17

Anybody can see the code on a closed source application, also.

It's not like 'binary' is this mystical mush that is undescipherable to human-like.

Machine code, like source code... is just that: code. Removing access to the human-written source code makes things more difficult, but it does not make it even remotely impossible or impractical to find flaws in it.

It just makes it impossible and impractical to fix problems that get found unless your the original developer.

Just look at the most popular ways people's computers are hacked. Internet Explorer, Adobe Flash, Adobe Reader, etc etc... Not having the source code has not slowed anybody down much when it comes to "owning" your computer.

Reply Score: 1

Mr.Manatane Member since:
2010-03-19

Yeah and you can say the same for Linux. Just as the last big security holes which was present on all linux kernel from 2.4 to 2.6 all releases ...
It wasn't faster to find the security hole which has been there since many years.

And it's much easier to read source code than binary.

If you say the contrary:
1. you are in bad fait
2. then prove it and stop using high level languages (C, C++, Python etc ...) to make your software ...

Reply Score: 1

RE[5]: Security implilcations.
by WereCatf on Sat 3rd Apr 2010 12:53 UTC in reply to "RE[4]: Security implilcations. "
WereCatf Member since:
2006-02-15

Just as the last big security holes which was present on all linux kernel from 2.4 to 2.6 all releases ...

All OSes have bugs, you know? There is not a SINGLE OS on the whole planet without a bug somewhere. And besides, Windows too has quite big bugs there but being closed source has not stopped anyone from finding them; quite the contrary, it only stops people from patching them.

Reply Score: 2

abstraction Member since:
2008-11-27

There is actually a bugfree OS. I dont remember the name of the company that created it but I think it was australian. They mathematically verified it to be bugfree. It can be done by using special language semantics that makes it side-effect free (it basically means that given a set of input it will always reply with the same output). Functional programming languages like Standard ML and Haskell are very good at that.

Reply Score: 1

RE: Security implilcations.
by kaiwai on Sat 3rd Apr 2010 07:55 UTC in reply to "Security implilcations. "
kaiwai Member since:
2005-07-06

That's a lot of new stuff that hasn't been vetted by security gurus. A lot of new attack surface, that's more closely integrated with the host.

Its cool, yes, but it makes me shiver to think of all of the security implications.


And that is the thing; with more testing, more stress testing of technologies - hopefully the weaknesses are exposed early so they can be addressed. Take ActiveX, by itself, it is a great piece of technology but it took at least 10 years before Microsoft finally locked down ActiveX.

Reply Score: 2

Bill Shooter of Bul Member since:
2006-07-14

Oh dear Lord, did you just say active X *is* great? As the creator of many active X controls, I'd have to disagree. It *was* the best solution, when you were dealing with a MS only environment in the late 90's early 00's, but its dead Jim. And, I really think Microsoft could have done something better. It really didn't become secure, until it was obsolete because the priority of security at microsoft didn't really exist until 2004 or so.

Reply Score: 2

No code protection
by nt_jerkface on Fri 2nd Apr 2010 15:16 UTC
nt_jerkface
Member since:
2009-08-26

Javascript also isn't highly valued by web developers.

But it does a good job of showing the potential of HTML5.

Reply Score: 2

RE: No code protection
by Kroc on Fri 2nd Apr 2010 15:22 UTC in reply to "No code protection"
Kroc Member since:
2005-11-10

I suppose Native Client will help those who don’t want to provide the source. It’ll be faster to boot too; I can’t see it getting adoption outside of Chrome though. The last thing Apple wants is native code being delivered outside of the App Store.

Reply Score: 1

RE[2]: No code protection
by nt_jerkface on Fri 2nd Apr 2010 16:44 UTC in reply to "RE: No code protection"
nt_jerkface Member since:
2009-08-26

Server-side processing with output to HTML5 would do the trick. This also means that the game engine wouldn't have to be coded in javascript.

Developers would flock to such a framework because it would be cross-platform and insulted from piracy.

Reply Score: 2

RE[3]: No code protection
by twitterfire on Fri 2nd Apr 2010 18:00 UTC in reply to "RE[2]: No code protection"
twitterfire Member since:
2008-09-11

Server-side processing with output to HTML5 would do the trick. This also means that the game engine wouldn't have to be coded in javascript.

Or even better, cgi or .net on server side with H.264 output.

edit:

It's not good to run code on the server: imagine what if some 100 000 users want to play same time?

The best way is using java or silverlight.

Edited 2010-04-02 18:01 UTC

Reply Score: 3

RE[4]: No code protection
by nt_jerkface on Fri 2nd Apr 2010 19:08 UTC in reply to "RE[3]: No code protection"
nt_jerkface Member since:
2009-08-26


It's not good to run code on the server: imagine what if some 100 000 users want to play same time?

The best way is using java or silverlight.


I think a mix is probably the best, have a client to share some of the processing but make it useless to pirate.

But if we're talking about replacing 2D iphone games a single dedicated server can handle plenty of players.

Reply Score: 2

RE[3]: No code protection
by kaiwai on Sat 3rd Apr 2010 07:59 UTC in reply to "RE[2]: No code protection"
kaiwai Member since:
2005-07-06

Server-side processing with output to HTML5 would do the trick. This also means that the game engine wouldn't have to be coded in javascript.

Developers would flock to such a framework because it would be cross-platform and insulted from piracy.


So hypothetically speaking when it comes to native code, Microsoft could have a native code back end for Microsoft Office and then the output would appear as HTML5? I remember hearing about COM support being added to Silverlight - is that the possible future, the front end being delivered to the end user via Silverlight with the native processing occurring on a server farm at Microsoft HQ?

Reply Score: 2

RE[4]: No code protection
by dragSidious on Sat 3rd Apr 2010 12:31 UTC in reply to "RE[3]: No code protection"
dragSidious Member since:
2009-04-17

It's hard to tell if your all being sarcastic or just being ignorant.

Microsoft has exposed the COM to expose 'native code' to the internet.

It's called ActiveX and it sucks huge donkey dick. It's just a really bad idea and causes all sorts of horrificly bad things to go on in the web.

I am sure that Chrome's 'native code' is not as horrible as ActiveX (as Google engineers are not huge f-ng morons like the ActiveX architects were), but there is no need to do anything like that.

ECMAscript is ugly and it's not fun, but it's a complete programming language that is just about as capable as any other high-level programming language anybody would care to embed in the browser.

It's now relatively fast with modern JIT compiling technics and whatnot and it's been around, in one form or another, for decades now and is supported and used by not only browsers, but a ton of different applications.

so that is why that if people had a chance to do it all over they would choose something else ecmascript is still a win for web-based applications.

Reply Score: 1

RE[4]: No code protection
by nt_jerkface on Sat 3rd Apr 2010 19:21 UTC in reply to "RE[3]: No code protection"
nt_jerkface Member since:
2009-08-26

I remember hearing about COM support being added to Silverlight - is that the possible future, the front end being delivered to the end user via Silverlight with the native processing occurring on a server farm at Microsoft HQ?


That is a likely future but I doubt they would use COM. They'd probably rewrite large parts of the office engine to run on the server and then build the interface in Silverlight. It would likely be a subscription service as well.

Edited 2010-04-03 19:22 UTC

Reply Score: 2

RE: No code protection
by beta.services on Fri 2nd Apr 2010 16:30 UTC in reply to "No code protection"
beta.services Member since:
2009-02-27

"Javascript also isn't highly valued by web developers."

That is so true. I think the issue is the level of understanding amongst web developers of what JavaScript can really do. Most don't think past DHTML.

I has taken me over 10 years of professional web development to realise how powerful JavaScript can really be.

A lot of it has been because that as web developers, we develop around the idea that web users can disable JavaScript within their browsers. The thinking has been why put effort into something you can't control?

But finally, I think, we are coming to a point where the lowest common denominator is no longer our target demographic. Viva La Web!

Reply Score: 1

RE: No code protection
by galvanash on Fri 2nd Apr 2010 17:16 UTC in reply to "No code protection"
galvanash Member since:
2006-01-25

Javascript also isn't highly valued by web developers.


That is completely true, and it is also a crying shame. Modern versions of Javascript are quite powerful and there is more work being put into optimizing performance for them than virtually any other interpreted language. Most developers never see past the basic DOM model and don't really delve into the language itself - they just use it as a tool for doing DOM manipulation and thats it, more or less treating it like a macro language.

I'm not claiming it is the most beautiful language ever designed, but it does have most if not all the features needed to write code using virtually any programming paradigm you can think of (OO, procedural, functional, event driven, etc.)

I personally prefer Python, but I would have to concede that for its intended purpose Javascript is probably a better language. I have always been curious if a Python implementation of a browser scripting language could be competitive performance-wise, but from what I have seen I highly doubt it. Python is beautiful, but Javascript is practical (and fast relatively speaking).

Reply Score: 2

RE: No code protection
by marcosebastian on Fri 2nd Apr 2010 23:15 UTC in reply to "No code protection"
marcosebastian Member since:
2010-01-29

Really man? Might want to check that twice. I'm a Web Developer, and I value Javascript highly.

Reply Score: 1

Belated April Fools?
by beta.services on Fri 2nd Apr 2010 15:48 UTC
beta.services
Member since:
2009-02-27

The original article was posted on April 1st. Anyone verified its authenticity?

Because i would hate to think that this site was regurgitating april fools cranks on april 2nd (3rd here in aus)

I really dont want to have to write off this site for the whole week from my calendar next year.

Reply Score: 1

RE: Belated April Fools?
by Kroc on Fri 2nd Apr 2010 15:52 UTC in reply to "Belated April Fools?"
Kroc Member since:
2005-11-10

Er, the video, the screenshots (which I took), and the compilation instructions, including link to the Google code site with the full source code isn’t good enough?

I mean, porting Quake II to HTML5 for real, for an April fools joke is pretty high on the effort-required scale for just a prank. Anyway, the article said that this has been under development since November last year.

Reply Score: 1

v Its an 1. April fool!
by theuserbl on Fri 2nd Apr 2010 15:52 UTC
RE: Its an 1. April fool!
by Kroc on Fri 2nd Apr 2010 15:55 UTC in reply to "Its an 1. April fool!"
Kroc Member since:
2005-11-10

I’VE PLAYED THE GAME. IN MY BROWSER. I COMPILED THE THING FROM SOURCE AND UPLOADED SCREENSHOTS.

What more proof do you want! You can go compile and play it yourself.

The reason the whole code was checked in yesterday was because it’s a public site, duh, and they wanted to hold back and not let anybody find out until they were ready.

Reply Score: 3

RE[2]: Its an 1. April fool!
by Dekonega on Fri 2nd Apr 2010 23:06 UTC in reply to "RE: Its an 1. April fool!"
Dekonega Member since:
2009-07-28

I've made a HD video of the thing...
http://www.youtube.com/watch?v=OZR_m8pBYcU

It's not a joke. ;)

Reply Score: 1

javascript... sigh...
by FunkyELF on Fri 2nd Apr 2010 17:24 UTC
FunkyELF
Member since:
2006-07-26

Anybody else wish you could run Python in a web browser?

There are people wanting to get javascript on the server.... I think it would be better to get PHP or Python in the web browser.

Reply Score: 2

RE: javascript... sigh...
by twitterfire on Fri 2nd Apr 2010 18:06 UTC in reply to "javascript... sigh..."
twitterfire Member since:
2008-09-11

Anybody else wish you could run Python in a web browser?


I don't think so, but I wish we can run native x86 in the web browser.

Though being realistic I have to be pleased that at least I can run .net in the web browser.

Reply Score: 2

RE[2]: javascript... sigh...
by Kroc on Fri 2nd Apr 2010 18:07 UTC in reply to "RE: javascript... sigh..."
Kroc Member since:
2005-11-10
RE[2]: javascript... sigh...
by WereCatf on Fri 2nd Apr 2010 18:21 UTC in reply to "RE: javascript... sigh..."
WereCatf Member since:
2006-02-15

I don't think so, but I wish we can run native x86 in the web browser.

And lock out all non-x86 platforms, including the millions of different portable devices both those that exist already and those that will come? Wow, sounds like an excellent plan. Oh, wait..

Reply Score: 3

RE[3]: javascript... sigh...
by Zifre on Fri 2nd Apr 2010 21:48 UTC in reply to "RE[2]: javascript... sigh..."
Zifre Member since:
2009-10-04

And lock out all non-x86 platforms, including the millions of different portable devices both those that exist already and those that will come? Wow, sounds like an excellent plan. Oh, wait..

That's why I wish we could run LLVM in the browser ;)

Reply Score: 3

RE[4]: javascript... sigh...
by WereCatf on Fri 2nd Apr 2010 21:53 UTC in reply to "RE[3]: javascript... sigh..."
WereCatf Member since:
2006-02-15

Heh, just wait, someone will implement that too sooner or later! ;)

Reply Score: 2

RE[4]: javascript... sigh...
by Timmmm on Sat 3rd Apr 2010 00:28 UTC in reply to "RE[3]: javascript... sigh..."
Timmmm Member since:
2006-07-25

Already being done. Portable Native Client uses LLVM bytecode:

http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf

That will be awesome.

Reply Score: 2

Big Windbag Comment
by fretinator on Fri 2nd Apr 2010 17:25 UTC
fretinator
Member since:
2005-07-06

We are getting closer to what I have always believed was an inevitability - where stuff resides shouldn't matter to users or developers (ignoring security for the moment!).

What do I mean?

Well, a long time ago, and far, far away, the CD-ROM was a new technology. It was a big deal for programs to be able to access information from this medium. They were "multimedia aware" applications. Standards were written. As Biden would say, it was a BFD. You had to specifically code your application to be able to access the data on this mystical storage medium.

Presently, the CD-ROM is just one of many removeable media. Entire operating systems can run off of one. It's no longer a BFD. I've always felt this would one day be true of the Web. Java brought some of this, where Applets could access data just by URL's. Web Services have brought us closer, as has AJAX. Web 2.0 if a BFD.

Soon, though, data will just live where it lives. Applications will run from wherever. And the developer and the end user will not even think about. It will no longer be a BFD.

So, besides health care reform, what's the next BFD for computing? I'm thinking maybe OpenDOC...

Reply Score: 2

RE: Big Windbag Comment
by Thom_Holwerda on Fri 2nd Apr 2010 17:26 UTC in reply to "Big Windbag Comment"
Thom_Holwerda Member since:
2005-06-29

So, besides health care reform, what's the next BFD for computing?


Thin clients, of course. Duh!

Reply Score: 2

RE[2]: Big Windbag Comment
by fretinator on Fri 2nd Apr 2010 18:00 UTC in reply to "RE: Big Windbag Comment"
fretinator Member since:
2005-07-06

Reminds me, the other day I saw a guy taking notes with a hand-held lead device on a flattened, wood by-product. He was able to easily combine graphics and text, consumed very little power (totally wireless), and utilized persistent storage. I was amazed.

Reply Score: 5

RE[3]: Big Windbag Comment
by AaronD on Sat 3rd Apr 2010 00:32 UTC in reply to "RE[2]: Big Windbag Comment"
AaronD Member since:
2009-08-19

Did he use a graphite-based stylus or a petroleum-based one?

Reply Score: 1

RE[4]: Big Windbag Comment
by fretinator on Sat 3rd Apr 2010 04:30 UTC in reply to "RE[3]: Big Windbag Comment"
fretinator Member since:
2005-07-06

I think it was graphite, and it had the backspace key on the top of the stylus.

But seriously, I am a Computer Science student (over 50) with several laptops, including a netbook. Nevertheless, due to the small desks, and the mixture of symbols in the notes (e,g, calculus), I have found a good mechanical pencil and a notepad to be the best note-taking device.

However, if Apple want to send me an iPad (like they do the editors, here), I would be willing to try in out in class!

Reply Score: 2

This is a no go
by twitterfire on Fri 2nd Apr 2010 17:57 UTC
twitterfire
Member since:
2008-09-11

However, none of the technologies in use here having left draft status. I would put it at around two years before this technology (and games using it) arrive in the hands of the public via mainstream releases of Safari, Chrome and Firefox. But those innovating will be ready to hit the ground running.


What technologies are you talking about? WebGL? HTML 5?

I think that the porting of Quake 2 to javascript is just a show-off, a proof of concept. I don't really think that Google engineers consider javascript the way to go for web games.

Any kid who even doesn't finished the most elementary IT class yet, knows that javascript is a interpreted language ans as such, it sucks badly in terms of performance. Even worse, it's interpreted by a web browser, a software not known for it's remarkable focus on performance. Trying to write a game in javascript, if not done as a proof of concept, is as stupid as trying to write a game in bash.

There are far better technologies such as java and silverlight.

Reply Score: 2

RE: This is a no go
by Kroc on Fri 2nd Apr 2010 18:03 UTC in reply to "This is a no go "
Kroc Member since:
2005-11-10

So, you’ve done how much work with JavaScript?

1. Performance of JS has increased 1000 fold in the last two years. It can be as fast as 50% native speed in some cases.

2. “Try writing a game in JavaScript". Glad you said that, because I have. Multiple times. And guess what? It’s plenty fast enough. I don’t have anything finished enough to show, but here’s something better than I can do as an example: http://www.megidish.net/awjs/

Java is dead. Silverlight will follow eventually, for the same reasons as Flash. Not everything will support it and HTML5 will allow developers to target everything in one go.

EDIT. Forget my gumpf, have you realised the idiocy of saying that JavaScript isn’t fast enough for games, when you’re commenting on a thread ABOUT QUAKE 2 RUNNING ENTIRELY IN JAVASCRIPT. Good grief.

Edited 2010-04-02 18:06 UTC

Reply Score: 1

RE[2]: This is a no go
by twitterfire on Fri 2nd Apr 2010 18:19 UTC in reply to "RE: This is a no go "
twitterfire Member since:
2008-09-11


2. “Try writing a game in JavaScript". Glad you said that, because I have. Multiple times. And guess what? It’s plenty fast enough. I don’t have anything finished enough to show, but here’s something better than I can do as an example: http://www.megidish.net/awjs/


I was talking about real games such as Crysis, Assassin's Creed, Dragon Age, Grand Theft Auto and so on. Not about the next breathtaking Tic Tac Toe, Tetris and Hangman.



Java is dead. Silverlight will follow eventually, for the same reasons as Flash. Not everything will support it and HTML5 will allow developers to target everything in one go.

Java is not dead, that is just wishfull thinking on your behalf. Tell that java is dead to millions of companies and individuals who are developing and using java software. Silverlight is near anywhere as dead. Silverlight is just at the beginning.


EDIT. Forget my gumpf, have you realised the idiocy of saying that JavaScript isn’t fast enough for games, when you’re commenting on a thread ABOUT QUAKE 2 RUNNING ENTIRELY IN JAVASCRIPT. Good grief.


I was talking about 2010 games, sorry if smart people like you consider idiotic anything that is less than 15 years old.

Reply Score: 2

RE[3]: This is a no go
by WereCatf on Fri 2nd Apr 2010 18:25 UTC in reply to "RE[2]: This is a no go "
WereCatf Member since:
2006-02-15

I was talking about real games such as Crysis, Assassin's Creed, Dragon Age, Grand Theft Auto and so on. Not about the next breathtaking Tic Tac Toe, Tetris and Hangman.

No one would write those in Java or Silverlight either, so your point is quite moot.

Reply Score: 2

RE[4]: This is a no go
by twitterfire on Fri 2nd Apr 2010 18:36 UTC in reply to "RE[3]: This is a no go "
twitterfire Member since:
2008-09-11


No one would write those in Java or Silverlight either, so your point is quite moot.

No one cared to write them in Java or Silverlight, but Java and Silverlight are much reasonable game platforms than javascript. At least since some professional games are/were written in .net, why can't they be written using Silverlight API? Add some DirectX bindings to SIlverlight, and voila, you're on your way.

Reply Score: 3

RE[5]: This is a no go
by vivainio on Fri 2nd Apr 2010 18:43 UTC in reply to "RE[4]: This is a no go "
vivainio Member since:
2008-12-26

At least since some professional games are/were written in .net, why can't they be written using Silverlight API?


What do you mean by "professional games"? People are paid to write games with JME, are they "professional games" as well?

Reply Score: 2

RE[5]: This is a no go
by WereCatf on Fri 2nd Apr 2010 18:55 UTC in reply to "RE[4]: This is a no go "
WereCatf Member since:
2006-02-15

No one cared to write them in Java or Silverlight, but Java and Silverlight are much reasonable game platforms than javascript. At least since some professional games are/were written in .net, why can't they be written using Silverlight API? Add some DirectX bindings to SIlverlight, and voila, you're on your way.

Both Java and Silverlight were designed with being overall more capable than Javascript but Javascript has been closing the gap very fast lately, and I am sorry but I just have to disagree with you.

And what has .net to do with the discussion? Does those "professional" games run in the browser across several different platforms? No? Then they have no place in this discussion.

Reply Score: 2

RE[6]: This is a no go
by raboof on Fri 2nd Apr 2010 22:52 UTC in reply to "RE[5]: This is a no go "
raboof Member since:
2005-07-24

Both Java and Silverlight were designed with being overall more capable than Javascript but Javascript has been closing the gap very fast lately


Ummm... no?

JavaScript still sorely lacks a type system - which in turn limits the IDE's (many IDE features depend on type information being present). Also, the available libraries are nowhere near what's available for Java (not sure about Silverlight).

EcmaScript 4 had a lot of promise, but sadly got side-tracked...

Edited 2010-04-02 22:52 UTC

Reply Score: 2

RE[4]: This is a no go
by nt_jerkface on Fri 2nd Apr 2010 19:17 UTC in reply to "RE[3]: This is a no go "
nt_jerkface Member since:
2009-08-26

I was talking about real games such as Crysis, Assassin's Creed, Dragon Age, Grand Theft Auto and so on. Not about the next breathtaking Tic Tac Toe, Tetris and Hangman.

No one would write those in Java or Silverlight either, so your point is quite moot.


Well the framework isn't there yet to build those games so your point is moot as well.

When that framework is available it won't be HTML5. It will be a proprietary plug-in like Silverlight that offers more than client side Javascript.

Reply Score: 2

RE[3]: This is a no go
by Kroc on Fri 2nd Apr 2010 18:30 UTC in reply to "RE[2]: This is a no go "
Kroc Member since:
2005-11-10

I was talking about real games such as Crysis, Assassin's Creed, Dragon Age, Grand Theft Auto and so on.


And I’m talking about real games like Bejewelled and Farmville that have more users than those games and make just as big bucks.

Tell that java is dead to millions of companies and individuals who are developing and using java software.


Java is dead for gaming, like we were discussing, ne?

I was talking about 2010 games


I thought we were discussing JavaScript being fast enough for games, which it is. I’ll grant you that there aren’t many games written in JavaScript because _so many developers are still hung up on IE_. But it’s not that it isn’t possible—and Quake II in HTML5 should raise eyebrows and get interest going in developing games in the browser, which I’ve known has been possible since Firefox 3.

Reply Score: 2

RE[4]: This is a no go
by nt_jerkface on Fri 2nd Apr 2010 19:28 UTC in reply to "RE[3]: This is a no go "
nt_jerkface Member since:
2009-08-26

I’ll grant you that there aren’t many games written in JavaScript because _so many developers are still hung up on IE_. But it’s not that it isn’t possible—and Quake II in HTML5 should raise eyebrows and get interest going in developing games in the browser, which I’ve known has been possible since Firefox 3.


It has nothing to do with IE. Flash and Silverlight provide a better framework for games and that would be true even if IE didn't exist. HTML5 will improve but so will Flash and Silverlight.

Reply Score: 2

RE[5]: This is a no go
by Kroc on Fri 2nd Apr 2010 20:38 UTC in reply to "RE[4]: This is a no go "
Kroc Member since:
2005-11-10

But Flash and Silverlight will never be on the iPad, and like it or hate it, the commercial world so, so badly wants a bit of that pie.

Reply Score: 0

RE[6]: This is a no go
by nt_jerkface on Fri 2nd Apr 2010 23:43 UTC in reply to "RE[5]: This is a no go "
nt_jerkface Member since:
2009-08-26

I think the commercial world will be sticking with the itunes store for the next few years. Cross-browser compatibility isn't everything.

But it will be interesting to see the HTML5 apps that hobby developers create. Just don't expect a web app revolution like so many claimed would happen with Ruby on Rails.

Reply Score: 2

RE[4]: This is a no go
by moondevil on Fri 2nd Apr 2010 20:47 UTC in reply to "RE[3]: This is a no go "
moondevil Member since:
2005-07-08


Java is dead for gaming, like we were discussing, ne?


Oh, and no one told me nothing about it

http://www.runescape.com/
http://www.nordgame.com/
http://www.banghowdy.com/
http://www.gamerendering.com/Imperii/
http://www.madskillsmotocross.com/
http://ghook.speedrungames.com/

not to name all the games being developed for J2ME, Android, and all the studios now using Java/JOGL for their tools.

Reply Score: 2

RE[5]: This is a no go
by Kroc on Fri 2nd Apr 2010 21:03 UTC in reply to "RE[4]: This is a no go "
Kroc Member since:
2005-11-10

I concede, I'm wrong, I had forgotten Android development!

Flash has been the mainstay for cross platform gaming for a few years, and I have every reason to believe a big battle for the gaming space is now brewing. Apple are cutting off Flash in favour of Cocoa. Adobe are trying to push Flash on mobile devices. Java will always be there, as it basically always has been. Microsoft are trying to build a new lock in ecosystem with Silverlight / .NET / XNA / DirectX after their old lock in IE failed, and HTML5 will be aggravate the lot of them in the long run.

Edit: Oh—and Nintendo are seeing the first serious competition in the mobile space they’ve seen in ages. The iPhone may only represent a tangential threat to Nintendo’s market, but it has definitely lowered the price consumers expect for a game.

Edited 2010-04-02 21:10 UTC

Reply Score: 1

RE[5]: This is a no go
by Dekonega on Fri 2nd Apr 2010 23:11 UTC in reply to "RE[4]: This is a no go "
Dekonega Member since:
2009-07-28

You forgot the best www-browser based java game ever made.

Minecraft:
http://minecraft.net/

Reply Score: 1

RE[4]: This is a no go
by Lennie on Sun 4th Apr 2010 10:15 UTC in reply to "RE[3]: This is a no go "
Lennie Member since:
2007-09-22

I really want HTML5 to succeed, but to be honest people have been doing games in activex/directx in IE for over 10 years. I think someone created some extensions for flash to do the same with directx as well, can't remember. You can load compiled VB or C (not the VBscript-kind) in IE through .htc-behaviours as well.

But it's all proprietary.

It's W3C which is slow, even Mozilla had a proposal for XBL-behaviours which didn't get accepted, I'm really glad we are making progress now though.

Reply Score: 2

RE[2]: This is a no go
by Lennie on Sun 4th Apr 2010 10:08 UTC in reply to "RE: This is a no go "
Lennie Member since:
2007-09-22

It's not entirely running in the browser, it's running on the server, like gmail. Just everything that is needed to get the visual part to the browser has been done. Just have a good look at what Google Web toolkit really does. It offloads as little as possible to the browser.

EDIT: typos

Edited 2010-04-04 10:28 UTC

Reply Score: 2

RE[3]: This is a no go
by Kroc on Sun 4th Apr 2010 10:22 UTC in reply to "RE[2]: This is a no go "
Kroc Member since:
2005-11-10

They compiled the one-player mission statically. No server computation involved.

Reply Score: 1

RE[4]: This is a no go
by Lennie on Sun 4th Apr 2010 10:30 UTC in reply to "RE[3]: This is a no go "
Lennie Member since:
2007-09-22

Ohh, ok, my misunderstanding I guess, but I still wonder why then run it on localhost:8080 ? Why not just dump the static code in a directory and serve it from a any webserver ?

Edited 2010-04-04 10:36 UTC

Reply Score: 2

RE[5]: This is a no go
by Kroc on Sun 4th Apr 2010 14:27 UTC in reply to "RE[4]: This is a no go "
Kroc Member since:
2005-11-10

The localhost:8080 thing is because you run the dedicated server to enable multiplayer and because Quake just runs like that. Nothing is ideal here because it’s a C app that’s been ported to Java and then transcoded into JavaScript. If you were writing a game in HTML5 from scratch you certainly wouldn’t do it this way, and it could be written to run from a folder much easier ;)

Reply Score: 1

RE: This is a no go
by vivainio on Fri 2nd Apr 2010 18:24 UTC in reply to "This is a no go "
vivainio Member since:
2008-12-26

Any kid who even doesn't finished the most elementary IT class yet, knows that javascript is a interpreted language ans as such, it sucks badly in terms of performance.


Javascript implementation can be interpreted of compiled (JITted). E.g. Chrome runs all javascript as native code.

It may be that the Canvas implementation is what's slowing things down here. With opengl, this would probably be pretty snappy.

There are far better technologies such as java and silverlight.


If you are willing to go for Silverlight, you could as well go all the way and make a normal, native Windows game.

Reply Score: 3

RE[2]: This is a no go
by twitterfire on Fri 2nd Apr 2010 18:29 UTC in reply to "RE: This is a no go "
twitterfire Member since:
2008-09-11


If you are willing to go for Silverlight, you could as well go all the way and make a normal, native Windows game.


I'm not willing to go for anything since I prefer native games and I think that every software should do only one thing and do it good: the browser should display web pages, the video player should play movies, the audio player should play music and the damn games should be native.

I was just pointing that if somebody wants games to run as web applications, there are much better choices than javascript which is not meant for games or anything that has to do with performance.

Reply Score: 2

RE: This is a no go
by raboof on Fri 2nd Apr 2010 23:01 UTC in reply to "This is a no go "
raboof Member since:
2005-07-24

Any kid who even doesn't finished the most elementary IT class yet, knows that javascript is a interpreted language ans as such, it sucks badly in terms of performance. (...) There are far better technologies such as java and silverlight.


Of course natively compiled code is much faster compared to interpreted code. However, Java and Silverlight don't contain natively compiled code either: their 'binaries' consist of bytecode that has to be run by a Virtual Machine, too.

Compiling source to bytecode beforehand might give Java and Silverlight a bit of a head-start, but after that the interpretation/JIT-compilation techniques are not all that different.

A difference is JavaScript is much more 'dynamic' than the typed Java/Silverlight code - the VM can leverage the typing information to perform optimalizations on Java/Silverlight, this is much harder with JavaScript

Reply Score: 2

RE: This is a no go
by computrius on Sat 3rd Apr 2010 00:13 UTC in reply to "This is a no go "
computrius Member since:
2006-03-26

Why does everyone lump java in the same category as flash and silverlight?

Flash and silverlight are browser extensions.

Java is a full fledged virtual machine/language/api for making desktop applications as well as applications that can run in a browser. What silverlight and flash do is only a small subset of what java does.

Edited 2010-04-03 00:20 UTC

Reply Score: 2

RE[2]: This is a no go
by raboof on Sun 4th Apr 2010 13:36 UTC in reply to "RE: This is a no go "
raboof Member since:
2005-07-24

Java is a full fledged virtual machine/language/api for making desktop applications as well as applications that can run in a browser. What silverlight and flash do is only a small subset of what java does.


Indeed Java is more powerful than Flash/AIR.

But when Java applets and JavaFX are entering the 'web applications' arena, they will have to compete with Flash and Silverlight, and a comparison is justified. Java has an advantage for being such a full-fledged platform, but this also comes with a cost (e.g. slow start-up times).

That said, Java and Flash/ActionScript are not really in the same ballpark in terms of language maturity and availability of libraries. I'm not so sure about Silverlight: doesn't that allow you to talk to any .Net code? That would make it quite similar to Java.

Reply Score: 2

RE[3]: This is a no go
by Kebabbert on Tue 6th Apr 2010 10:23 UTC in reply to "RE[2]: This is a no go "
Kebabbert Member since:
2007-07-27

Several big stock exchanges with ultra low latency and extreme performance demands are developed on Java. Java is foremost for the server, and then for the client.

Reply Score: 2

RE[4]: This is a no go
by raboof on Tue 6th Apr 2010 10:29 UTC in reply to "RE[3]: This is a no go "
raboof Member since:
2005-07-24

Several big stock exchanges with ultra low latency and extreme performance demands are developed on Java. Java is foremost for the server, and then for the client.

No argument there - for example slow start-up times are no problem in such situations, it's throughput and fail-safety that matters. The browser/client arena is simply a whole different ballpark.

Reply Score: 2

RE: This is a no go
by ceekay on Sat 3rd Apr 2010 05:58 UTC in reply to "This is a no go "
ceekay Member since:
2006-02-09

nice troll.

Reply Score: 2

Comment by abstraction
by abstraction on Fri 2nd Apr 2010 22:23 UTC
abstraction
Member since:
2008-11-27

What the hell is going on. Can someone just take a step back and look at this and say. Wait a minute. What are we doing here. We started out with a browser that rendered html nicely. It was simple and had a well-defined purpose. Then we added javascript to stur things up a bit and then css and a bunch of more little things again and again and now we have a broowser that can play quake. Shit what should we add next? I know. Let's add a f--king particle accelerator. Why? I don't know. But it is coooool.

Reply Score: 2

RE: Comment by abstraction
by strcpy on Sat 3rd Apr 2010 12:40 UTC in reply to "Comment by abstraction"
strcpy Member since:
2009-05-20

Completely agreed.

The WWW, The Big Regression in Computing, BRC.

Of course the cool kids here are delighted to see over ten year old crap being run in a browser. Kind of shows the current state of affairs.

And it is even funnier that all the Javascript, and Silverlight, and Flash crap comes over again. But no one questions that it is totally idiotic to put more and more crap to into WWW to begin with.

Reply Score: 2

RE[2]: Comment by abstraction
by abstraction on Sat 3rd Apr 2010 17:09 UTC in reply to "RE: Comment by abstraction"
abstraction Member since:
2008-11-27

Totally. Do one thing and do it well as the saying go.

Reply Score: 1

RE: Comment by abstraction
by hefbe on Sat 3rd Apr 2010 18:03 UTC in reply to "Comment by abstraction"
hefbe Member since:
2010-04-02

In my opinion this article just demonstrate the potency of HTML5.

Reply Score: 1

why Homebrew over MacPorts?
by hefbe on Fri 2nd Apr 2010 22:45 UTC
hefbe
Member since:
2010-04-02

I'm curious to know why you used Homebrew instead of Macports. Is it lighter or it's just you couldn't resist novelty? ;)

Reply Score: 1

RE: why Homebrew over MacPorts?
by Kroc on Sat 3rd Apr 2010 05:56 UTC in reply to "why Homebrew over MacPorts?"
Kroc Member since:
2005-11-10

Didn’t want to mess up my filesystem. I’m picky about installing stuff into the UNIX area that is too oversized and difficult to maintain and operate. Brew is just a folder and plays nicely with Apple’s layout. MacPorts is a giant dump on your drive with it’s own opinion on how to run the shop.

Reply Score: 1

RE[2]: why Homebrew over MacPorts?
by hefbe on Sat 3rd Apr 2010 14:52 UTC in reply to "RE: why Homebrew over MacPorts?"
hefbe Member since:
2010-04-02

Fair enough. Also, I think you forgot to mention this is for Intel Macs only.

Reply Score: 1

Big Picture - ChromeOS
by Technocracy on Sat 3rd Apr 2010 22:13 UTC
Technocracy
Member since:
2006-01-08

Get your development theories here:

Google Engineer suddenly ports Qukae II to web browser - get stuffed... This was a planned stunt. ChromeOS will be able to play games quite adequately through their OS. Much like OnLive

http://www.onlive.com/

The games etc will be hosted on their servers so no need to worry about security. Any documents and personal data that need to keep secure will keep on one server - data that does not have to be keep secure will be kept on another server (on one of the many gabillion servers).

You will not need to worry about a browser being insecure and data being accessed on your hard drive because the data will not be on your hard drive, it will be on Google's.

Marketing hype that's all this is... while being very cool at the same time ;)

Reply Score: 1