Skip to content

Instantly share code, notes, and snippets.

@Recoskie
Last active April 21, 2023 07:38
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Recoskie/c2d9058aee6b7270bc77bd5b96a2b0b0 to your computer and use it in GitHub Desktop.
Save Recoskie/c2d9058aee6b7270bc77bd5b96a2b0b0 to your computer and use it in GitHub Desktop.
The limits of web applications.

Graphics performance. Graphics before HTML5 canvas existed.

At one point in time, writing web applications ware stupid as to do any graphics at all involved using div elements one pixel in size with an absolute x, y position and color.

The other method I developed was a graphics engine that let you set the width and height of a bit map. Each pixel color was stored and referenced to the bytes in the bitmap for each pixel color. I implemented basic text and 2D graphics drawing functions as I built basically a bitmap codec that wrote directly to the web page from javascript memory.

Both methods gave poor performance but allowed me to do some 3D graphics using sine and cosine rotation transformations and line drawing functions. The bitmap method was faster, but the performance was still poor and would only give me the ability to render basic 3D shapes.

I never released this graphics implementation as by the time I had all the graphics 2D functions implemented, then HTML5 canvas started.

In HTML5 canvas, we can now do native graphics function calls and get native application graphics performance across all web-connected devices.

This was the most amazing thing added to javascript and the HTML web standards that started to make building applications, UI components, and games run at native application performance.


Reading binary files and working with raw binary data.

There are times in which we want to read large binary files and do such at native application performance.

Well, now you can. You can use all 53 bits in a float64 number to read files as large as 16 petabytes.

We can now read files in sections and navigate them if you want to process files in the web browser using only javascript at native code performance.

This also means we never have to upload a file that is 16 petabytes to any server to process the files. Instead, we can process them right inside the user's web browser on their PC, or cell phone.

This once used to be a problem with javascript and web applications. However, with the new file reader API added to web standards, it is now extremely fast on any connected web device giving native app performance.

Building and creating loaders for different file formats and implementing codecs in script is a lot of work, but now we can process files at native code performance on any web-connected device.

A good example is a simple bitmap codec. You can now design your own readers that perform at the same performance as the codecs built into your web-connected device.

Now assuming you are designing a brand new video file format or picture format for storing each individual pixel color per picture frame and sound bar per second that you know is not supported by any web browser, you can use the improved binary file system and binary types javascript now has to process the files right in the web browser. You then can use HTML5 to render the video frames like youtube.

You can also request files from the web as binary file objects that can be read as binary files in the file read API right inside the web browser.

For example, both Geforce now and Microsoft xCloud support their own custom video codecs for cloud gaming completely translated in javascript in their web apps.

You can download both the web application or test the Android application. You will find Geforce now is the most optimized when it comes to designing a codec while Microsoft is struggling with this, and their android app is better at the moment.

At one point in time, doing such tasks in javascript only without Flash or any plugins would have been considered off-limits, but is not anymore.


Running emulators in javascript only, HTML5 graphics, and fileReader.

Can we run emulators at close to native code speed? Well, the answer is we can now on web-connected devices given the improvements we now have, but there is one problem.

We can legit recompile code from a ROM file by writing javascript equivalent operations into a string.

We call the eval function to generate compiled functions to run. We then can store these chunks of code as functions.

This is one of many workarounds that the Dolphin emulator did on iPhone to compile code and run GameCube and wii games at full speed until Apple killed it. They blocked dolphin from communicating using a bridge-type connection viable port number to the built-in web API.

Since javascript compiles javascript to raw machine code, it basically did JIT compilation until Apple killed the workaround.

The eval function in javascript should be avoided, but in some cases, it is faster to write the steps out as a string into compiled callable functions. If we are not receiving code online or through a server and it is generated algorithmically from a ROM file or by a data science (Artificial intelligence) algorithm, then using eval will compile machine code functions that you can call that outperform algorithms, and If you are certain, the functions will be reused after being created using eval.

The small problem with running an emulator entirely inside of a web browser is not any of the following reasons: the inability to read the ROM file directly at high performance using the fileReader API, the inability to translate the code and run it, or to do native graphics calls in HTML5. AS all of that is possible without any internet connection.

The problem is not being able to adjust the amount of RAM memory we need to load all the textures and code snippets to make the game playable.

An Android or iOS application can let us allocate more memory as needed and store the large textures and everything required to make a smooth emulator/simulator.

It is not impossible to make it work in the web browser app without an internet connection with the limited percentage of RAM memory we can use. It would be much smoother if we could use more RAM when needed.

In the case of the dolphin emulator workaround, it only had to compile code snippets; basically, load and unload code snippets not in use using eval to compile code.


Should we process data on the server side or the client side?

Since we can do everything in javascript now, even process large data and files, it makes sense to do as much as we can in javascript or on the web-connected device in the web browser as it limits the load on the server side and less data is transmitted and read by the server-side improving the user's security.

We can design everything to run as web applications now and do custom UI design.

At one time, we would load java, or Flash to do all this, but now HTML5, and javascript has replaced the need for compilers and machine code programs in Flash as it all can be done in the web browser with HTML5 and javascript.

People have even built more than just emulators that run privately inside your web browser, disassembler, and reverse engineering tools that can be run while offline and privately in the web browser. People have also made web applications that edit pictures and save files without being connected online to the server as it runs entirely inside the web browser as javascript and HTML.

It is easy to misjudge what can all be done on the client's web browser using only javascript and HTML as a lot has changed, and a lot of developers do not know how to read binary file formats or how to write them and how to build graphics engines. We can also create audio output as well algorithmically using sine and creating audio synthesizers. As of right now, javascript and HTML is a full-blown programming language with the capabilities to do all things you could in assembly language or C++.


Are web applications good?

In order to make our web application into a real application that can run entirely offline, we have to create a service worker that specifies all scripts and pictures and everything that the web application will need to work without needing to request any files from online. Your web application should never use any server-side code for processing files or anything and should not need an internet connection. There should never be any PHP serverside code or rails. If it is an audio program like FL studio, photoshop, an emulator, or a game.

This is the main, most important focus of creating a great web application. If there are some features you wish to add, such as scores, leaderboards, multiplayer, and other things, then you focus on that last. Focus on all things that will work without an internet connection and dose not need any server-side code as it will make it very secure and fast performing.

You can even build an assembler and compile Microsoft programs in javascript without any server-side code as it can run right in a cell phone or PC web browser without an internet connection as long as you know how to structure and write the headers for a Microsoft program. If you require a computer library on the server side, then you are basically saying you are limited in what you can create code or program. The same is true with file processing.

Microsoft has agreed that web applications are now as powerful as desktop applications and allows you to install them as applications in the Microsoft app store. When you run a web application, they load without the browser UI so the whole window is useable for your web application. No back button, reload button, and URL bar is gone.

Even iPhone/Android lets you install web applications and loads them as fullscreen application with no URL bar, no reload, and navigation buttons.

You can set the application icon for your web application and the load screen to everything you would with regular applications.

So to answer this properly, the real answer is that web applications have become real applications.

A lot of applications are web applications and you can go to them as a web page or you can go into browser options and install the page as a web application. On app stores, it installs it for you without you knowing it is a web application as it loads and works the same as all native apps on your cell phone/pc, and can be visited by web page URL.


The lack of well-developed web applications.

Applications such as disassemblers that operate online should never need to download a program from your device to read it client side. A full fledged disassembler, or decompiler, can run right inside the web browser with no upload limit and is able to load files 16 petabytes in size as we can read and navigate them without transmitting them to an online server. This is also better for user security. We can also build good emulators, but we have to use RAM memory wisely.

People have also built virtual machines that can run an entire operating system in javascript and display the graphics memory in HTML5. Similar to building an emulator, but is very impressive. It is a little bit slower on a cell phone than on a PC, but it shows how fast cell phones can be compared to a PC these days. It will also allow you to understand that there are no limits to web apps. In which the only limit is what you can build ground up and optimize.

The limitation of a good web application is the developer's understanding of how to process or create different binary files from scratch. Understanding enough graphics design and UI science which is a whole subject on its own. Understanding processor architecture and machine code if building emulators, or building a compiler that works while offline that can compile binaries that run on a system without any server-side libraries or binaries.

This list will get shorter and simpler as developers create more javaScripts with callable functions that do some of the work for the developer without having to know how everything is at binary level. Even though machine code is very basic and standardized across all systems by arch type and is not individualized by vendor or company. In fact, it takes longer to learn UI science than it does machine code.

What is lacking is real developer talent when it comes to web applications, and many developers do not understand what all javascript and HTML5 can do.


Web application pros and cons.

Pros.

  • Web apps run on everything.
  • Changes made to the application page are given as an update through all app stores to update the scripts and files stored on the phone or PC.
  • Web apps run the same as native applications on all devices when saved to the phone and run without any internet connection.
  • Applications are modular and very modern in design.

Cons.

  • Making everything run offline is a lot of work, especially when most of the binary data and processing work has to be designed ground up.
  • Good knowledge of UI science and graphics also goes a long ways.
  • Web applications take much higher technical know-how and skills than building native apps. You have many more tools to make well built native apps.
  • Much longer planning and development time. Much easier after the core components are designed for a well-built, optimized web application.

Web applications are very modern and modular. Whether you choose to do the extra work to build a well-optimized web app or build native applications is entirely up to you and your preference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment