GuestNo new alerts

Web Apps vs Web Scripts

- Articles28
 
Please note that the use of the term "web apps" in this article is mainly used in contrast to the old method of deploying websites and are not to be confused with client-side apps.

Originally, the web was filled with countless little scripts and every-time a user visited a website, a script would be loaded off the filesystem, compiled on the spot would finally cough up a response and the server would turn around and give that to the user.

This worked. But, it wasn't particularly fast. Eventually, later systems of this type invented protocols which would tap into thread pools rather than individual processes for each request which was better, but was still not ideal.

Another problem is data. Scripts are largely stateless and pull in a vast amount of information from the database, memory caches (adding complexity and a certain degree of unpredictability to one's stack for admins), etc.

This means that requests are largely independent and are constantly forgetting things they just knew an instant ago, but in a different context.

Whereas, with apps, you fire up a persistent process (things sometimes get slightly more complex with single-threaded languages like JavaScript, but I won't note that here) and all the compiled code and a fair bit of important data that is unlikely to ever change stays in memory.

There is no "forgetting", asides for more transient data and hence it's more performant by default.

There is also the benefit that you can take down the application for an update without getting caught in a not so fun mess of undefined behaviour every-time a thousand files are in the midst of being updated.

Some would argue that this reduces the velocity at which one can develop an application and that is one factor which one does have to keep in mind, although I personally think the slowdown there is largely overrated.