Live data from Hacker News

Brython: an implementation of Python 3 running in the browser

github.com

41–50 of 76 posts

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

#41
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…

If TS is eventually added to the JS standard, I would be very happy. I've only picked it up in the past few weeks, but I'm consistently amazed at how much sense it makes

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

#42
post #25
post #21

Past related threads: Brython: Python in the Browser - https://news.ycombinator.com/item?id=26781461 - April 2021 (1 comment) Brython – A Python 3 implementation for client-side web programming - https://news.ycombinator.com/item?id=23746067 - July 2020 (214 comments) Brython – Client-side web programming in Python - https://news.ycombinator.com/item?id=15914805 - Dec 2017 (1 comment) Brython – A Python 3 implementat…

Wow I wasn't aware of those. But apart from the 2020 post, the others are pre-TS. Brython seems to have come a long way since TS came in

id say they wont make it till they get into webassembly. especially if their own website runs brython cause its a poor standard bearer

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

#43
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…

> TypeScript [...] adds to the bundle size.

tbh i haven't checked, but isn't the transpilation step for typescript just stripping out the type annotations? TSC is build-time only, so it won't factor into your bundle size, and i can't imagine the generated JS is significantly bigger than source -- if anything, it should be smaller ;p

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

#44
post #43

Earlier quoted context omitted.

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…

> TypeScript [...] adds to the bundle size. tbh i haven't checked, but isn't the transpilation step for typescript just stripping out the type annotations? TSC is build-time only, so it won't factor into your bundle size, and i can't imagine the generated JS is significantly bigger than source -- if anything, it should be smaller ;p

It definitely adds to the bundle size, but how much it adds depends on your implementation. This discussion on the topic is pretty interesting [0]. One comment from that discussion says “it is possible to double to the size of your source code”.

[0] https://dev.to/haruanm/does-typescript-increase-the-bundle-s...

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

#45
post #36

Earlier quoted context omitted.

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).

Good point. I was thinking of changing styles via DOM, like CSS-in-JS, but you’re right that “y to CSS” would still be there.

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

#48

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…

The problem was WebAssembly despite what people think isn't a JS replacement. WebAssembly isn't designed to go after DOM manipulation and the rest of the browser world (in short, think calculating physics and heavy number crunching instead of whether or not some input with id blah is blank). The best analogy I can give is this, imagine using Lua and calling of compiled code (C/C++/Rust/etc), this is the JS/WebAssembly way of doing things.

Does the web browser (an application for reading documents written in hypertext), need to evolve? Or, has the web browser been asked to do more than it should and we need a new type of application? So much of the internet is based around the fact that the basics of the web browser can't change (don't break the web!). If the basics can't change then maybe the need for a new standard where the basics fit the application is required.

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

#49
post #43

Earlier quoted context omitted.

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…

> TypeScript [...] adds to the bundle size. tbh i haven't checked, but isn't the transpilation step for typescript just stripping out the type annotations? TSC is build-time only, so it won't factor into your bundle size, and i can't imagine the generated JS is significantly bigger than source -- if anything, it should be smaller ;p

For comparison, ClojureScript, another language that compiles to JavaScript, adds to the bundle size, but in my experience, it's mostly because of the runtime (core functions and data types) because the Google Closure compiler optimizes the initial transpiled JS.

I would guess running the TypeScript output through the Google Closure compiler (or adding similar optimizations directly to the TypeScript compiler) could make TypeScript bundles comparable to JavaScript bundles or smaller. It looks like people see significant improvements running TypeScript output through Closure compared to just WebPack [0].

[0]: https://medium.com/appmonet/using-closure-compilers-advanced...

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

#50
post #36

Earlier quoted context omitted.

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).

I'm going to ask an ignorant question and I'm sorry, but couldn't you basically write an application in web assembly, using OpenGL and creating whatever UI you wanted in there, and just use CSS for the scaffold? You'd only need a mobile and desktop web app, but you'd need one anyway, right? (Note.. I'm very obviously not a web developer, so forgive my naivete).
Post reply on HN