WebAssembly On The Server??? Why?

Поділитися
Вставка
  • Опубліковано 6 чер 2024
  • WebAssembly is well known for unlocking near-native performance for browser based applications, but it also has some really compelling use cases on the server as well. One of the Docker founders even stated that if it had existed back in 2008, they may not have needed to create Docker.
    00:00 Why WASM on the Server?
    00:56 Wasmer
    01:27 WebAssembly Package Manager
    02:05 Compiling To WebAssembly
    02:35 Compiling mdbook To WASM (Part 1)
    03:00 WASI
    03:37 Error compiling mdbook to WASM
    04:21 Changes necessary for compiling to WASM
    04:59 Rust Optional Dependencies & Features
    06:01 Compiling mdbook to WASM (Part 2)
    06:43 Running mdbook with Wasmer
    08:55 Publishing to WAPM
    11:00 Finding and Running The Package on wapm.io
    12:06 Review & Closing Thoughts
    ---
    Stuff I use to make these videos - I absolutely love all of these products. Using these links is an easy way to support the channel, thank you so much if you do so!!!
    Camera: Canon EOS R5 amzn.to/3CCrxzl
    Monitor: Dell U4914DW 49in amzn.to/3MJV1jx
    Lens: Sigma 24mm f/1.4 DG HSM Art for Canon EF amzn.to/3hZ10mz
    SSD for Video Editing: VectoTech Rapid 8TB amzn.to/3hXz9TM
    Microphone: Rode NT1-A amzn.to/3vWM4gL
    Microphone Interface: Focusrite Clarett+ 2Pre amzn.to/3J5dy7S
    Tripod: JOBY GorillaPod 5K amzn.to/3JaPxMA
    Keyboard: Redragon Mechanical Gaming Keyboard amzn.to/3I1A7ZD
    Mouse: Razer DeathAdder amzn.to/3J9fYCf
    Computer: 2021 Macbook Pro amzn.to/3J7FXtW
    Caffeine: High Brew Cold Brew Coffee amzn.to/3hXyx0q
    More Caffeine: Monster Energy Juice, Pipeline Punch amzn.to/3Czmfox
  • Наука та технологія

КОМЕНТАРІ • 144

  • @CharlesChacon
    @CharlesChacon Рік тому +28

    You blew my mind with that point of defragging the open-source library space. Huge boon for WASI

    • @maximebeaudoin4013
      @maximebeaudoin4013 Рік тому +6

      This is what hypes me up the most about this project honnestly. The idea of having language agnostic librairies is incredible.

    • @codetothemoon
      @codetothemoon  Рік тому +2

      indeed! it's crazy how many projects that essentially do the same thing are being built and maintained in parallel, just because of language boundaries

    • @yes-vy6bn
      @yes-vy6bn Рік тому +2

      also abstracts away hardware, enabling platform agnostic code, which along with not having to fiddle around with platform-specific code for each platform, could enable us to break free from archaic operating systems and create a new one from scratch, as long as the new OS supports WASM
      also, it can allow for a programming language renaissance bc as long as you support WASM, you can ignore the number one thing (imo) that holds back programming languages, which is lack of libraries

    • @CheshireSwift
      @CheshireSwift Рік тому

      @@yes-vy6bn The Gary Bernhardt talk The Birth and Death of Javascript is along these lines, worth a watch if you haven't seen it.

  • @lukecastellan3000
    @lukecastellan3000 2 роки тому +10

    THE VIDEO I WAITED FOR!
    WASM on the server looks so interesting 🤩♥️

  • @BrianMelancon
    @BrianMelancon 2 роки тому +90

    I can't help but be reminded of Java's promise of "Write once, run anywhere." In my opinion, Java failed horribly on that front. This was mainly because you had to install a compatible version of the Java VM on each system. In many cases you have to install multiple different Java VMs for different Java applications. Most end users ended up having to install and maintain multiple flavors and versions of Java VMs. Often when installing a Java application you ended up installing the entire compatible VM along side it just to ensure it would run.
    Interestingly, where Java succeeded most is where the VM could be locked down to a specific, known flavor and version; like servers, embedded, Android, etc.
    If WASM is going to succeed, it absolutely MUST avoid that kind of fragmentation. It HAS to be the case that if you compile to WASM, it just works on every system. There does seem to be some hope for WASM. I'm crossing my fingers.

    • @codetothemoon
      @codetothemoon  2 роки тому +42

      To add to your point - the JVM is really "heavy" both in terms of resource/performance overhead and in how it forces developers into a certain ecosystem. Initially this was the Java language, but even as more JVM languages were created, developers were still forced to use GC and other things the JVM included.
      Because WASM is not opinionated like the JVM was - ie it doesn't force you into a specific memory management model - it seems like this allows the runtimes to be lighter weight and thus hopefully be less prone to the fragmentation you're referring to
      Time will tell!

    • @jasonshen
      @jasonshen 2 роки тому +2

      yes java can but the performance can't compare with rust

    • @KitsuneAlex
      @KitsuneAlex Рік тому +2

      That is only partly true, JVM bytecode is ALWAYS upwards compatible, so if you run the latest Java (18 for example), you could run a Java 8 program just fine. The only problem would be internal APIs from com.sun packages or the like, which may have been deprecated/removed in newer versions.

    • @Mmonk111
      @Mmonk111 Рік тому +1

      Java has been providing backward compatibility. So at least by Java 8, newer version of JVM run any kind of older bytecode without problems. Since Java 9, Due to adoption of the module system, some legacy bytecode doesn't work with Java 9+. This is the one of the reason why couple of project still prefer Java 8 over Java 11+.

    • @fltfathin
      @fltfathin Рік тому +2

      @@KitsuneAlex machine code will be always be upwards compactible too, given all the instructions are always available or in wasm's case it is proven to be possible to at least simulate the instruction. btw most of the time library/ os compactibility is the breaking point for most software instead of the language's

  • @xavhow
    @xavhow Рік тому +1

    Thank you for wasi intro.
    I’ve heard of it but never thought it could or should run on servers.
    Exciting time indeed…

    • @codetothemoon
      @codetothemoon  Рік тому +1

      Thanks for watching! Wasmer is very active in development and may have more tricks up their sleeve, stay tuned for that...

  • @darkfire2703
    @darkfire2703 2 роки тому +37

    Wasm is a big step forward in the browser and extremely promising for servers but I don't think the docker comparison fully holds up. While wasm performance can be impressive, it is still noticeably slower than native code executed through docker. The sandboxing features in docker are supported by linux kernel features and run the actual CPU bound code with fully native performance.
    Nonetheless wasm is a pretty darn exciting technology

    • @codetothemoon
      @codetothemoon  2 роки тому +10

      Great point about performance - has someone done benchmarks that we can take a look at? Docker is amazing, but I think it does add a bit of friction into the development process in that you have to think about a Dockerfile, creating an optimal image without too many extraneous binaries, and make building that container part of your dev process. Not a huge deal, but the idea that WASM might negate the need for all of that is interesting.

    • @ArnabAnimeshDas
      @ArnabAnimeshDas 2 роки тому +4

      wasm is still evolving. It takes a bit of time for a new technology to catch up.

    • @tablettablete186
      @tablettablete186 2 роки тому +6

      @@codetothemoon I am doing a research on that!
      To be honest, I am quite impressed by the performance of Web Assembly: it sometimes is as fast as containers (secure ones at least)!
      To explain a little better, SECCOMP can reduce performance by a lot in conatainers!

    • @phenanrithe
      @phenanrithe Рік тому +2

      @@codetothemoon I don't know much about Wasm but I fail to see the comparison too, except they both offer a sandbox. Docker offers a native environment, if Wasm had to do that it would require an extra layer of OS in each package, making them huge and requiring a lot of JIT compilation. They're just operating at different levels.

    • @stanrock8015
      @stanrock8015 6 місяців тому

      Wasm will be v3 of containers over time.

  • @GMTX-qj8or
    @GMTX-qj8or 2 роки тому +2

    Awesome debrief of scope big hug from Australia

  • @irlshrek
    @irlshrek Рік тому +1

    Fascinating and exciting!

    • @codetothemoon
      @codetothemoon  Рік тому

      I agree! I believe they've innovated quite a bit more since I made this video, possibly more on that in a future video...

  • @sovrinfo
    @sovrinfo Рік тому +1

    Great video.Thank you a lot

  • @user-QesOrwuMqN
    @user-QesOrwuMqN 2 роки тому +14

    Hi, very interesting! I think it could easily replace any app store on mobile devices. Potential is huge!

    • @codetothemoon
      @codetothemoon  2 роки тому +3

      Wow, that's true! I hadn't thought of that!

    • @ollydix
      @ollydix Рік тому

      One can only hope.

  • @micnubinub
    @micnubinub 2 роки тому +3

    In the first few seconds I was thinking fad, but by the end I started realising the potential... Will be keeping an eye out

    • @codetothemoon
      @codetothemoon  2 роки тому

      Yeah it'll be interesting to see where developers take this!

  • @paulsalele3844
    @paulsalele3844 2 роки тому +2

    Great tutorial!!

  • @FugalBaboon
    @FugalBaboon 2 роки тому +2

    Very interesting!

  • @maximkuznetsov1906
    @maximkuznetsov1906 Рік тому +3

    Hi, thanks for the video. It's brief and helpful. Can you please make a video about how to send HTTP requests from WASM and WASI.

    • @codetothemoon
      @codetothemoon  Рік тому

      thanks, glad you found it valuable! I do plan to look into that space, maybe with Cloudflare workers which now seem to support WASM...

  • @raptorjesus3396
    @raptorjesus3396 Рік тому +3

    I would appreciate a curated list of sources in the description, so the viewer can have a looksie for themselves. Like where did you get the information about wapm from? Not just the homepage and a link to the docs. That would be awesome :3
    Thanks in advance

    • @codetothemoon
      @codetothemoon  Рік тому +2

      Unfortunately I don't have much of a list, my resources were strictly the WAPM documentation as well as direct conversations with the Wasmer folks. They are very responsive on their Discord server, I'm sure they would be happy to help with any questions!

  • @PeterBernardin
    @PeterBernardin Рік тому +6

    This is really cool. I think the whole WASM ecosystem is going to be huge. One issue I see with it though is that for example in NPM, pretty much every package is in javascript. This allows for things like tree-shaking. If every WASM package is basically machine-code, that means multiple packages that have the same dependencies may not be able to use the same binary, or if they do there will be a lot of complex inter-weaving of communication between threads that will slow down the application. I wonder how they've solved the problems that arise from the dependency tree given that.

    • @codetothemoon
      @codetothemoon  Рік тому +2

      Nice, yeah I think it shows incredible promise. I haven't dealt too much with dependency resolution in the WASM world, but I *think* all WASM-based libraries would be statically linked and invoked in their own sandbox, such that we don't have to worry about dependency conflicts when leveraging them. Not 100% sure on this though.

    • @mr-boo
      @mr-boo Рік тому

      Good point, although i assume tree shaking is less of an issue with wasm than with js due to smaller resulting packages (depending on compiler and config, of course). But you’re right that tree shaking would be very hard on the wasm level. The compiler could by recompiling your project and all its deps from source.

    • @andrez76
      @andrez76 Рік тому

      Right on. If there's one thing that beats Node.js, Java, Docker, .NET, WASM/WASI etc. in terms of being cross-platform and cross-architecture (not to mention being around longer), it's got to be dependency (hell) management. Regardless of whether one's dealing with DLLs, JARs, NPM packages, the issue pointed out by Peter always comes up. I suppose the people behind WASM/WASI are aware and probably have considered some solutions (mitigations might be a more appropriate term) but I guess a "perfect" alternative is either impossible of very hard to achieve. When possible, statically linking dependencies is a simple and effective solution. It doesn't really solve the dependency version conflict issue; instead, it forces you to deal with it beforehand.

  • @hirisraharjo
    @hirisraharjo 2 роки тому +2

    Thanks a lot!

  • @eduardabramovich1216
    @eduardabramovich1216 Рік тому

    Is it possible to write a Desktop Environment in wasm? Like gnome or kde.

  • @overra
    @overra Рік тому +4

    This is awesome. I wonder if there will be an OS developed around it.

    • @codetothemoon
      @codetothemoon  Рік тому

      Thanks Adam - I agree, I feel like operating system level support for some kind of isolated container (maybe a WASM runtime) is something we might see in due time...

  • @JT-mr3db
    @JT-mr3db Рік тому

    Running the binaries in the browser kinda blew my mind. It reduces the friction of testing a package massively.

  • @gamer-gw9iy
    @gamer-gw9iy 2 роки тому +23

    Amazing tutorial, WASM just seems like "better" java (java *can* self optimize at runtime and get crazy performance, WASM would not). Not sure if it would replace docker for most of my uses though, unless I start running hardened kernels👍 Sure do love how docker makes an isolated virtual filesystem

    • @codetothemoon
      @codetothemoon  2 роки тому +10

      thanks! yeah we'll see how things play out, Docker is awesome but it'd be nice to have OS completely abstracted away from the build/deployment process

    • @NathanHedglin
      @NathanHedglin 2 роки тому +12

      There are JIT interpreters for WASM. It'll get there. It's a newborn baby compared to old man Java

    • @JosephDalrymple
      @JosephDalrymple Рік тому

      WasmEdge anyone?

  • @cameronguilbeau5888
    @cameronguilbeau5888 Рік тому +3

    Great content, this is California before the gold rush

  • @KitsuneAlex
    @KitsuneAlex Рік тому +1

    I just recently adopted AssemblyScript into my collective's ecosystem, and it's been a pleassure working with WASM. This stuff is the future.

    • @codetothemoon
      @codetothemoon  Рік тому +1

      nice, I haven't actually tried AssemblyScript yet - seems interesting.

    • @KitsuneAlex
      @KitsuneAlex Рік тому

      @@codetothemoon it's becoming a really nice language. TypeScript on steroids with specialized extensions for WASM. Even things like external refs, ref types, pointers, sized integer types and even threads :)

  • @Waitwhat469
    @Waitwhat469 Рік тому +1

    12:40 how does this cross language library usage work? Are there any good examples of this?

    • @codetothemoon
      @codetothemoon  Рік тому +1

      new video on this very topic coming soon, stay tuned!

  • @jon2386
    @jon2386 Рік тому +2

    Is it possible to create a web assembly app that runs in the browser that calls native swift macOS frameworks?

    • @codetothemoon
      @codetothemoon  Рік тому +1

      Unfortunately I don't think so, as far as I know (I could be wrong!)

  • @Verrisin
    @Verrisin Рік тому +2

    semi-unrelated, but one thing I don't understand about new package managers - why don't they use (something like) IPFS. It seems so well suited for exactly packages.
    - less traffic for servers, deduplication, ease of sharing, more robust ... and it's all publicly available stuff...

    • @yes-vy6bn
      @yes-vy6bn Рік тому +1

      "tea" is doing this (made by creator of homebrew). the project is also trying to enable funding of open-source software (even the packages buried under layers of dependencies!)

  • @greglocker2124
    @greglocker2124 Рік тому +3

    Why did it take me almost 5 years to learn that web assembly does more than hasten the imminent demise of JS??? THANK YOU for sharing this, I can't even imagine all the possibilities this opens up for me!
    I'm about to finish a step in my project, and the next step is all about how to get a national network of bots running programs in various languages on various versions of Android with different versions of different locally stored packages (there are algorithms that analyze your packages and various other details of your device to "fingerprint" you in case you try to value your privacy and hide your personal data) to do what I want them to do, never fail, and if they do fail they still need to be reachable and thereby fixable.
    I wasn't sure how to go about that, but I figured I'd either need a custom package manager (I really DID NOT want to make that) or a controller that handles multiple package managers.
    This. Is. A. Godsend..
    Thank you.

    • @codetothemoon
      @codetothemoon  Рік тому

      Nice Greg, glad this might be part of the solution to your problem!

  • @lonewolfcoding5208
    @lonewolfcoding5208 Рік тому +2

    i think it will not replace docker
    is webassembly support running operating system like in docker
    in docker you can run almost anything safely including operating systems without conflicting on dependencies or libraries
    in docker image you can install ubuntu or centos

    • @codetothemoon
      @codetothemoon  Рік тому +2

      the nice thing about wasm is that the developer doesn't have to worry about operating system at all, as they do with Docker. I think most developers deal with operating system in a Docker context out of necessity, not because it is actually relevant to their application. So it winds up being more "boilerplate" configuration and setup that isn't really specific to the application being built.

  • @sohn7767
    @sohn7767 2 роки тому +3

    Wasm never ceases to flabbergast me

  • @redcrafterlppa303
    @redcrafterlppa303 Рік тому +1

    It's like java bytecode with a more minimal runtime and no gc, right?

    • @codetothemoon
      @codetothemoon  Рік тому +1

      Sort of - instead of "no gc" I would say "leaves memory management strategy up to the application". I'd also add that applications are run in a "sandbox" environment, where privileges have to be explicitly enabled, as opposed to the JVM which by default doesn't impose any restrictions.

  • @jomy10-games
    @jomy10-games 2 роки тому +3

    Some feedback I would give for WAPM: it’s confusing how you can use libraries

    • @codetothemoon
      @codetothemoon  2 роки тому

      how so?

    • @jomy10-games
      @jomy10-games 2 роки тому

      @@codetothemoon no examples on how you can use them and when you select “libraries” in the search, then no packages show up at all

  • @edgeeffect
    @edgeeffect Рік тому +2

    Looked at the title and thumbnail and thought "what the hell for?!?!" Watched the video and thought "Hmmmm.... this sounds like an interesting idea".
    It's funny how Java started as a cool new browser technology and eventually found a home on the server, and now WASM is following that path again.

    • @codetothemoon
      @codetothemoon  Рік тому

      Nice! Glad it evoked and subsequently satisfied that curiosity. It's true that server side WASM feels a bit like a less opinionated version of what Java was trying to achieve way back when.

  • @lonewolfcoding5208
    @lonewolfcoding5208 Рік тому +2

    i noticed most of the tutorials like this
    do we need mac to program?
    i dont have alot of money

    • @codetothemoon
      @codetothemoon  Рік тому

      No need to use a mac, Wasmer works on all of the major platforms!

    • @d.sherman8563
      @d.sherman8563 Рік тому

      No, macs just seem to be the most popular dev machines.

  • @hUwUtao
    @hUwUtao Рік тому +1

    era of union!

  • @StEvUgnIn
    @StEvUgnIn Рік тому +1

    Isn't what exactly the JVM was for?

    • @codetothemoon
      @codetothemoon  Рік тому

      In a sense. The big differences are (1) that the JVM imposes a bunch of things on the application like a memory management scheme (garbage collection), and (2) it assumes that applications should be given full access to the host system. WASM resolves both of these issues.

  • @DanielToebe
    @DanielToebe Рік тому +1

    I see a lot of promise in WASMER. What is needed is an orchestration system, and some proven distributed systems in WASM

    • @codetothemoon
      @codetothemoon  Рік тому +1

      what do you mean by orchestration system?

  • @JosephDalrymple
    @JosephDalrymple Рік тому +2

    WasmEdge looks interesting! Mixed with CRI-O + Kubernetes for Stateless? Could be a great setup. I don't get much time to toy with those kinds of things anymore, though, unfortunately. Otherwise, I would!

    • @codetothemoon
      @codetothemoon  Рік тому

      Took a quick look, it does look pretty interesting. How do you think it compares to Wasmer? Is the Kubernetes support a game changer for you?

  • @pathakvivek7865
    @pathakvivek7865 2 роки тому +2

    It is interesting..

  • @jofla
    @jofla Рік тому +1

    look for Colin Breck's latest posts on Web Assembly, WA is very promising for IoT

  • @LUN-bo2fb
    @LUN-bo2fb Рік тому +1

    comparing wasm with docker looks weird for me. they both provide isolation but on different level. it is possible that people will use wasm with docker.

    • @codetothemoon
      @codetothemoon  Рік тому

      They both aim to address the same problems, which are code portability and the "sandboxing" of untrusted code. The means by which they achieve these things is quite different, which is why WASI is so interesting. Docker seems like it would be unnecessary overhead for some WASI applications, as it's kind of a sandbox within a sandbox - but maybe there is a valid use case for that.

    • @AlfanNurFauzan
      @AlfanNurFauzan 10 місяців тому

      like using jvm inside docker?

  • @tenminutetokyo2643
    @tenminutetokyo2643 Рік тому +2

    There's no end to this shit.

  • @johnkost2514
    @johnkost2514 2 роки тому +3

    Sounds like Silverlight or Flash plugins for the browser..

    • @codetothemoon
      @codetothemoon  2 роки тому +3

      Flash on the server! That would be something 🙃

  • @jkuang
    @jkuang Рік тому

    Kubernetes is the king. Anything else is "too little, too late." All the major companies are backing Kubernetes and it has been involved DEEP AND WIDE in many corporations' server infrastructures.

    • @everyhandletaken
      @everyhandletaken Рік тому

      That is fine for the corporate space, but it is incredibly complex & WASM fits into quite a different category IMO.

  • @pchasco
    @pchasco Рік тому +4

    I am skeptical. I do not see a compelling reason to move from containers, or to stop building native apps that run in containers. The promise of library interop is much more complicated than it is presented here. Just because a library built in another language can link into any other WASM binary, that doesn’t make them compatible. Different languages use different data structures, memory layouts, runtimes, and conventions. Unless WASI solves that issue, what we are really getting here is the ability to compile code that could be run natively to bytecode, then run less efficiently under WASM than it could when compiled natively and hosted in a container. Node/deno/bun solve a problem: Enable web technologies to be run outside the browser. WASM was created to enable “compiled” languages to run in the browser. But here there is no browser. That code could just be run natively.

    • @everyhandletaken
      @everyhandletaken Рік тому

      I get your point, but containers are not the answer to everything either- though they are a wonderful thing.
      I cannot see how efficiency is higher with a container, than it is with WASM though..
      If I want to run a Docker container, I have to have the Docker daemon running, download (or build) the image & create, then start the container. The container is a virtual environment, are we expecting bare metal performance?
      For WASM I can download (or build) the WASM file & run it.
      The other bonus is that I don't need to care about whether my Docker base OS image is up to date, it isn't needed.
      Not saying you are wrong, as I certainly haven't benchmarked them as a comparison, but perhaps the comparison you are looking at isn't really the reason for or against either, it just depends on the requirement for your tasks.

    • @pchasco
      @pchasco Рік тому

      @@everyhandletaken Docker is not a virtualized environment. Containers use kernel namespacing to isolate processes and IO, but there is no virtualization occurring. For the most part, native code running in a container is bare metal. When processes under docket make system calls, those calls are intercepted and handled differently than calls from processes running outside containers, which does add some overhead. The overhead is minimal, and WASM environments will have their own overhead when making calls from the sandbox.

  • @everestshadow
    @everestshadow 2 роки тому +1

    LOL No. At least not in 5 years. I have finished multiple projects required to have a feature for wasm and it sucks.

    • @codetothemoon
      @codetothemoon  2 роки тому +2

      Client side WASM or server side WASM? What sucked about it?

    • @everestshadow
      @everestshadow 2 роки тому +2

      @@codetothemoon It's mostly about IO (the lack of it) . Last time I tried wasi is still a pain in the ass for socket and file system. In order to migrate my Rust web apps to it I basically have to write a custom IO reactor for it. And it still ends up not working like I want it to be. If you look at the Rust ecosystem stuff like tokio and async-std still have no target for wasi yet.

    • @codetothemoon
      @codetothemoon  2 роки тому +2

      @@everestshadow yeah those things are definitely big issues. still in the very early days like you said, it'll be interesting to see how things evolve.

  • @jma42
    @jma42 Рік тому +2

    its infuriating how many pitfalls and headaches we could have avoided if we only adopted new technologies, I hate how strong money is involved as a barrier for these..

    • @codetothemoon
      @codetothemoon  Рік тому +1

      Yeah it's frustrating sometimes how hard it is to move from established systems and processes to newer ones, even in the case where they are clearly better

  • @airman122469
    @airman122469 Рік тому +1

    “If web assembly existed in 2008 we wouldn’t have had to make Docker”
    Ummmm… no. Containers have many use cases and the majority of them are outside of the use cases for web assembly.

    • @codetothemoon
      @codetothemoon  Рік тому

      Which these use cases are outside the capabilities of a wasm sandbox?

    • @everyhandletaken
      @everyhandletaken Рік тому

      @@codetothemoon looks like he is still thinking about an answer to this lol

  • @rawlzi116
    @rawlzi116 Рік тому +1

    BLAZOR

    • @codetothemoon
      @codetothemoon  Рік тому

      I’ve heard good things about it, what’s been your experience?

  • @EmilNicolaiePerhinschi
    @EmilNicolaiePerhinschi Рік тому +1

    Docker became popular because it allowed running single-threaded Node apps as if they were separate systems, which pushed complexity onto the load-balancer/reverse proxy ... and it made life miserable for backend programmers
    if the authors of Docker support web assembly on the server then I'll skip it

    • @codetothemoon
      @codetothemoon  Рік тому

      Docker definitely adds a bit of friction to development, but man the portability it enables is pretty awesome. I think WASM-based platform would facilitate the same portability but with much less friction...

  • @oefzdegoeggl
    @oefzdegoeggl 7 місяців тому

    while it is obviously nice to get stuff running in the browser in a performant way, it's not the smartest idea on the server. depending on your language of course. a native rust binary will run quite a bit faster than a wasm package. why exactly would you throw away the extra performance when you have 1:1 the same development effort? to avoid packaging a little OS stub in docker? oh stop it. it's a few MB if you take alpine. even if it was a GB, i'd happily package it if it gives a 50% speed improvement over wasm. of course, "we" still had created docker, even if wasm was around 10 years before. how exactly are you going to package let's say postgresql otherwise? port it to wasm? that is nonsense. same for that idea of "all developers love each other and work together on a crypto lib, giving up their own ecosystem". hahahaha. sounds a bit like communism to me. that one did not work out. neither will this. obviously, in an ideal world, you are right. but this is not how humans work.

  • @HelloThere-xs8ss
    @HelloThere-xs8ss Рік тому +2

    Why would you do this 😭

    • @codetothemoon
      @codetothemoon  Рік тому +1

      Because portability! 🎉

    • @segeus
      @segeus Рік тому

      @@codetothemoon Why? Because I can!^^

  • @casualweekday-ytshadowbang2469

    0:38 No DO_SOMETHING_BAD. I love the safety considerations a few secs before running a curl… | sh.

  • @AMFLearning
    @AMFLearning Рік тому +2

    #amflearningbydoing #amflearning nice