[HN Gopher] Popcorn: Run Elixir in WASM
       ___________________________________________________________________
        
       Popcorn: Run Elixir in WASM
        
       Author : clessg
       Score  : 130 points
       Date   : 2025-05-15 17:14 UTC (2 days ago)
        
 (HTM) web link (popcorn.swmansion.com)
 (TXT) w3m dump (popcorn.swmansion.com)
        
       | nelsonic wrote:
       | Very promising. But still not stable. One to watch.
        
       | Muromec wrote:
       | AtomVM is something like 1m when compiled, isn't it?
        
         | mathek wrote:
         | Compiled to WASM it's ~700K, gzipped only 190K. But there's
         | also BEAM code - the whole standard library is ~3M gzipped. We
         | plan to do tree shaking to only include the used parts of the
         | stdlib - then it should get way smaller for most use cases.
        
           | Muromec wrote:
           | That's a lot of wasm and beam. I tried to do it the other way
           | -- compile beam straight to wasm and it seems to work in
           | straightforward cases, producing wasm binaries in kilobytes
           | sizes. With wasm fx it's even possible to do processes
           | natively. You can find the link in bio.
           | 
           | Cool thing would be to somehow wire it up to liveview to make
           | it possible to run some parts on the frontend side
           | transparently.
           | 
           | I'm not doing any active development on it right now, but it
           | looked pretty doable when I tried last time.
        
       | pesnk wrote:
       | Congratulations on the project! It works great, until we need to
       | handle the best part of Elixir, that's creating multiple actors.
       | 
       | This Task code, for example doesn't work.
       | Enum.map(0..10, fn(_) ->         Task.async(fn -> IO.puts("new
       | process") end)       end) |> Task.await_many()
        
         | mathek wrote:
         | Tasks seem not to work indeed, but spawning processes works.
         | Try                 Enum.map(1..10, fn _i ->         spawn(fn
         | -> IO.puts("new process") end)       end)
         | 
         | Also, there are two scenarios: compiling code in the browser
         | and running it, and running precompiled code in the browser. In
         | the latter case more things work, for example the 'game of
         | life' example uses GenServers, Supervisors and Registry:
         | 
         | https://popcorn.swmansion.com/game_of_life/
         | 
         | https://github.com/software-mansion/popcorn/tree/main/exampl...
         | 
         | But yes, it's still unstable. Improving the stability is our
         | main focus right now.
        
       | Lord_Zero wrote:
       | I'm honestly surprised at how slow WASM is moving. As a very
       | experienced web dev, when I first learned about WASM I was sure
       | people would be building production UIs in Python and Golang and
       | other traditionally server-side languages.
        
         | Muromec wrote:
         | Wasm doesn help much with UI, its more about moving parts of
         | the server into the client as blacboxes with no access to dom.
         | 
         | The blackbox can of course return the state of UI to be
         | rendered/pathced, but that doesnt unlock much (if any)
         | interesting capabilities for amount of overhead it adds
        
         | eterm wrote:
         | Well there's blazor, which does that rather well, but it's
         | treated with the same suspicion that most MS frameworks are.
         | The fear that it'll be killed for poor adoption, leading to
         | poor adoption.
         | 
         | The blazor adoption probably isn't even that bad, but it's hard
         | for MS to shake this stigma since so many people got burned on
         | Silverlight and don't ever want to make the same mistake.
        
           | throwawaymaths wrote:
           | I thought blazor failed because people didn't like websites
           | that take minutes to load up all the websites assets. I'm not
           | sure why, it could be:
           | 
           | - Technical issue with blazor performance or blazor makes
           | perf regressions hard to fix
           | 
           | - blazor technical framework encourages programming style
           | that is bad for perf
           | 
           | - blazor or blazor ecosystem attracts programmers that can't
           | deal with perf issues
        
             | josephg wrote:
             | As I understand it, blazor really needs WasmGC in order to
             | have good performance and small bundle sizes. Otherwise,
             | blazor is forced to ship a GC inside the wasm bundle - and
             | that adds a lot of weight. And it also makes it more
             | complex to share C# objects with javascript.
             | 
             | WasmGC is supported in all browsers + nodejs now, but its
             | still pretty new. Safari only started shipping it in
             | December last year. I'm not sure if wasmgc is the default
             | build for blazor, or what the status is on it.
             | 
             | Blazor should be able to be good, small and fast. (Maybe
             | even smaller than rust web frameworks.) But I don't know if
             | we're there yet.
        
               | lylejantzi3rd wrote:
               | Doesn't Blazor include the entire .net core runtime? Or
               | has that changed?
        
               | chris_pie wrote:
               | .NET doesn't use WasmGC because Microsoft found it too
               | different from how .NET's GC works. Which is quite
               | unfortunate
        
               | josephg wrote:
               | Oh what a pity. Anywhere I can read more about that?
        
           | pier25 wrote:
           | Blazor wasm is just too heavy for most use cases.
           | 
           | In terms of speed, it's not even close to anything else in
           | JS:
           | 
           | https://krausest.github.io/js-framework-
           | benchmark/current.ht...
        
         | afavour wrote:
         | That's actually what I feared the most and I'm glad we haven't
         | seen it happen.
         | 
         | Python and Go are not small languages, making users download
         | entire runtimes to do something that can be done fine without
         | them would be a huge shame. The performance problem with web UI
         | is the DOM, not JavaScript.
        
           | lylejantzi3rd wrote:
           | You can mitigate some of that with web workers, but it's a
           | shame that multiple websites can't share a python runtime the
           | same way they can on a shared linux box. You have to download
           | a separate one for every website that uses it. But, if you
           | follow that train of thought to the end, you wind up with the
           | browser itself bundling those runtimes, just like it did with
           | Flash back in the day.
           | 
           | I'm not sure any of this would be an improvement over what we
           | have now.
        
             | chii wrote:
             | the only good reason to build these runtimes is to enable
             | existing applications to be recompiled into wasm for use
             | inside the browser - it doesnt make sense to greenfield an
             | application that uses non-web UI libraries, only to then
             | bundle the entire UI runtime with it.
        
           | hinkley wrote:
           | At least with Go static analysis should allow you to tree
           | shake the bits you aren't using.
           | 
           | The problem with the CDN solution was always that it assumed
           | that everyone would be on a couple versions and that never
           | happens. With success comes more contributors and with more
           | contributors come more point releases and more users who are
           | not on the latest version.
           | 
           | So soon you could have five versions for five sites you
           | visit.
        
           | camdenreslink wrote:
           | I kind of thought popular runtimes would just be bundled with
           | the browser if we could get an "official" enough source (e.g.
           | Python Software Foundation or Google). Then users wouldn't
           | need to download a million different versions and sources of
           | Python for each website.
        
         | IshKebab wrote:
         | I really hope nobody plans to make web front-ends in Python.
         | Jesus.
        
         | jcmontx wrote:
         | That's what the .NET folks have been doing for many years now.
         | Blazor is .NET on the client-side
        
       | codetrotter wrote:
       | For anyone else wondering the GitHub repo is here:
       | 
       | https://github.com/software-mansion/popcorn
       | 
       | Couldn't find any link to it on the article
        
       | Jump3r wrote:
       | Hey, Kuba from team working on Popcorn here. I wasn't expecting
       | it to be posted on hn but here we are. Feel free to ask me any
       | question.
        
       ___________________________________________________________________
       (page generated 2025-05-17 23:01 UTC)