Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brython: an implementation of Python 3 running in the browser

github.com

Post reply on HN
Print view View original

31–40 of 76 posts

Re: Brython: an implementation of Python 3 running in the browser

#31

Post by Tade0 »

gchamonlive wrote: post #19
bluedays wrote: post #16

I'm hoping web assembly eventually completely replaces javascript. It would be amazing if we could theoretically compile any language down to be browser compatible.

This is something that I wanted to hear more from people invested in frontend. I work exclusively as a DevOps/DataOps/Backend engineer and have little contact with stuff running in the browser. I did, however, work with AngularJS back in the day, and although the framework itself didn't lend itself to nicely to productivity and simplicity, I believe that what I found most confusing was how unergonomic the browser env…

> not having for instance a SQLite natively

We had this for a brief moment in the form of Web SQL, but as a rule web standards require independent implementations to be developed, and all the implementors were using SQLite under the hood. The current alternative is IndexedDB - for better or worse.

> Is the browser environment becoming more dev-friendly with the adoption of WebAssembly?

Yes, but that doesn't have much to do with WebAssembly.

JavaScript as a language evolved, we have TypeScript with its flexible and expressive type system and bundling is becoming less of a pain with each consecutive framework re-written using ES2015 modules(and loaded via e.g. Snowpack https://www.snowpack.dev/).

WebAssembly is helpful when there's a need for some heavy lifting - e.g. in software codecs, but that's still a niche application.

Re: Brython: an implementation of Python 3 running in the browser

#32

Post by peterthehacker »

Tade0 wrote: post #31
gchamonlive wrote: post #19

Earlier quoted context omitted.

This is something that I wanted to hear more from people invested in frontend. I work exclusively as a DevOps/DataOps/Backend engineer and have little contact with stuff running in the browser. I did, however, work with AngularJS back in the day, and although the framework itself didn't lend itself to nicely to productivity and simplicity, I believe that what I found most confusing was how unergonomic the browser env…

> not having for instance a SQLite natively We had this for a brief moment in the form of Web SQL, but as a rule web standards require independent implementations to be developed, and all the implementors were using SQLite under the hood. The current alternative is IndexedDB - for better or worse. > Is the browser environment becoming more dev-friendly with the adoption of WebAssembly? Yes, but that doesn't have much…

Technologies like TypeScript are still dependencies that require transpiling to vanilla JavaScript and add to the bundle size. While typescript is becoming more and more common (for good reason) it still is effectively a workaround that compensates for the unergonomic-ness of the browser environment. You could make the same argument for frameworks like Angular, React and Vue.

If WebAssembly replaced js, then newer, more efficient browser languages could be invented. Like a new implementation of typescript could be created that is statically compiled and more efficient. All of this transpiling from x to js and y to css would be unnecessary.

Re: Brython: an implementation of Python 3 running in the browser

#34

Post by coupdejarnac »

meredydd wrote: post #17
peterthehacker wrote: post #7

This project will transpile python code to JavaScript code instead of something WASM-based, like pyodide [0]. What are there the performance and usability consequences of each approach (py to js vs. py to wasm)? [0] https://github.com/pyodide/pyodide

(Disclosure: I'm a maintainer of https://skulpt.org , another Python-in-the-browser runtime, as well as a Python web framework/dev environment that uses it, https://anvil.works ) The short answer is that basically all the current Python-in-the-browser implementations (and there are a few!) predate widespread support of WASM. But even once WASM is a thing, you get a choice between: 1. Compile a full Python environment…

Thanks for skulpt. Using it as a replacement for replit to teach kids.

Re: Brython: an implementation of Python 3 running in the browser

#35

Post by fulafel »

meredydd wrote: post #17
peterthehacker wrote: post #7

This project will transpile python code to JavaScript code instead of something WASM-based, like pyodide [0]. What are there the performance and usability consequences of each approach (py to js vs. py to wasm)? [0] https://github.com/pyodide/pyodide

(Disclosure: I'm a maintainer of https://skulpt.org , another Python-in-the-browser runtime, as well as a Python web framework/dev environment that uses it, https://anvil.works ) The short answer is that basically all the current Python-in-the-browser implementations (and there are a few!) predate widespread support of WASM. But even once WASM is a thing, you get a choice between: 1. Compile a full Python environment…

In addition prior to webassembly there were asm.js + emscripten based Python ports. With mostly the same properties as the wasm based ones.

Re: Brython: an implementation of Python 3 running in the browser

#36

Post by bri3d »

peterthehacker wrote: post #32
Tade0 wrote: post #31

Earlier quoted context omitted.

> not having for instance a SQLite natively We had this for a brief moment in the form of Web SQL, but as a rule web standards require independent implementations to be developed, and all the implementors were using SQLite under the hood. The current alternative is IndexedDB - for better or worse. > Is the browser environment becoming more dev-friendly with the adoption of WebAssembly? Yes, but that doesn't have much…

Technologies like TypeScript are still dependencies that require transpiling to vanilla JavaScript and add to the bundle size. While typescript is becoming more and more common (for good reason) it still is effectively a workaround that compensates for the unergonomic-ness of the browser environment. You could make the same argument for frameworks like Angular, React and Vue. If WebAssembly replaced js, then newer, m…

The "y to CSS" part would still be there - even with WebAssembly, your UI options are still pretty much the DOM (great for documents and form entry, not so great for applications) or canvas (too low level and loses platform consistency, accessibility, usability, really every affordance of an operating system).

Re: Brython: an implementation of Python 3 running in the browser

#37

Post by anticristi »

Can I hijack this post for a nit-pick?

While I love Python and feel most comfortable with it, it always bothered me that it make a distinction between accessing a dictionary item and accessing an object member. E.g.:

  a["getStuff"]()  # call the "getStuff" function of dictionary "a"
  b.getStuff()     # call the "getStuff" method of object "b"
In contrast, in JavaScript, these two are equivalant.

   a["getStuff"]()
   a.getStuff()
I find JavaScript more dev-friendly. Any idea why Python didn't opt for the same approach? Would make sense to me, since "everything is a dictionary/object".

Re: Brython: an implementation of Python 3 running in the browser

#38

Post by rhacker »

anticristi wrote: post #37

Can I hijack this post for a nit-pick? While I love Python and feel most comfortable with it, it always bothered me that it make a distinction between accessing a dictionary item and accessing an object member. E.g.: a["getStuff"]() # call the "getStuff" function of dictionary "a" b.getStuff() # call the "getStuff" method of object "b" In contrast, in JavaScript, these two are equivalant. a["getStuff"]() a.getStuff()…

I ran into this recently while learning it... confused me for a long time because I'm typically writing TS for my day job.

Re: Brython: an implementation of Python 3 running in the browser

#39

Post by julienb_sea »

peterthehacker wrote: post #32
Tade0 wrote: post #31

Earlier quoted context omitted.

> not having for instance a SQLite natively We had this for a brief moment in the form of Web SQL, but as a rule web standards require independent implementations to be developed, and all the implementors were using SQLite under the hood. The current alternative is IndexedDB - for better or worse. > Is the browser environment becoming more dev-friendly with the adoption of WebAssembly? Yes, but that doesn't have much…

Technologies like TypeScript are still dependencies that require transpiling to vanilla JavaScript and add to the bundle size. While typescript is becoming more and more common (for good reason) it still is effectively a workaround that compensates for the unergonomic-ness of the browser environment. You could make the same argument for frameworks like Angular, React and Vue. If WebAssembly replaced js, then newer, m…

Transpiling is more about broad browser compatibility than anything else. In any event, even if you invented some more efficient browser language, it would likely need a universal browser-compatible compilation target anyway (like web assembly). This isn't particularly a step forwards from TS compilation to JS, and the loss of all common JS libraries would be a huge drag on adoption.

Re: Brython: an implementation of Python 3 running in the browser

#40

Post by supervisual »

anticristi wrote: post #37

Can I hijack this post for a nit-pick? While I love Python and feel most comfortable with it, it always bothered me that it make a distinction between accessing a dictionary item and accessing an object member. E.g.: a["getStuff"]() # call the "getStuff" function of dictionary "a" b.getStuff() # call the "getStuff" method of object "b" In contrast, in JavaScript, these two are equivalant. a["getStuff"]() a.getStuff()…

I would argue opposite, For a long time JS had this issue where when you iterated on keys in a dictionary you had to ensure you were skipping methods etc via .hasOwnProperty check. Python by making clear distinction between contents and functionality avoids this.
Post reply on HN