Brython: an implementation of Python 3 running in the browser • Hacker News Board

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

#71

Post by rank0 » Tue, Jul 20, 2021, 2:22 PM UTC

ben-schaaf wrote: post #60

rank0 wrote: post #54

Earlier quoted context omitted.

idk how I feel about web assembly. At least now we can see what client-side javascript is doing. If WASM becomes mainstream then all client side code is going to be essentially binary blobs.

With all the minification and JS being used as a compile target for other languages it's already essentially binary blobs.

I agree with what you're saying but WASM is just way more difficult to reverse engineer. Also if WASM becomes the standard, everyone will have binary blobs running in their browser at every web page by default. At least now its only for web apps which are intentionally obfuscated/minified/transpiled/whatever...

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

#72

Post by UnpossibleJim » Tue, Jul 20, 2021, 2:37 PM UTC

hnfong wrote: post #52

UnpossibleJim wrote: post #50

Earlier quoted context omitted.

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

Yes. For example: https://workspaceupdates.googleblog.com/2021/05/Google-Docs-... But it's going to be a very "heavy" custom framework that takes time to download and load. Overkill in most cases.

Ok. Makes sense. Thanks =)

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

#73

Post by bri3d » Tue, Jul 20, 2021, 3:21 PM UTC

UnpossibleJim wrote: post #50

bri3d wrote: post #36

Earlier quoted context omitted.

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

That was my second option - canvas.

WebGL is a type of HTML5 canvas context. Unfortunately, there are major drawbacks which I also outlined - it's too low level and loses platform consistency, accessibility, usability, and really every affordance of an operating system - you're starting over from scratch and loading in dependencies or writing your own implementation of some immensely challenging concepts (font rendering on its own is usually several hundred kb of code and could fill textbook upon textbook).

If you're familiar with GL UI frameworks like dear-imgui, they do all work pretty well in WebAssembly. But again, they're compromised from the start because you lose all OS consistency and accessibility. And unlike in games, where these frameworks are often employed, OS consistency isn't expected, and accessibility is sadly ignored, the experience of a cross-platform UI framework appearing in a canvas element on the web becomes jarring very quickly.

There is an alternative approach, like Google Docs employs and the sibling poster linked - combining the DOM for input elements with custom rendering. But, this is really, really complex and challenging.

Every time I develop applications for the web, I yearn for an application-focused presentation layer which provides the expected fundamentals around accessibility, OS consistency, and rendering layout while ditching the hacks-on-hypertext minefield of CSS and the DOM.

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

#74

Post by rpmisms » Tue, Jul 20, 2021, 7:12 PM UTC

runarberg wrote: post #53

rpmisms wrote: post #41

Earlier quoted context omitted.

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

You can actually annotate typescript types using JSDoc comments. So if you don’t like the added step of compiling your source down to JavaScript you can still write JavaScript with doc comments and then typecheck with `tsc --noEmit` which won’t run the compile step. However I do see the appeal of the ergonomic of the TypeScript syntax. I hope TC39 will add something like optional type annotations to the spec.

It could be a feature flag, like `use strict`, but `use types` instead

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

#75

Post by runarberg » Tue, Jul 20, 2021, 8:58 PM UTC

rpmisms wrote: post #74

runarberg wrote: post #53

Earlier quoted context omitted.

You can actually annotate typescript types using JSDoc comments. So if you don’t like the added step of compiling your source down to JavaScript you can still write JavaScript with doc comments and then typecheck with `tsc --noEmit` which won’t run the compile step. However I do see the appeal of the ergonomic of the TypeScript syntax. I hope TC39 will add something like optional type annotations to the spec.

It could be a feature flag, like `use strict`, but `use types` instead

I’m actually hoping for something more akin to python’s optional type annotations. Where opting in is as simple as using type annotations. The runtimes (i.e browsers, nodejs, etc.) would then simply ignore them like they do with comments. But third party tools could use them to do some static analysis. Like mypy does for python (or tsc --noEmit does for javascript).

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

#76

Post by rpmisms » Tue, Jul 20, 2021, 10:59 PM UTC

runarberg wrote: post #75

rpmisms wrote: post #74

Earlier quoted context omitted.

It could be a feature flag, like `use strict`, but `use types` instead

I’m actually hoping for something more akin to python’s optional type annotations. Where opting in is as simple as using type annotations. The runtimes (i.e browsers, nodejs, etc.) would then simply ignore them like they do with comments. But third party tools could use them to do some static analysis. Like mypy does for python (or tsc --noEmit does for javascript).

It really depends on if you want enforced typing, which is why I think a feature flag could be useful. There's room for both—explicit typing being available, and enforced types being a flag away.