3 ms·

The future of the web could also be back to the browser. Python can run in the browser with SQLite. I have had ideas of taking Django or fastapi and then either

The future of the web could also be back to the browser. Python can run in the browser with SQLite. I have had ideas of taking Django or fastapi and then either using the browser or put it in an app which runs it in WebKit or blink and syncing to the servers if that is even needed for the app.

imiric 4y ago
That's neat, but it's not the web. You're merely using the web as a deployment mechanism, and the "browser" as a hypervisor. You might as well build an Electron app at that point if you want the desktop UX.
- horsawlarway 4y ago
  Out of curiosity - what do you believe the web is, exactly? Because if you're ruling out his approach - you're also mostly ruling out the entire article here (since this approach does not in any way solve your datastore needs).
  - imiric 4y ago
    Right, I was a bit harsh with the "it's not the web" remark. Ultimately, the web is what we make of it, and it's not up to anyone to claim it's one thing or the other. Initially, the "web" had a clear definition: a client-server architecture, a markup language to render data from the server, a protocol for the client to request data from the server, and a universal format to reference data. Then we added more technologies to improve styling, interactivity, P2P protocols, etc., and it's been evolving ever since. Instead of documents, we served apps. Thin clients were deemed unsuitable, until we realized performance might be an issue, and now we can choose whichever approach makes sense for the product. So I'd say I'm a bit of a traditionalist in this sense, and think that a web app should still involve frequent communication with a server. If you're building a product using web technologies, but it's running entirely (or mostly) offline, that's great, but it's not part of the World Wide Web. You could use any number of technologies to build a desktop app at that point, and using web frameworks and a web browser is a choice made out of convenience, rather than suitability. After all, if you download an installer over HTTP for an offline desktop app written in a non-web language, would that still count as a "web app"? We have to draw the line somewhere, and I suppose it's a matter of preference where that is done. Or maybe the line is forever blurred and web apps are all that we have now... > Because if you're ruling out his approach - you're also mostly ruling out the entire article here (since this approach does not in any way solve your datastore needs). I don't think that's the case. I may disagree with the assertion that "the future of the web is on the edge", but the article still suggests a traditional client-server model. It's just that the server is now distributed and closer to the client, which in general is a good idea.
- lioeters 4y ago
  The web is a deployment mechanism, and the browser does essentially manage sandboxed processes as a kind of virtual operating system. The web is evolving. Python with SQLite running in the browser is part of the web.
  - systemvoltage 4y ago
    Can you please explain more? How would a local sqlite database work with a typical, say a CRUD blogging app as an example? Do invidividual users have their own database in the browser?
    - lioeters 4y ago
      It probably wouldn't be suitable for a blog or classic CRUD app. The use cases I've heard about are more for education and online editor/IDE. For example: interactive documentation that runs code in the browser with an ephemeral/temporary database, possibly imported from the user's desktop. For teaching programming languages in the browser, with the compiler compiled to WASM, so the student doesn't have to set up a local development environment. Or a database explorer that's a purely static site with no server, neither remote nor directly on user's computer - just virtually in the browser, which is a more secure sandbox. You could have a folder of HTML, CSS, JS that's a full-stack application with client UI and server (theoretically). Further reading: • SQL Databases in the Browser, via WASM: SQLite and DuckDB - https://blog.ouseful.info/2022/02/11/sql-databases-in-the-browser-via-wasm-sqlite-and-duckdb/ https://blog.ouseful.info/2022/02/11/sql-databases-in-the-br... • Pyodide - https://pyodide.org/en/stable/ https://pyodide.org/en/stable/ - Pyodide is a Python distribution for the browser and Node.js based on WebAssembly. • Client-side WebAssembly WordPress with no server - https://make.wordpress.org/core/2022/09/23/client-side-webassembly-wordpress-with-no-server/ https://make.wordpress.org/core/2022/09/23/client-side-webas... • Stackblitz - Instant development environments - https://stackblitz.com https://stackblitz.com
Existenceblinks 4y ago
It's just browsers not having generic vm. It just not be able to run more than one programming language. (ok, wasm..). Other VM has a bunch of dialect of its langs run on them.

imiric 4y ago

That's neat, but it's not the web. You're merely using the web as a deployment mechanism, and the "browser" as a hypervisor. You might as well build an Electron app at that point if you want the desktop UX.

horsawlarway 4y ago
Out of curiosity - what do you believe the web is, exactly? Because if you're ruling out his approach - you're also mostly ruling out the entire article here (since this approach does not in any way solve your datastore needs).
- imiric 4y ago
  Right, I was a bit harsh with the "it's not the web" remark. Ultimately, the web is what we make of it, and it's not up to anyone to claim it's one thing or the other. Initially, the "web" had a clear definition: a client-server architecture, a markup language to render data from the server, a protocol for the client to request data from the server, and a universal format to reference data. Then we added more technologies to improve styling, interactivity, P2P protocols, etc., and it's been evolving ever since. Instead of documents, we served apps. Thin clients were deemed unsuitable, until we realized performance might be an issue, and now we can choose whichever approach makes sense for the product. So I'd say I'm a bit of a traditionalist in this sense, and think that a web app should still involve frequent communication with a server. If you're building a product using web technologies, but it's running entirely (or mostly) offline, that's great, but it's not part of the World Wide Web. You could use any number of technologies to build a desktop app at that point, and using web frameworks and a web browser is a choice made out of convenience, rather than suitability. After all, if you download an installer over HTTP for an offline desktop app written in a non-web language, would that still count as a "web app"? We have to draw the line somewhere, and I suppose it's a matter of preference where that is done. Or maybe the line is forever blurred and web apps are all that we have now... > Because if you're ruling out his approach - you're also mostly ruling out the entire article here (since this approach does not in any way solve your datastore needs). I don't think that's the case. I may disagree with the assertion that "the future of the web is on the edge", but the article still suggests a traditional client-server model. It's just that the server is now distributed and closer to the client, which in general is a good idea.
lioeters 4y ago
The web is a deployment mechanism, and the browser does essentially manage sandboxed processes as a kind of virtual operating system. The web is evolving. Python with SQLite running in the browser is part of the web.
- systemvoltage 4y ago
  Can you please explain more? How would a local sqlite database work with a typical, say a CRUD blogging app as an example? Do invidividual users have their own database in the browser?
  - lioeters 4y ago
    It probably wouldn't be suitable for a blog or classic CRUD app. The use cases I've heard about are more for education and online editor/IDE. For example: interactive documentation that runs code in the browser with an ephemeral/temporary database, possibly imported from the user's desktop. For teaching programming languages in the browser, with the compiler compiled to WASM, so the student doesn't have to set up a local development environment. Or a database explorer that's a purely static site with no server, neither remote nor directly on user's computer - just virtually in the browser, which is a more secure sandbox. You could have a folder of HTML, CSS, JS that's a full-stack application with client UI and server (theoretically). Further reading: • SQL Databases in the Browser, via WASM: SQLite and DuckDB - https://blog.ouseful.info/2022/02/11/sql-databases-in-the-browser-via-wasm-sqlite-and-duckdb/ https://blog.ouseful.info/2022/02/11/sql-databases-in-the-br... • Pyodide - https://pyodide.org/en/stable/ https://pyodide.org/en/stable/ - Pyodide is a Python distribution for the browser and Node.js based on WebAssembly. • Client-side WebAssembly WordPress with no server - https://make.wordpress.org/core/2022/09/23/client-side-webassembly-wordpress-with-no-server/ https://make.wordpress.org/core/2022/09/23/client-side-webas... • Stackblitz - Instant development environments - https://stackblitz.com https://stackblitz.com

Existenceblinks 4y ago

It's just browsers not having generic vm. It just not be able to run more than one programming language. (ok, wasm..). Other VM has a bunch of dialect of its langs run on them.