Winchestro · April 28, 2015 21:00
diff --git a/gistfile1.txt b/gistfile1.txt
 If you develop native applications you are at the mercy of established and restrictive stores, which are totally overcrowded and/or hard to get into. People generally don't like downloading things unless when it comes to pirating software, which they of course love. 

 If you develop on the web this problem doesn't really vanish. You still have to pay a lot of attention so the size of your application, you can't just develop software that has to download 5 gig data upfront before it starts running and pretend you develop a native application, like most engines that compile to the web asssume. 

 The problem is, most established tools are developed under the assumption that the size of your data doesn't really matter, and all data is already on the clients hard drive and relatively cheap to access. It has been optimized for developing applications to be distributed through upfront downloads or CDs/DVDs as a medium. But on the Web you're back to basically floppys that need to carry everything your App needs to *start* running and then you download the rest on demand. Optimally even over really terrible network conditions.

 One possible solution would be, if you as a developer / designer are good enough at programming to pull it off is to focus primarily on "procedural" assets, aka assets with really low kolmogorov complexity, which you can compress enough to send them around even under the worst network conditions and have the freedom to either render them on the server or the client depending on the capabilities of the client and your free server resources. 

 It puts a lot of restrictions on what you can do, but can result in products with a similar, or even better impression than those developed without that focus. On the other hand, even though it may be more difficult than just using existing toolchains, for a single or a small group of developers it may actually be easier to learn and to polish. 

 But those techniques generally are much more demanding to CPU/GPUs, which are already a point of high uncertainty on the web. Most computers accessing the web are not really made to run demanding software, but it would be nice if those would still be able to run it and at least not get a highly negative impression, like a DoS or really low framerate. 

 So that's why I think servers that can assist weak hardware under good network conditions are important to actually get any advantage from putting stuff on the web at all. ( If 99% of people get nothing but crashes or lags, it would actually be a lot better to distribute it as native apps and only expose screenshot / video content, as that leaves a better impression than crashes and lags ).

 But that of course comes with server costs for the developer that need to be covered somehow. So why even bother? Where should the money for all this come from? Highly dubious modern monetization techniques? 

 That's another problem. The web doesn't really give you a choice to monetize anything without drastically reducing the quality of your software. So in order to make money you'd still need native applications and marketplaces unless you are a dick. But if you focus on the web for exposure and on native for performance you can leaverage the strenghts of both worlds. People can use your software on the web, and if they like it, and want to run it with better performance, they can buy your native application.

 You can leaverage the high discoverability on the web, which it is really good at, even at a loss then and you leaverage the performance boost of native applications which *they* are really good at and work around overcrowded store and lack of discoverability.

 ( I'm saying "software" and not "games" because even though I love games, all kinds of software faces those problems and some even more than games just because gamers are relatively tolerant and willing to wait minutes for loding bars to fill up or upgrade their hardware when it comes to software lagging / crashing / not working. They've been basically trained to think they need better hardware and not that the software needs to perform better for decades, but there are a lot of people who don't think that way. )

 So those are my (long term) plans to go from JS+WebGL. Adding C/C++/OpenGL to the mix, to improve hot code by compiling to the web with emscripten (should it become actually usable one day), write server sofware to assist clients through server-side rendering using C/C++/OpenGL and ultimatively ship native as native applications bundled with the open source V8 javascript engine and all those optimized module binaries written in C/C++ to get the full native performance to actually generate the assets from the code ( on-demand JS comes from the server for all cold code, API bindings, GUI and most of application code itself to reduce piracy issues and make it easier to iterate and maintain ).
	If you develop native applications you are at the mercy of established and restrictive stores, which are totally overcrowded and/or hard to get into. People generally don't like downloading things unless when it comes to pirating software, which they of course love.

	If you develop on the web this problem doesn't really vanish. You still have to pay a lot of attention so the size of your application, you can't just develop software that has to download 5 gig data upfront before it starts running and pretend you develop a native application, like most engines that compile to the web asssume.

	The problem is, most established tools are developed under the assumption that the size of your data doesn't really matter, and all data is already on the clients hard drive and relatively cheap to access. It has been optimized for developing applications to be distributed through upfront downloads or CDs/DVDs as a medium. But on the Web you're back to basically floppys that need to carry everything your App needs to start running and then you download the rest on demand. Optimally even over really terrible network conditions.

	One possible solution would be, if you as a developer / designer are good enough at programming to pull it off is to focus primarily on "procedural" assets, aka assets with really low kolmogorov complexity, which you can compress enough to send them around even under the worst network conditions and have the freedom to either render them on the server or the client depending on the capabilities of the client and your free server resources.

	It puts a lot of restrictions on what you can do, but can result in products with a similar, or even better impression than those developed without that focus. On the other hand, even though it may be more difficult than just using existing toolchains, for a single or a small group of developers it may actually be easier to learn and to polish.

	But those techniques generally are much more demanding to CPU/GPUs, which are already a point of high uncertainty on the web. Most computers accessing the web are not really made to run demanding software, but it would be nice if those would still be able to run it and at least not get a highly negative impression, like a DoS or really low framerate.

	So that's why I think servers that can assist weak hardware under good network conditions are important to actually get any advantage from putting stuff on the web at all. ( If 99% of people get nothing but crashes or lags, it would actually be a lot better to distribute it as native apps and only expose screenshot / video content, as that leaves a better impression than crashes and lags ).

	But that of course comes with server costs for the developer that need to be covered somehow. So why even bother? Where should the money for all this come from? Highly dubious modern monetization techniques?

	That's another problem. The web doesn't really give you a choice to monetize anything without drastically reducing the quality of your software. So in order to make money you'd still need native applications and marketplaces unless you are a dick. But if you focus on the web for exposure and on native for performance you can leaverage the strenghts of both worlds. People can use your software on the web, and if they like it, and want to run it with better performance, they can buy your native application.

	You can leaverage the high discoverability on the web, which it is really good at, even at a loss then and you leaverage the performance boost of native applications which they are really good at and work around overcrowded store and lack of discoverability.

	( I'm saying "software" and not "games" because even though I love games, all kinds of software faces those problems and some even more than games just because gamers are relatively tolerant and willing to wait minutes for loding bars to fill up or upgrade their hardware when it comes to software lagging / crashing / not working. They've been basically trained to think they need better hardware and not that the software needs to perform better for decades, but there are a lot of people who don't think that way. )

	So those are my (long term) plans to go from JS+WebGL. Adding C/C++/OpenGL to the mix, to improve hot code by compiling to the web with emscripten (should it become actually usable one day), write server sofware to assist clients through server-side rendering using C/C++/OpenGL and ultimatively ship native as native applications bundled with the open source V8 javascript engine and all those optimized module binaries written in C/C++ to get the full native performance to actually generate the assets from the code ( on-demand JS comes from the server for all cold code, API bindings, GUI and most of application code itself to reduce piracy issues and make it easier to iterate and maintain ).