If you're familiar with all that's going on with the source code or at least some parts of it, and have time to spare, do take the time out to contribute to this project. It's pretty insane what they're building.
Great post and great comment but please don't put "Show HN" on submissions like this. As rahimnathwani pointed out, that signifies that the project is your personal work.
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 environment itself was, from not dealing with a filesystem (and thus having to resort to tricks like transpiling and bundling) to the rather terse API, not having for instance a SQLite natively and not being able to enable something like this without bringing copious amounts of megabytes of extra javascript deps...
Is the browser environment becoming more dev-friendly with the adoption of WebAssembly? I ask that because, in my opinion, if the browser itself doesn't evolve, it doesn't matter which language we use, interacting with it will still be a hassle. All in all, it feels like the browser advanced a lot in technology for optimization and resource management, but not so much in becoming more user-friendly to the developer.
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.
The browser has been a system-within-a-system for a long time now. That's a pretty big problem, because it's inefficient computation-wise and has very low interoperability with the host system, which has big implications. The user also has sort of an upside: the browser, being isolated on the host machine, is very portable. And, maybe safer, but I'd argue against this point, because a monolith is too hard to audit; if you want security and correctness you need many small components, not one huge one. But, those are user problems. Big vendors enjoy non-interoperability, because it lets them do user lock-in and have monopolies. That's also why we hardly have medium-sized vendors: only gigantic and minuscule.
If I had a magic wand,
- I'd make Web maximally interoperable, give an API to everything: look up Youtube recommendations or listen to Spotify programmatically or from the command line;
- introduce legislation to forbid non-interoperable for-profit (or infrastructure-level) software; otherwise businesses are incentivized to make walled gardens and lock-in users; e.g. no more countless chat apps;
- get rid of Javascript: it creates too many security and fingerprinting problems, and, if everything has an API, you don't need it;
- break up the browser into a composition of smallest independent components possible; it will get you `apt install facebook-local-events`;
- get rid of password-based authentication: what a horrible idea that was;
- get rid of any client-side possibility to track or fingerprint users; if you're making choices about what services to use or how, those choices can be fingerprinted, depending on some other things, but that's another matter; the other party should not be exposed to what hardware or software or configuration you use or how you use your peripherals;
- introduce consumer and competition protection laws to bring software out of the wild wild west in terms of legislation.
I've more or less described the destruction of Web as we know it, but also a creation of something much better, in my eyes. Doesn't sound very feasible, but that's what I'd do if I had a magic wand.
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.
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.
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).
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.
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.
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.
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.
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].
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”.
Not having direct access to the file system or the network or to a database are because of the sandbox, not because of JavaScript. You can do all those things in Node.
Web Assembly isn’t going to get rid of the sandbox.
Sandbox doesn't imply not having a file system available (for example, for use in imports), I believe this is more of a historic limitation than a strictly technical one (just because we need the sandboxing concept).
I know. Fakeroot is not strictly sandboxing, but I think it illustrates the point.
I don't think Webassembly will ever replace Javascript in the browser. Javascript has a low barrier of entry and if you are creating React/Angular sites there's little to gain from Webassembly for someone not interested in safer languages.
Saying that I am really interested in Webassembly and think the word web in Webassembly does it a disservice.
I have started to think of Webassembly as a light weight JVM. It's heavy sandboxing makes it really interesting as an evolution to FaaS (Function as a service) such as AWS Lambda. Lucet which Fastly is using for their Compute@Edge reports 35 micro second code start time! I can't wait until Fasly put there Compute@Edge on general release so I can try it. I've been playing with Cloudflare workers and as they us Chrome to run WASM files you have to mess about writing Javascript shims so a bit rough around the edges debugging.
Webassembly should realise the original goals of serverless providing a cross platform runtime with security guarantees and be fast and lightweight.
Most people package an entire OS in Docker containers, with WASM they get a small cross platform artifact. This project already looks like a way to run them in K8s https://github.com/deislabs/krustlet.
It also looks great for cross platform media devices. Have the bulk of your code as a WASM binary and then have very thin platform specific shim the WASM interacts with.
I don't think this is ever going to happen. JavaScript is still and probably always will be the language used to manipulate webpages and interact with the user, it's extremely optimized and a quite fast and effective scripting language.
WebAssembly provides an amazing opportunity to do general computing in webpages more efficiently than with the JavaScript scripting language, but it's not designed to interact directly with the user or documents. Certainly that _could_ change in the future, but that's not one of its design goals and I don't think it would even be particularly effective at it.
I’ve noticed both “plain HTML please” and “Wasm is awesome” sentiments expressed on HN. I wonder if these reflect two distinct subpopulations, or if there is an intersection of HNers who like both ideas.
The existence of both sentiments speaks to the idiosyncratic history of the web. The browser is powerful because it has grown to be ubiquitous, but also has this odd dual mandate of displaying static content and running dynamic apps.
I think it's more of a dislike for slow, laggy, and frankly janky experiences caused by excessive JavaScript or under qualified JS developers over the past 10 years.
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.
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...
(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 to WASM (via Emscripten), and load it in the browser. This is what Pyodide does - it lets you use a boatload of existing libraries, but you have to download and bytecode-compile the world to do it. On my machine Pyodide takes 10+ seconds to load. (PyPy.js, which predated WASM, was even worse!) The upside is that you can run more or less anything from the existing ecosystem. This tradeoff is great for Pyodide's use case (notebooks in the browser) - long load times are OK, but you really want those numerical libraries.
2. Ship a lightweight, JS-based runtime. This is what Brython and Skulpt do. You'll pay in performance (compilation overhead, interpretation, and the overhead of preserving Python rather than JS semantics for things like attribute lookup), but your payload will be much smaller (Skulpt is ~250kb on the wire), and you'll be interactive much faster. We chose Skulpt for the client side of our full-stack Python-in-the browser platform, Anvil (https://anvil.works). Unfortunately, you'll be amazed how many Python libraries don't work in this environment. Most "normal" Python code is pretty straightforward, but dig into any big library and you'll find a native dependency really fast. (Skulpt's original 'datetime' implementation was ported from PyPy, and even that depended on native code. In PyPy, the interpreter written in nearly pure Python!) In something like Anvil, this is no biggie, because you can call server-side code with one function call, but it could be a nasty surprise in a traditional app.
3. Compile "not quite Python" to JS (this is what Transcrypt does). This more or less transliterates Python code to the nearest Javascript equivalent. This produces really compact, JIT-friendly JS code, but it will bite you the moment you rely on Python semantics that aren't there in JS. Worse, you're now neither fish nor fowl: If you have a question, you can't consult StackOverflow for Javascript answers, but half the Python answers won't work for you.
(To my knowledge, nobody has yet attempted the "WASM + lightweight runtime" approach. We've occasionally discussed it, but it would be hard to retrofit to an existing project, because you'd want to move a-lot-but-not-all of the runtime into WASM to avoid being hammered by the JS-WASM bridge, and building a Python runtime from scratch is a heavy lift...all for a performance boost you might just get from generating faster JS.)
Before the pandemic, a colleague of mine wrote an in-depth comparison of six popular Python-in-the-browser implementations, with sample code and a discussion of their trade-offs, with a lot more detail than I can fit into this comment: https://anvil.works/blog/python-in-the-browser-talk
It would be cool to compile a Python program (not runtime) to WASM. Nuitka compiles Python to a native program, but I think it still deals with a lot of runtime overhead, and I don't think an equivalent for WASM is coming soon.
Pyodide still involves writing JS (literally). Brython just needs you to know the simple basics of JS (since the syntax is similar), and you're good to go with pure Python from there on.
After reading this thread and being frustrated by the pretty useless exceptions Brython gives, I switched over to using Pyodide (which took 5 minutes, both libraries are pretty simple). There is a huge improvement on usability with Pyodide. It doesn't wrap JavaScript objects in lots of additional structures like Brython does and it actually gives stack traces that end in user code!
I've only been exploring Pyodide for the 10 minutes since I switched over and discovered these two pieces.
I'm curious if there's a good reason to use Brython over Pyodide.
Edit: Ok one weird thing with Pyodide is that I cannot use subscripts with JavaScript objects in Python. I have to use dot accessors. So not `row["age"]` but `row.age`. Kinda weird, not too Pythonic.
Pyodide is rather larger than brython. It's essentially a full python interpreter and stdlib compiled to wasm, whereas brython is a reimplementation of python directly in javascript.
Yeah Transcrypt is interesting! There’s even a book that shows you how to use it with React [0]. Personally I think mithril.js would be a better fit than React because JSX isn’t supported.
Brython has been around a long time, at least 7 or 8 years. While I love Python and I'm not a particularly big JS fan, I feel like if Brython didn't really make a dent before ES6 and TypeScript, then it will be really hard to do it now. Does anyone know what the biggest Brython project/app is? Can we see it in production other than a simple hello world?
Yeah, it has been there for quite some time, but has really started getting off the ground in about mid-late 2019 which is strange, since like you mentioned, the advent of TS. But slowly a lot of interest has been brewing over it, it's growing faster than ever, and has been attracting users/contributors a LOT only since the start of last year.
Python was itself around for years, predating PHP by several years even, before it took off; PHP got big much quicker. Ruby was around for several years before Rails helped it take off outside of Japan. So, that doesn't mean Brython will take off now, but it does at least suggest it's possible.
My biggest gripe is that so far I haven't been able to get good stacktraces out of it on errors. It also wraps all objects in custom Brython types that you have to rewrap in Python types to do stuff like get `.keys()` on JavaScript objects.
Yeah. Like I said, it could really do with more contributors who can work on these issues and add keep adding features. rayluo who is a major contributor (developed brip to support using regular PyPi packages with brython), for example, works at Microsoft, and most probably does this in his spare time. More people like this can help bring Brython up even more, so there's a majority coverage for what JS can do, with Brython. Joining their Groups forum really shows you how much they're working and how much they're dedicated to this. This is only going to keep growing, if more devs and contributors hop onto the project even in their spare time.
Fantastic there is brip, I like to check in on Brython from time to time, and the lack of something like Brip was one reason I haven't been able to use it more.
I guess being able to take the C parts of extensions and have them compiled with emscripten would be a logical step further.
Starboard is completely different from Brython, although it is cool. As for pyodide, it still involves proper working knowledge and literal implemetation of JS - Brython just needs you to know the bare basics, the rest is just pure Python
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".
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.
Highly recommend looking into Munch, "a dictionary that supports attribute-style access, a la JavaScript."
https://github.com/Infinidat/munch
In theory, implementing attribute-style access on user-defined Python object is just a matter of overriding its __(get|set)attr__ methods, for example:
In [1]: import collections
In [2]: class DotDict(collections.UserDict):
2 def __getattr__(self, k):
3 try:
4 return self.__getitem__(k)
5 except:
6 return super().__getattribute__(k)
7 def __setattr__(self, k, v):
8 try:
9 self.__setitem__(k, v)
10 except Exception as e:
11 super().__setattr__(k,v)
In [3]: d = DotDict({'a': 'b', 'c': [1,2,3], 'square': lambda x: x*x})
In [4]: d.square(4)
Out[4]: 16
In [5]: d
Out[5]: {'a': 'b', 'c': [1, 2, 3], 'square': <function <lambda> at 0x7f9ef5d5b0d0>}
In [6]: import datetime
In [7]: d.created_at = datetime.datetime.now()
In [8]: d
Out[8]: {'a': 'b', 'c': [1, 2, 3], 'square': <function <lambda> at 0x7f9ef5d5b0d0>, 'created_at': datetime.datetime(2021, 7, 19, 19, 42, 32, 341393)}
In practice, this can lead to headaches. Take, for example, what happens if we try to serialize `d` (which has a non-serializable lambda function in its keys) using the built-in pickle module:
In [9]: import pickle
In [10]: pickle.dumps(d)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
_pickle.PicklingError: Can't pickle <class 'DotDict'>: attribute lookup DotDict on builtins failed
Thankfully there's a third-party library called cloudpickle which can serialize just about any python object to bytes -- even including the user-defined DotDict class (!):
In [12]: deserialized_d = cloudpickle.loads(cloudpickle.dumps(d))
In [13]: deserialized_d
Out[13]: {'a': 'b', 'c': [1, 2, 3], 'square': <function <lambda> at 0x7f9ef650fee0>, 'created_at': datetime.datetime(2021, 7, 19, 19, 42, 32, 341393)}
Since the entire class definition is serialized along with the instance, the deserialized copy preserves the object's attribute-style interface as before:
In [14]: deserialized_d.created_at.strftime("%c")
Out[14]: 'Mon Jul 19 19:42:32 2021'
But I recommend Munch over rolling your own because subclassing `dict` is fraught with a surprising number of edge cases.
this is the default stdlib with everything, you have tools to transpile only what you need and make it much smaller: https://www.brython.info/static_doc/en/import.html. Also after first launch it is stored in indexedDB, which speed up import the following times.
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 implementation for client-side web programming - https://news.ycombinator.com/item?id=9792536 - June 2015 (60 comments)
A Python 3 implementation for client-side web programming - https://news.ycombinator.com/item?id=5807059 - June 2013 (117 comments)
Brython, Python in the browser - https://news.ycombinator.com/item?id=5133047 - Jan 2013 (65 comments)
Brython - Python to Javascript translator - https://news.ycombinator.com/item?id=4923530 - Dec 2012 (68 comments)
(That last thread and the June 2013 thread are good for anyone worried that HN has become more negative lately...)