We replaced our React front end with Go and WebAssembly | Hacker News Reader

We replaced our React front end with Go and WebAssembly

dagger.io

250 pointsmiranda_carter232 comments

Open articleView on HN

Early in the post:

> As a small team, we need to ship fast.

So they chose a solution that required them to:

> Spent almost a month prototyping

> there was no real ecosystem for Go-app UI components and we knew we’d have to write our own

> Go WASM is slow at parsing large amounts of JSON, which led to dramatic architecture

Not sure what their definition of shipping fast is, since this just sounds like resume oriented programming.

What you aren't including is the chronic cost of maintaining the status quo, which is the entire reason for making the change. Sometimes making no decision costs you more than making a risky one - and if the decision is risky, you'll want to investigate it first.

During that investigation you discover things (like having to implement your own components) and try to account for how much they'll subtract from the time and energy you save. If the calculus works out, you keep going. If it doesn't, you stop. We kept going, and now we can ship complex features and optimizations to both UIs within a day or two.

> I spent a lot of time figuring out how to render 200k+ lines of log output without crashing. This led to optimizations deep in our virtual terminal rendering library...

Interesting. I have two wildly different takes on this.

1) Dagger is such an interesting company that they let developers do whatever they want, as long as it works and works well. A good mix of pragmatism and fun.

2) Holy crap, it's a real company with real customers. Why would they attempt something like this in one of their key products, where are the adults?!

The adults would make a quarterly plan, schedule 16 hours of meeting each week, 4x the head count and put everyone into a silo. And then nothing gets done except next quarter.

Is it? What if instead it was another “We did a full rewrite and it was a mistake. Here is why” type of postmortem?

I could have been, but it wasn't so far. And even if it was, there is a lot of things to learn in such mistakes. Audacity of doing the ambitious thing and the newly gained experience of why not doing it is how we get experienced people in the industry. Otherwise it's just dogma and nobody breaks past the established practices, which are always suboptimal.

Sure, if you're like uber at the peak of over-hiring and have hundreds of engineers more than you actually need. Then go ahead and try to reinvent things and hopefully you'll be able to improve the status quo.

But if you claim to be a small team that needs to ship fast, I believe you should just pick the industry standard boring technology and grind away.

Exactly. People only look at success.

The question is to fully see (and boringly like the parent post was talking about) what are the rewards and the risks to decide if it is worth it or not. What if it made the company tanked financially (like you would have to go back to the state before but have to rewrite the rewrite because you had to change the database design in your first rewrite or something) and not be able to ship for another 6 months? Being a small team you don't have all the cash you want unless you already made it big. Also you have to explain to your investors why you won't ship. And really how come you are an expert in tech when you had to redo it from scratch so next time maybe they can reinvest.

This type of decision needs clear planning, reward and risk, and a real business goal to happen. But let's be real many times it's not the case and X is the new cool tech. I am all about being audacious but in a calculated way.

To me what they did looks exactly that -- being audacious in a calculated way that benefited them.

What could this company possibly doing that can't be handled by react or Vue or Vanilla or whatever the myriad other ones are?

Definitely, if there as a gold lesson I had with WebForms and JSF, was that frameworks that abstract the way that browser APIs work, without debugging tool for those additional cake layers are not what I want to spend my time on, unless I am told that is the way by higher ups.

It sounds like people having fun, which means they would care more and ship faster if it works out. If it doesn't work out, they will do something boring.

Why hate on people actually enjoying the thing at times when everyone with the boring stack is one round of layoff away from the door?

Why call every little disagreement and pointing out of inconsistency "hate"?

Disagreement on values, especially coupled with outright dismissal falls into the hate category for me.

The comment in GP is not a 'disagreement', it is just bad faith.

"Not sure what their definition of shipping fast is, since this just sounds like resume oriented programming."

It's not allowed to disbelieve someone's claims, especially given evidence to the contrary?

I mean, with selective quoting you can make any point you want. Let's do the full quote:

> So, we ended up with two interfaces trying to accomplish the same thing, one of them in one language and ecosystem (TypeScript/React), the other in a totally different language and ecosystem (Go), and we couldn't easily share business logic between them.

> As a small team, we need to ship fast. Having to re-implement every feature twice was just a massive tax on our velocity.

Oh. Wait. They're cutting away an entire code base and a second language & ecosystem to support. Maybe it's not quite as resume-oriented after all.

We can certainly argue if that was the right way to do this, but it's not like it's an entirely unreasonable resume padding exercise.

It simply means that, for their purposes, React wasn't good enough. Personally, I applaud any effort that doesn't use React.

>We had some very good reasons to do it: a team of strong Go engineers; a complex UI that TypeScript/React didn't scale well for

Because its a bullshit assessment, they ran into the same limitations in their obscure choice, they didn’t move fast and break things, and both choices have optimizations to deal with these problems

and we would all fail system design interviews for considering the same thing

> Personally, I applaud any effort that doesn't use React.

Why?

There needs to be competition

>We had some very good reasons to do it: a team of strong Go engineers; a complex UI that TypeScript/React didn't scale well for;

After going though demo a bit, I can see this is what they wanted to say here: we have a team of strong Go engineers who are not that strong when it comes to web frontend, the smells of it are everywhere. The signup page don't fit in the screen and have empty scrollable space around it. Every click inside the dashboard is a spinner on the whole screen with waiting for page reload. Even icons are showing their alt-texts while loading. These are all smells of just low-experience web application, but it's relieving to say React didn't scale

Web developers without mobile experience have been using React Native to create smelly mobile apps for a long time now, and it's still growing

Mobile experience is two distinct Java/ObjC worlds, so creating smelly apps on web technologies is justified by that.

> a complex UI that TypeScript/React didn't scale well for

You can go a long way with render optimizing on the web. Even some basic virtualization should allow for showing millions of log entries. Or, you could still use web technologies (OffscreenCanvas), a bit weird to go directly with WebAssembly.

Exactly, it's hard to imagine a UI so complex it would "not scale" in the browser.

Not looking like they are making Concorde cockpit or something.

I mean, the browser itself was made to display complex UI elements, and is optimized for displaying interactive dashboards (at least it tried to in the last 20 years).

Plus, computers are fast enough, if something is somehow still slow, you can still make it seem fast if you add proper transitions and fix the timing of animations and loading order. For example, maybe one log file is 10GB, of course the browser will crash if you try to load all of it in the browser. Simply preload the latest 1000 lines, then use websockets to load new data as the user scrolls. Now, if you scroll first and then load the data, the app will seem slow, the trick is to start loading the data when the scroll already reached 90% of current buffer. Anyway, tricks like this will make any app seem instant, even if things still actually take time to load.

I sometimes remember what mad tricks game developers did in the late 90s and early 00s to optimize their games and all that "web doesn't scale" crap sounds just funny to me ;)

I can hear these Gophers in the meeting complaining how TypeScript is „completely unreadable”.

I was slightly worried it would be one of those “render to canvas” frameworks (which are an accessibility nightmare and are ever so slightly broken), but that’s not the case here! Looks like WASM – DOM interop is finally fast enough for this to work.

32 MB binary is a big no-no though.

Not a fan of this bundle size, but it's not a web store landing page — it's a professional application, and it's users are likely to use it extensively through their day, and all hundreds of navigation events and new tabs will (if handled correctly) hit the same cached bundle.

It’s a good point, but keep in mind that’s 32 MB of code: you can cache it, but you still have to parse and initialize it for every tab. (It might not be as bad as it sounds, WASM is lighter in this aspect than JS; but it’s still a good proxy for startup performance IMO.)

It should work well for applications with longer session size, like Figma: you open a project one time and work on it for hours. I’m not sure if that’s the case with Dagger Cloud: you might be looking at a single trace, or compare dozens of builds throughout the day. The post only claims “better overall performance and lower memory usage”, but without any numbers it’s hard to tell anything.

I use golang WASM and use web workers and shared workers with a service worker.

This means that a new tab does not reload the whole thing each time.

Once you get it going it’s easy to build large complex systems.

I also struggled with the binary output size of Golang WASM, and that it was growing with each version. Someone recommended TinyGo, and although I haven't needed it for a couple years now, at the time the WASM binary output size was much better.

Now I am settled on Zig/WASM, which gets me pretty close to C/WASM combo i.e. tiny. The JS bridge has some overhead, but I've rewritten most of that and it works good enough for canvas 2D/3D or even DOM. It would be nice to ditch the JS bits, and I suspect the compositors all-the-way down are probably hitting my 2D performance.

I’ve been looking at Zig for some time, too. Perhaps I should give it a go!

Any particular tricks on making bridged DOM fast?

https://crates.io/crates/sledgehammer#:~:text=Why%20is%20it%...

I use a custom API on the JS side, and making the most of the shared memory for strings. For widget creation within DOM I have small API wrappers on the JS side to avoid too much bridge crossing with attribute sets/gets.

For 2D/3D moving the canvas animation loop to the JS side helped.

So far the html (inc custom JS API) comes in at 20KB, and my wasm around 80KB (SVG based UI with a small embedded font).

Not sure how the latest Zig compares, but I'd be quite happy stuck on this older version for this project because it seems very stable.

i swear, some people hate rust as much as the comment sections claim rust people are fanatics

Looks like it was compressed to 4MB, but still.

Figma is much more than that and lots of people use it daily

Coincidentally, I just checked the LinkedIn page of a colleague, and Vivaldi said it was loading ~30MB of data for that.

Yeah, but with most JavaScript frameworks (and even Rust compiled to WASM), 4MB (at most!) would be the size of the uncompressed bundle.

I had the same worry: that they'd be rendering everything into a canvas. It's very neat to see that the WASM<>DOM interop is there now, and they render actual native elements. Even inspecting the DOM it's quite readable (far easier to read that I've seen React produce).

OTOH, Rust solutions have been pretty disappointing so far; usually relying on macros (which are a pain to write, debug or maintain in any way) and lots of DSLs (which negate the value of any development tools).

The binary size for this approach is a big issue, but assuming that it can be decreased, I'd think that go can end up being a very viable candidate in this space.

They've decided to create their front end using https://go-app.dev/ . From that page: "Go-app is a package for building progressive web apps (PWA) with the Go programming language (Golang) and WebAssembly (Wasm)."

Go isn't a very good fit for this kind of thing. I've done it with Rust (Leptos, Dioxus, etc). The wasm binaries are a lot more sane when using Rust. On average, my wasm binary was around 240kb and it compresses really well over the wire.

Why not Zig?

Why not Rust? Zig does not have nearly the same memory guarantees as Rust, I mean, why create a new language and still make the same fundamental errors when we've fixed them in other languages. That's also how I feel about Go and its lack of algebraic data types.

Zig is a completely different language than Rust. Memory safety is just one aspect. I personally find Rust to be very difficult to read and can never manage to be productive in it.

Lacking memory safety is a fundamental mistake in my opinion, not merely one aspect. We have learned much from the days of C and C++, so much that companies are migrating away and finding that many of their bugs are solved with memory safe languages like Rust.

I forgot to follow up on this, I don't know how to make HN give me some kind of a notification on replies to my comments.

I should have been a bit more clear. I love memory safety. But I dislike a lot of other aspects specific to Rust. I would much prefer e.g. C with memory safety (somehow). So that is, for me, why not Rust. Rust is more more than just memory safety.

https://www.hnreplies.com is an unofficial way to get comment replies via email.

Perhaps you should look into Vale or Pony then, they have memory safety like Rust, also without a GC, but they use different mechanisms for it.

> I don't know how to make HN give me some kind of a notification on replies to my comments

I built https://hackernewsalerts.com for that

Zig doesn't have a 1.0 release yet so I'd be hesitant to use it on any production projects. I've dabbled in it for some toy projects just to get a feel for the language and so far I think I still prefer Rust although the simplicity of Zig is something I can get behind.

What does Zig offer over Rust in this use case? It makes lower-level operations easier, but that's not super relevant to most UI work (unless you're Figma)

What about Go causes large binaries?

Go's "nothing is async because everything is async" model, combined with WebAssembly's (current) lack of support for stack switching and arbitrary goto, essentially mean that the compiler needs to insert extra code everywhere to support arbitrarily un/rewinding the stack.

This massively bloats binaries and means that go compiled to wasm is much slower than native speed, significantly more so than than the equivalent slowdown for c/rust.

see https://github.com/golang/go/issues/65440

Well, for one, you need the whole Go runtime.

Can that at least be a separate wasm file from some common URL so the browser can cache it?

You can't have dymanic linking of two C-like libraries compiled to wasm, because you would not be able to pass pointers around. Basically everything you compile to wasm becomes static binary which needs some bitfiddling to interact with.

Hm, so besides not having cross-site caching like ahoka mentioned, you can't even use some common fast CDN to host the compiled runtime.

It's more of a go problem than the wasm problem. Don't bundle such a big runtime and pass memory pointers around and you can have nice things.

Something beam-hosted with zero pointer sharing between nodes and smaller runtime maps to wasm much better.

It's also unfortunate for a lot of heavy JS libs out there that they can't be cached locally anymore, but security is important.

One WASM-related case I've actually encountered in the wild is Unity web. Similar problem as Golang, the runtime is heavy.

Browsers don’t do that. Caches are not shared across sites.

Nit: they don't do that anymore, because cross-origin caches cause privacy problems. But they used to, and this news is still percolating through the industry.

Some of them still do, if someone is using an outdated enough browser :D for example Chrome <86 (released 2020).

Didn't expect that, but not very surprised. So short of the browser giving the Go runtime some special treatment, this sounds like a no-go.

Can't be done until Wasm Components are widely supported by browsers and everything in wasmland moves at turtlespeed for various reasons...

Probably that Go has to ship heavier runtime (with its own GC etc)

Probably that. Kotlin waited until wasm GC was available and now has a compiler that relies on that. Kotlin wasm binaries can be pretty small depending on what libraries you use.

Probably a bit of work but there should be no reason why Go would not be able to do the same at this point.

.NET is still not using WASM GC for Blazor, because it doesn't support all the use cases in .NET runtime, that is the thing wiht having a single GC implementation for everyone.

People tend to think all GC are the same, they are not.

Would be interesting to see a follow up in a few months on whether the tradeoff from a heavier but widely used stack to a possibly more performant but certainly more esoteric one works out positively.

I can’t imagine trying to hire for a front end developer to work on something like this is that easy compared with finding a react dev.

Do you think maybe this is less of a big deal in the brave new world of chatGPT.

I know I have zero worries about having to code in a new language or framework with the ability to get answers so quickly to my dumb questions, but maybe that is because I’m still choosing languages and frameworks that are fairly popular and have so much online documentation that the LLMs know about them, and if something is really esoteric maybe the help wouldn’t be that good?

Due to the restrictions (short term at least) when it comes to training data and availability of documentation, I believe coding in a new language or framework becomes an even bigger mountain than usual due to chatGPT providing misleading information.

This is made worse if there are breaking changes in a new release that you are using. Even when the thing is popular, like Svelte, it was giving me outdated information before the introduction of Runes that often led to deadend packages or solutions that resulted in odd performance.

I'm sure eventually it'll be resolved, but ultimately I would only recommend people sticking to more traditional languages and frameworks that have been around for many years now and are relatively unchanging in order to benefit from chatGPT. Basically, the more projects you find using that thing on github, the better your outcome is going to be with current LLMs.

Maybe JS devs will learn to stop reinventing the wheel every half a year thanks to the knowledge cutoffs.

React was released 11 years ago and is the de facto default choice for most of the web applications.

They have definitely chilled out on "reinventing the wheel" quite a few years ago.

No? React reinvents itself constantly. I've worked on React websites and am currently working on a React Native app. React was first classes-based, now there's functions, hooks and it will soon get a compiler. Not to mention that they nudge you to use Next.js (and Expo for RN) now. Svelte did the same with the switch to these god awful Runes. Not to mention a lot of libraries that constantly get deprecated or don't work anymore with React 19.

No. JavaScript is a mid-level developer’s heaven — everyone has a right to framework

I think companies are way too worried about hiring developers based on their specific technology they’ve previously worked with.

Unless maybe you are doing something radically different, like web development to graphics drivers or something.

Development skills are typically very transferable between languages, libraries, etc. And I think it’s healthy for developers to branch out and try new tech stacks from time to time.

I’d be more worried about a developer who doesn’t have the versatility to pick up something new. Because they probably also haven’t invested the time and effort to really understand what they’ve worked on in the past.

Your example of web devs writing drivers is why I posed the question, as go is very much not a widely used web dev language, and the devs who know go may not at all understand the common web development patterns and practices.

Rather than the specific language, I’m more thinking of the domain, meaning ‘web devs who know go’ being a smaller cohort than ‘webdevs who know react’.

Go is a pretty popular language for web servers, so while "react devs who know go" might be small, "go devs who know react" might have large overlap.

I think it’s better to have somebody who has a deep understanding of all layers of the application rather than only one part.

If a developer is already an expert in the back end using Go, then great. Maybe they’ll bring a different perspective when they work on the front end. And they will probably enjoy a new challenge.

Web development is not so hard that a good developer can’t learn the basics in a couple months, especially with some mentoring.

I wouldn't say that web dev is "hard" as in any part would need a very deep knowledge, but it sure as hell very wide.

There are so many things and concepts, multiple must-know languages, browser quirks, some networking knowledge, CORS, etc. If you do use an "industry-strength" backend framework then the complexity surely drops, e.g. it will handle injections and stuff, but not having heard at least a bit about what your framework does for you, and reinventing the wheel can go really bad really fast.

If you’re trying to build a team from scratch, you probably want to hire devs with relevant experience.

But I think it’s a sign of an unhealthy or immature team if it is unable to onboard and train new developers.

You are right that a new developer could easily make a lot of mistakes, but it is the responsibility of the senior developers on the team to give feedback and review the code of less experienced members.

An LLM makes it even more beneficial to use popular tooling, because it's going to be better at answering questions about it. Meanwhile it's basically useless for whatever I'm doing at work with internal tools unless I have a pure language question (which for C++ is still ehh).

Maybe this is what will get people to stop reinventing wheels.

In the brave new world of chatGPT, developers will be in for a shock once they get good enough to generate executables.

It will be like looking for a job as Assembly programmer, when everyone else has moved into high level programming languages.

Better improve those architecture design and social skills.

If anything, LLMs require "boring tech" much more so than people.

Sure, it may know the language, but God save us from all the hallucinating in case of some niche lib

Hey, I’m the creator of go-app. What a surprise to come across this post on HN! I’m really happy to see you folks built something that fits your needs with it. Wishing you continued success with your product!

What is the benefit of writing Go to generate HTML?

1. With go-app

  func (h *hello) Render() app.UI { 
    return app.Div().Body(app.Text(fmt.Sprintf("Hello %s", h.name))) 
  }

2. Compared to using templ

  templ Hello(name string) { 
    <div>Hello, { name }</div> 
  }

For me personally, the latter seems nicer

- I can see at a glance the structure of the HTML

- Completion on the HTML tags, attributes, etc

- Completion on CSS (TailwindCSS LSP for VSCode)

- Logic can still be shared with other types of UIs (e.g. CLI, Native Apps, Webkit, gRPC)

If what you want is option 1, isn't this solution incomplete. That is, the fully realised vision would be a native component / widgets API (e.g. Fyne, QT, GTK), and then generate HTML from the components?

However, "since Dagger Cloud is built as a PWA, it can be installed as a desktop or a mobile application. This makes it possible to launch Dagger Cloud like a native application and get a full-screen experience without needing to open a browser first, or just have a dedicated icon in your desktop taskbar/dock", so it sounds like the "Native App" is using a Webkit (e.g. Wails, Tauri, Electron)

Anyway, congrats on having commercial users building stuff with your project!

In a previous version, I was using HTML, but it was written as strings. This allowed interaction with Go, but debugging was challenging since the Go compiler does not check the content inside strings, and no editor provides syntax highlighting for HTML embedded in a Go string.

With the current approach, the compiler can validate the written code, making it easier to use other Go code and enabling auto-completion in editors since everything is defined in Go.

Additionally, it eliminates the need to parse HTML, as every node state is represented in a Go-based virtual DOM, with only updates being pushed directly to the actual HTML nodes.

The key point here is that the UI can integrate background mechanisms written in Go, making them easy to use within the interface.

> Additionally, it eliminates the need to parse HTML, as every node state is represented in a Go-based virtual DOM, with only updates being pushed directly to the actual HTML nodes.

That looks really interesting. I'm curious, are there any performance drawbacks to updating DOM via WebAssembly or is it negligible? I.e. let's say you are building an editor of some kind. If the entire app is in Go, that means sending the keydown event to the WASM module and having it update HTML back. Is it not better (from performance perspective) to just use JavaScript all the way?

From the webpage:

"Go WASM is slow at parsing large amounts of JSON, which led to dramatic architecture changes and the creation of a “smart backend” for incremental data loading over WebSockets, using Go's rarely-used encoding/gob format."

From https://pkg.go.dev/encoding/gob

"This package is not designed to be hardened against adversarial inputs, and is outside the scope of https://go.dev/security/policy. In particular, the Decoder does only basic sanity checking on decoded input sizes, and its limits are not configurable. Care should be taken when decoding gob data from untrusted sources, which may consume significant resources."

How do they sanitize the gob data?

>from untrusted sources

if you can't trust your own backend, step one is reevaluating your life choices

..or a career.

After years of experience I question everything ;-)

It's not completely clear from the link but it seems like they are only using encoding/gob for backend -> client transmission over the websocket. In which case, it's your own backend, it is a trusted source. But the risk is that if there is any data going the other direction over the websocket in encoding/gob format. Probably best to just avoid completely.

Go JSON parsing isn't just slow in WASM, it's slow in native code also. I've never dug into why though, surely there are some big cost savings if this were to be optimized?

At work the Go backend was also using gob encoding in one case to store some values in the database. After some profiling, I noticed it was the top allocation part of the whole app. It was also showing on the CPU performance profiles. Finally some very light “fuzzing” (just a case were the wrong value was written to the database, and reading it back crashed the app) made me decide to rip it out and use JSON instead. Instantly, this section of the code disappeared from all profiles. I honestly do not understand why this format exists in the Go standard library and I would never use it. There are plenty other formats available…and a decoder should never crash in the face of invalid data!

WASM makes sense for certain niche use cases but it's really absurd just to make a regular web app.

This is an app made with go-app and it loads 3.6MB of WASM code for a simple media player.

https://lofimusic.app/collegemusic

It's not much different for Blazor. Even for a simple app you're looking at an initial load of at least +1MB.

People get really hung up on page weight. It's nice when an app loads fast with a cold cache, but if it's something that you load once and then keep open, or it's something that's easily cached for a long time after the first visit, page weight is much less of a worry for most users.

Code complexity is more of an issue in apps like this one. I'd guess that a WASM binary of a Go app is going to cause the JS engine to be busy a lot more than a typical JS app, which will increase CPU usage a lot, and eat into the user's battery life. That is a guess on my part though. Maybe WASM optimizes that?

The problem with wasm is also not having a straightforward way to load the thing in chunks.

I think the right way to do it for frontend is running small isolated apps that communicate with each other through channels or actor model or what not.

I believe Blazor can load chunks of WASM.

Open the network tab on this Blazor app (not mine).

https://stalcrafthq.com/

(you need to delete the app data in the Application tab of Chrome for the WASM files to reload)

You certainly can have multiple wasm apps on the same page and you can also implement you own runtime linker. It's just not the wasm thing. I don't know which one blazer is doing because I won't sit there and reverse engineer it npw.

I'm not arguing about page weight per se. The more code you have to download, parse, and run, the more CPU and memory and battery you'll be using.

WASM enables certain use cases like using FFMPEG in the a browser or game engines running on canvas which are super cool. But for 99.99% of DOM related functionality, JS is really the way to go.

Edit:

Here's another example. Loads and executes like 10MB of WASM code for something that could be done in 100kB of JavaScript.

https://stalcrafthq.com/

Author of ScHQ here. I want to explain the Blazor use here.

While I think it's a bit of a stretch to say it'd be 100kB JS (the app does a LOT of client-side lifting, so it'd definitely take more than that), otherwise you're right - WASM, specifically Blazor, is heavy. It's a bunch of download and non-ideal start time.

The reason I use Blazor here is that I work on this website alone, as a hobby project. This means I prefer to use tech (C# and .NET) I like to use instead of going lenghts learning additional frameworks. It also enables server and client share same code in places, so it can be used both in client and on server without having to program it twice. The website wouldn't be even nearly as feature rich if I had made it in JS.

The point I am making - I'd not advise Blazor use for every app, and if you already are familiar with JS frameworks, they're a good (or even better) choice. However WASM and Blazor has niches outside of "I do super fancy stuff" websites. It makes rich website development possible for backend devs and other people familiar with other technologies. It's good to think outside of the box sometimes.

Interestingly enough, it loads just 1.15 MB compressed with the biggest assets being logos on Firefox. At the same time, I can see it downloading far more assets (as if, unpacked and uncompressed blazor bundle?) on Edge/Chromium. What's going on?

Make sure you open the page in incognito/private window.

Apple music web player loads >8MB of resources. Spotify loads >12MB. Sure this is including some images etc. not just the code bundle, but it's not like other examples of SPA's are small.

IMO the end solution for this bundle size issue is for browser vendors/wasm designers to work with languages to setup cross site caching for these large language runtimes, built and distributed from trusted upstream builds instead of individual websites. Let me inform browser to link my wasm go app against a specific well known version of the go runtime built as wasm.

I'm sure it would need some work on the language side (go specifically statically links against the runtime at build time) but I'm sure it can be made to work.

> Apple music web player loads >8MB of resources. Spotify loads >12MB. Sure this is including some images etc.

I wasn't counting content, just the WASM files.

Spotify , SoundCloud, etc are not great examples as their players are bloated with tracking features etc.

Our player at Wavekit[1] weighs 33kB (compressed) and is customizable, includes multiple web components, etc.

[1] https://wavekit.app/

Will just comment that I think there is huge value on having all pieces (front end/back end/apps) on the same language if at all possible, especially for small teams.

I've gone the other direction, which is basically "Typescript everywhere", or at least as much as possible, i.e. React on the front end, NodeJS on the backend, and Capacitor for apps (note Capacitor may not be appropriate for all types of apps but in our case it was).

Hard disagree.

Just as I disagree about "full stack" developers. People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both.

Just the same Languages have their strengths. Using a backend language to write your frontend is more or less a waste of developer resources. Chances are if you just chose react and typescript you could pull things off the shelf and have almost an unlimited amount of resources and developers you could pull from compared to an esoteric LiveView or webassembly type framework, get the project done faster, ship and iterate as opposed to reinventing the wheel and satisfying the commonly felt NIH syndrome.

Typescript for both frontend and backend is a bit better, but the backend story for me is still weaker than using Python or elixir, etc simply serving an API, because if you are building a company, 9 times out of 10 you are going to have to have an API anyways. I like to have the boundary of that API explicit.

the only exception to the above is if you aren't building a company and instead working on a small personal or group project.

> Almost never have a met a person who was equally good at both.

Doesn’t that say more around your surroundings? I’ve definitely met people that were equally competent at both (and more competent than most). A lot of things that are important on the front-end are equally important on the back-end and vice versa. Lets add databases and infra while we are at it.

The thing is, you need an actually senior engineer for that. Not some kid right out of college that is somehow called a principal.

These are totally different skill sets with very different tool chains. Front and backand are as dissimilar as carpentry and cabinetry, or geography and geology, or tailoring and fashion design.

On the frontend you need to deliver excellent user experience, deliver accessibility, localization, cater to different—sometimes legacy—browsers. Even if you have a graphic designer, you still need to work with your designers to deliver a good UX.

On the backend (I think) you need to deliver optimization, and speed, you need to work within confines of your infrastructure, or work with your infrastructure engineer, you have to design databases and optimize your storage and delivery. You also need to deliver a good API for your frontend devlopers, otherwise they‘ll complain. I‘m a frontend developer so I bet there are tons of stuff backend developers do which I don‘t even know about.

It really depends on the product (or feature) how much of that expertise is necessary. You need some domain experts for sure who really know the ins and outs of the specific backend and frontend technologies to architect the overall app and build system, and do the hardcore stuff like optimization that you mention.

But fullstack engineering is just much more individually productive, if you're updating a settings page why involve multiple engineers and coordinate a handoff, when one engineer can just add the API calls on the backend and add the new toggles to the frontend in a single day? Most software doesn't need to be beautifully polished and completely excellent.

Anyway I personally just find it fun, I get to breathe life to a vision end-to-end and tackle a wide variety of problems, and I can deliver quickly. Even if I'll never be (and don't desire to be) a super expert in one technology.

> On the backend (I think) you need to deliver optimization, and speed, you need to work within confines of your infrastructure

I hope the same applies for frontend. Let's not have the 20MB bundles (definitely exists) and seconds before a page loads etc.

> which I don‘t even know about

Security!

> Security!

This is why no-one should hire me as a backend developer ;)

They’re definitely not totally different, it’s still programming. I’m competent in both and have occupied both roles in my career, but more importantly I’ve worked with people much better than me in both areas :) They were more similar than they were different.

I do agree with you that there are skills specific to each layer of the stack and they don’t all cross apply. You definitely don’t get to be good at backend and then magically be a strong frontend engineer! But I think a good backend engineer has a bright future as a good frontend engineer and vice versa, should they choose to pursue a different branch of our discipline.

Carpentry and cabinetry are both wood working as well, and both professions have somewhat of an overlapping tool set. However the professions are still very different, and being good at one will not make you good at the other. A good carpenter will have to learn a whole new skill set if they want to be a good cabinet maker.

By your own admission, you are a front-end developer, so why do you feel qualified to make such a broad, sweeping statement? Just because it feels different now does not mean it will once you’ve spent years working with it. Just the idea that ‘optimization’ and ‘speed’ are a back-end thing…

It’s a very recent thing that these things you describe are even considered related to front and back-end at all. If you go even 7 years back you’d have needed to consider all these as a “back-end” developer.

How you optimize for speed, size, and memory are very different between the frontend and the backend. On the frontend the best optimization is quite often to simply let the backend handle it.

For example if the the app is too slow because we are pulling in thousands of records and rendering it to the DOM, the correct optimization is to paginate the results. Both frontend and backend devs should know that. However the frontend dev needs to make the pagination a fluid UX for the user, decide between page controls or infinite scroll, implement search on type, set the correct aria-attributes so assistive technology knows this is an incomplete list, etc. The backend dev however needs to optimize the database queries, decide on the type of pagination (keyset vs. limit-offset vs. cursor etc.) and map the response such that the frontend won’t have to do too much work ones received (I guess a frontend dev should be able to do the latter; but it is hard to ask a frontend dev to be an expert in optimizing database queries; or implement proper keyset pagination [although if the UX team decides on infinite scroll that limits the possible pagination types a little]).

> If you go even 7 years back you’d have needed to consider all these as a “back-end” developer

I have been a frontend dev for almost 15 years, and I very much disagree with you here. I don‘t think that in 2018 you could expect a backend dev to implement responsive layout, deliver accessibility, localization, delivering to different browsers (case in point: Intl.PluralRules became widely available 7 years ago).

This may have been true in 2009 when web-apps were fairly simple (often just a series of form submissions), you had a good idea about the screen size of your users, it was hard to mess up accessibility (and yet, many developers did), localization was mostly done on the backend, single page apps were almost unheard of, etc. But not in 2018.

> I don‘t think that in 2018 you could expect a backend dev to implement responsive layout, deliver accessibility, localization, delivering to different browsers

This is all HTML & CSS. Bootstrap made responsiveness normal ever since it was introduced. If you have any form of server rendered application you have to handle these. It’s not like you can choose to hand it to a nonexistent front-end dev, since there is no separate front-end.

You articulated it beautifully.

I think a lot of frontend engineers can do backend work and vice versa, but it takes a lot to be very good at both. It's not impossible but also I think it's rare that a backend engineer would voluntarily decide to also become a frontend expert instead of leveling up their backend skills.

Fullstack in my experience arises out of a need by companies and startups to cut costs by having a single engineer do both.

A true fullstack developer is a jack of all trades.

The adage being "A jack of all trades is a master of none, but oftentimes better than a master of one."

A fullstack developer is not two developers in one. A dedicated backend or frontend dev will always overperform a fullstack dev in their side of the stack.

But while a good fullstack dev is not useful to a more mature company, they are invaluable to a startup, early stage company or greenfield project where building fast, lean and "good enough" is the target.

One of the important things about employing full stack engineers at small companies is that the skillsets of frontend and backend don't always meet the needs of the work they're doing.

Consider two examples: sending an email, which requires typical frontend skills but is by nature in the backend code; and configuring invisible backoff and retries in the frontend, which is the opposite.

I call myself a full stack engineer even though my ability to do design-adjacent work is pretty bad because I've spent a lot of time working in this middle ground. When you want to e.g. move PDF generation from the server to the client, or you want to untangle the horrible Redux caching layer that doesn't invalidate things properly, that's a specific blend of skills that's neither fully one nor fully the other. This is less about cost and more about a niche between the two fields.

Consider also data engineers, or teams with a technical lead rather than an EM, or any other role that sits between worlds.

I think it depends 100% on the person.

I’ve met people who haven’t solved a partial differential equation in 10 years and still remember how to do it whereas some people barely remember the library they used last week and have to keep a mountain of notes.

The people in the former camp have a lot of very deep knowledge on a lot of things.

Someone who can solve a partial differential equation with an hour refresher after ten years but most importantly can identify a situation where a differential equation is useful even if they can't solve it outright is still useful. If they're keeping a zettelkästen level system of notes and can get back up to speed on the specifics quickly but retain conceptual knowledge then I don't see any reason to dismiss them.

One issue our industry has is how to identity a great generalist. Broad conceptual thinking is harder to test and interview for than specialized tasks.

The second part of that adage was added on I believe centuries after the attestation of the first part. It's still a nice saying, of course. I think there's a third part to the phrase but I can't remember it for the life of me.

That's true, but the original phrase was from the 1500's so added centuries later could still mean centuries of usage.

It's important to not see any iteration of the phrase as either praise or insult. There is nothing wrong with being a specialist or a generalist, only that there are uses for both.

Most of the time being very good doesn't matter, when you're thrown into a process that's designed to extract mediocre work out of everyone, regardless of how good they are.

I'd imagine it's more common that a frontend dev moves to backend dev role.

From my experience a fullstack dev can be a lot more productive than two separate devs when it comes to adhoc work like bugfixes and adding small features.

Also they tend to have very good API design skills, since they understand both sides intimately.

> I’ve definitely met people that were equally competent at both

Tbh this is a meaningless statement. How on earth is any sane person supposed to compare competencies?

I both describe myself as full-stack and associate with other people who do the same. There isn't a single person among us who would try to pitch ourselves as equally competent on the front end and the back end. Who would do this? Why? To what end? This simply ignores why people actually use the term "full stack": to indicate willingness to take on work, not competency.

> I’ve definitely met people that were equally competent at both

This is somewhat silly because there's no good way to compare backend and frontend abilities. And why would you! A full stack engineer indicates willingness to tackle both sides, no equivalent competancy.

> Almost never have a met a person who was equally good at both.

I am literally that person. It's a good thing we've never met, or you wouldn't be able to say that anymore!

Edit: Sorry for sharing my professional responsibilities, where some of my clients pay me for front-end work, some for back-end work, and some for both. I forgot that people on the internet that have never met me know what I do better than I do, and that I'm not good at it! Please don't tell my clients that have been paying me continuously for 15 years....

perhaps you are the exception that proves the rule :shrug: or perhaps its hard to objectively measure one's owns abilities. which is the most common thing i have seen from "full stack" interviewees.

> perhaps you are the exception that proves the rule

As someone who worked directly with OP, I can confirm they are highly exceptional. Don't be too surprised when you encounter talented people on HN. I challenge you to be more inquisitive, rather than dismissive.

Or, you just think you’re literally that person. No offence, I’ve met my fair share of developers who are full of themselves but are barely tolerable at best.

Well they didn’t say that they are specialist level at both. It could be that they are mid/good level at both, which isn’t a particularly egotistical view to have of oneself. I got the impression that they were highlighting their skillset is more broad than deep, which is basically what you’d expect from a good full-stack developer.

I’ve met a lot of programmers early in my career who were full of themselves, and a number of more experienced ones later in my career that understood their own capabilities very well.

The devs who don't ooze ego over all of their code and just let their code speak for itself are often the best developers.

In my experience, I've seen no benefits (and sizable downsides) to using Python on the backend when the front end is React vs. using Node. There are tons of robust API frameworks for Node, a huge ecosystem, etc. So with Node and Python it's more potayto-potahto, and if that's the case, there are benefits to having everything in Typescript for standard server/client cases.

Note I'm not saying do this everywhere if there is a place where there are clear benefits to using another language. For example, while IMO the difference between Python and Node on the server for standard CRUD type apps is really one of preference, that's not the case for doing something with ML or LLMs, where the ecosystem around Python is much bigger, robust, and more generally familiar to the AI crowd.

What are the downsides? Benefits are if you use something that uses Pydantic models (say, fastapi + sqlalchemy) for example you seem to be able to get more granular control over DB types than, in my recent experience anyway, we had using Prisma / Nextjs.

We switched over, have fastapi generate an openapi.json, then use Kubb to have it auto-generate typescript types (it can also do zod models), done.

TBH the hardest thing for a long time about Node backend engineers isn't that there isn't great frameworks but a lot of times people choose node for the above use case. So developers who write Node backends were some breed of frontend people who chose node because they didn't want to learn another language as opposed to learning the language because it was the best tool for the job.

Anyways recently the typescript backend scene is developing a lot better than even a few years ago. stuff like NextJS becoming more popular and more stable better backend typescript frameworks coming out.

My comment was mostly aimed at using backend languages for frontend as opposed to necessarily targeting Typescript

Yeah, I agree with that. When I first saw the title on the article I thought "ergh...", because while I think Go is a fine language that really excels in some contexts, the number of developers who are familiar with "Go for the front end" is vanishingly small. My initial distaste was tempered by the fact that I thought they at least had a good reason for wanting to eliminate "need to code twice" for their different front ends.

FWIW I was a primarily a Java server developer for the first ~15 years of my career, then switched to Node and really loved it. It was at that point that I fell into the benefits of my "Typescript everywhere" mantra because it solved so many problems I had seen with the common setup of Java on the backend and Javascript with the rise of SPAs on the front end.

On my company’s latest project we are using Spring Boot on the backend with Typescript and React on the front-end. We are using Swagger for API specs which means we can generate type safe Typescript code for the front-end, including schemas for Zod and Tanstack query functions. With this codegen I can’t see many benefits to using Typescript on the backend, although the project is a rather standard CRUD app. I can understand why you might not want to use Java, but surely there are better backend choices than Java or Node?

I am curious - could you explain how you are benefiting from using Typescript on both back and front end?

I replied in another comment here, https://news.ycombinator.com/item?id=43009065.

When I've posted this before, the main objections I've got have usually been from the perspective on individual developers, or stuff like "you can't actually share a ton of code between front-end and back-end". That's not my primary point (though there are some places where it is nice to share code, e.g. input validation that you may want to run on the client for user experience/performance reasons but then that you also need to run on the backend for security reasons). The biggest benefit I've seen is in team dynamics which results in bugs getting fixed faster and new features getting added faster because it's easier for team members to "cross" backend/frontend boundaries.

I think you feel that way because you're comparing Node to Python. Neither of them are particularly good languages for servers. Languages like Go and Java/Kotlin are much better when you're building complicated systems that need to be performant and reliable.

Hard disagree on Node (at least if you're using Typescript) not being a good server language, and I say this as someone who was a Java dev for the first 15 years of my career. I've seen more performance nightmares with Java compared to a well-written Node server, though Java has improved a ton in recent years with things like virtual threads and the community has generally seen the error of the unnecessary AbstractFactoryBuilderGenerator shit that was so common for a long time in Java.

Go is not the best for ML and scientific applications in my experience. Orchestration is fine but the libraries just aren’t there, Gonum alone is way behind NumPy/SciPy

It's kind of funny to me how derided full stack developers are as unskilled generalists. It would have been unthinkable back when I started web development to only learn half of what it takes to build a website.

> People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both.

Full stack developer here who disagrees. Most web apps are not that complicated and if there are the term 'backend developer' will be replaced with something more specialised as well.

> the backend story for me is still weaker than using Python or elixir, etc simply serving an API

That is a very odd statement, Python has a lot of issues that NodeJS never had, in terms of developer experience I believe NodeJS is superior just based on the fact that I don't need to know what a virtual environment is and I don't need to choose between different incompatible package managers before I even write my first line of code.

> if you are building a company, 9 times out of 10 you are going to have to have an API anyways. I like to have the boundary of that API explicit.

If the only consumer of the API is your frontend, why would you want to have such a strong boundary?

> the only exception to the above is if you aren't building a company and instead working on a small personal or group project.

This statement can easily be hard countered by the rise of full stack frameworks like NextJS and the fact that the whole backend-frontend separation didn't always exist, it mainly happened because of SPAs.

I never interpreted Full Stack to mean homogenous competency, which is a rather strange concept if you think of it.

In fairness, the goalposts for frontend dev shifted significantly in the past 10 years.

But also, no one thinks Full-stack developers are experts at everything. We are well aware they are the jack-of-all-trades developer archetype, that's why we hire them. They come in all kinds of shapes like you allude to, more like a starfish of skillsets with varying degrees of skill in each leg.

But perhaps the best thing you get out of the starfish, is you know they'll be able to pick up whatever you throw at them, and they won't complain that that they can't do it because it's not "frontend" or not "backend".

Corallary, good programming is universal. I find people tend to be experts in business domain and framework, regardless of where that lives on the front/back spectrum.

As backend developer/devops that dabbles in (Web) frontend, I am fully spot on the point of view.

The only kind of frontend I could equally consider myself good, are native frontends on Apple and Microsoft platforms, but that is because native GUIs do most of the UI work and don't require CSS wizardy skills to turn divs into drop down boxes with type-ahead search.

I also think having one language can be a detriment at times. The JavaScript that you write on the server is so different than that on a browser. Same with Clojure/ClojureScript. This idea that everything is in one language so everything is understandable to everyone just isn’t true in my experience. It’s more like trying to learn to speak Brazilian and European Portuguese at the same time

There is something to be said about language _pairings_ though. I was building with a Python backend and ClojureScript front end for about 8 months and it. was. [expletive]. miserable. The context switch between the two languages was insane.

I rewrote the backend to Elixir and the problem completely went away. No more context switching. Elixir is amazing at what it does. ClojureScript is amazing for UIs and state management. Everything is functional and immutable.

That being said, I do occasionally wish the data validation could be written in one language and used on both places. But that’s just the engineer in me - in practice I have had 0 data validation mismatch errors

When you have a team of full-stackers with some front-end focused, some back-end, and some in the middle, with the right team culture these people can learn from each other and grow into well-rounded full-stack devs.

And given the current market, companies can be more selective.

backend engineering is really straightforward nowadays. same as frontend, its mostly knowing a couple tricks about how to format data. mostly is language agnostic api calls of some kind and you can have minimal transformation code over some fully managed platform. typescript seems to be one of the more supported transpilation tools.

So what? Both of these developers would be able to ship a typical feature in a typical web product by themselves, without back-and-forth with their counterpart all the time, and that's a huge productivity boost. May be at some point help from a subject area expert would be needed — set up proper db indexes, center that div properly on a small viewport. But being able to iterate without the need to communicate, debug miscommunications, or wait on another person’s availability is a massive efficiency gain. Most product work doesn’t require deep specialization—just someone who can get things working end to end, refine as needed, and know when to pull in an expert.

The alternative is siloed devs constantly handing off half-finished work, where backend waits on frontend for an API contract, frontend waits on backend for an endpoint, and everyone waits on QA. Been there, done that. A competent “full stack” dev sidesteps that bottleneck and ships.

> So what? Both of these developers would be able to ship a typical feature in a typical web product by themselves, without back-and-forth with their counterpart all the time, and that's a huge productivity boost.

Its a short term productivity boost sacrificing for long term maintainability and future productivity.

I would take 1 backend engineer + 1 frontend engineer over 3-4 "fullstack engineers" any day of the week.

What is the sacrifice, specifically?

Same reason you hire an architect, electricians, carpenters and plumbers to build a house instead of getting an equal number of handymen and telling them to get at it.

Thats not to say a layperson can't build a house, but having experience and training about a specific domain can make later modifications and updates significantly easier.

I find this comparison overly simplistic.

You don’t get back to architect when you’re doing plumbing. You don’t get back to plumbing when doing electricity.

And not only those are often highly isolated tasks but those domain have specialist in it as well. You might go to electrician who can do high voltage installations and you don’t care because he can to general wiring too (thus being full stack).

But there’s different about sacrifice that’s bigger issue. In software engineering handoff costs can be absurdly high. Teams can be allocated and if backend team misses on deliver the next window of opportunity can be in couple weeks. In micro, highly agile teams it’s yeah whatever, but I’ve yet to see a dedicated team of frontend/backend that’s on standby for the other party.

JS can serve API all the same as Python, and faster in most cases.

> Just as I disagree about "full stack" developers. People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both.

I would not be surprised if in 10 years from now, there will only be full stack web developers.

I am a desktop developer (yeah, Electron). There's really no front-end / back-end split in this domain. Electron is pretty much everything web front-end (in a "SPA, choose your own adventure" way rather than relying on a framework to do the heavy lifting) and all the business logic that is self-contained within the app and putting it all together with the APIs Electron exposes. I know that a local self-hosted back-end does not have the complexity of a distributed web-backend, but it's still much more than just front-end and there are areas of development that are probably more "wide" and definitely more complex than this anyway - like video game development or C++ / QT desktop development.

Now what happens to the front-end now? Full-stack frameworks like Next.js. They also simplify the front-end part to death, where you do not even get to think about state management anymore. Then you add generative AI...

Also consider this, is a front-end and back-end engineers with 10 years experience at a large co that much better at their respective domains than a full stack with 5 years of experience at a startup? I cannot say for the back-end, but I can say for the front-end - there's a ceiling and it does not take long to reach it (maybe 5 years). You stop getting much better once the ceiling is reached. So what makes someone good is both reaching the ceiling and continuing to do the work on a daily basis, rather than specialising in an area, in my option. A video game dev with 20 years of experience probably is much much better than one with 5y. But front-end? I don't think so.

This was my view once, but practically the languages have their own ecosystem strengths, now I think most of the major languages have similar concepts, async await, etc.. instead we now teach transfer your skills, and tbh I think it makes for a more interesting culture that's adoptive and excited by tech, and also learns better

It’s called being a software developer instead of being a JavaScript developer. If someone knows how to engineer software, their skills are transferable. Stitching libraries together is usually not software engineering.

software engineering is mostly a kludge of interacting with stuff people have made and will make, rather than physical limits of different materials and structures

stitching libraries together is the essense of soctware engineering

Definitely. Although Go is the simplest language with sane/good concurrency support so it's a good fit for Node.js/TS and Python shops that have run into a use case where they feel limited by their main language or runtime and need a concurrent backend service to implement a feature.

Kotlin also has amazing concurrency support. Plus you get the additional benefit of the entire Java ecosystem.

I wish it got more love.

Kotlin is not simple. it has like every language feature in existence

Why do people always mention kotlin, but not Scala?

Scala is more similar to traditional Java while letting functional programming shine.

Scala is way superb for concurrency than what Go or Kotlin have to offer. But it is a complex language with a high learning curve.

> Why do people always mention kotlin

It's backed by $$$ that have promoted it that way - a "better" Java.

Honestly, I think it is because the Scala community was/is/can be so pedantic and bickering and often combative and toxic that it lost all momentum and appeal.

Nobody wants that culture in their workplace. Also the dysfunction is visible in the technical fragmentation of the ecosystem

Kotlin’s structured concurrency and coroutines as a library are remarkable pieces of software engineering. It’s a great language and ecosystem… but

Modern java has been grabbing features from all the “better Java” languages at such a pace that the big gap right now that I see is the question mark operator.

> I wish it got more love.

.NET is in the same predicament. Very convenient and highly efficient concurrency primitives.

Typescript’s concurrency story is much stronger than go’s.

Unlike Go, but like Rust, it has a reasonable type system, and is data race free (since JS is single threaded).

Anyway, I come from a C++/Rust background, but have been using TS recently, and it’s a much nicer language than I’d have guessed.

I get the potential appeal in having a single language do all things, but in practice the front-end and back-end have vastly different jobs and different capabilities, so I see no issue in them being different languages and letting them utilize their strengths. Not to mention the vast amount of complexity you need to involve at some point in order to bring a language to a side it wasn't meant to be in.

moreso, you cant share promise chains or streams well across api boundaries, so it isnt seamless, even in the same language

This is why Rails is a decent solution for many apps. It’s “Ruby everywhere” including the data layer.

No disrespect to you but I'm constantly reminded of this quote:

    "Consistency is the hobgoblin of little minds"
      -- Ralph Waldo Emerson

It's this same idea that led Google down the garden path that was (is?) GWT: Java everywhere. It seems like a good idea but for every platform you add, you reduce the total the lowest common denominator between them. You add transliteration bugs and issues.

Google also trie to do this with Protocol Buffers on Javascript front ends and the serialization methods were... suboptimal. Because obviously you can't do (or at least couldn't at the time) binary encoding and decoding on a browser.

All this is why we've seen multiple attempts to, say, allow you to write an app that'll work on iOS and Android. React Native springs to mind.

Now if you can come up with an end-to-end Typescript solution, that's great. But it's also a pretty severe constraint and one that doesn't, for example, solve the native mobile platform issue.

I have pretty positive experience with Capacitor, actually. Precisely because it doesn't try to be e2e solution that shields you away from the native platform. It doesn't stand in your way when you want to do something native, it's more of a toolkit to manage the bridge between WebView/Native land.

I think it's a safety concern, I'd like to explicitly know whats being ran on the client vs the server.

And react introduces a host of dependencies which may be ill maintained. The only reason to bring this up in an online forum is because I'm tired of recruiters constantly asking for react and nodejs.

I disagree. I don't think it's too much to ask of software developers to be the bare minimum of competent enough to wire up a basic web service in whatever language they are dealing. REST is not complex.

REST is not complex.

REST isn't complex, but API design is still hard. Making a strategic choice not to design a service API but to ship the same code in two places is valid, and arguably the right one if that's what the teams skills lend themselves to.

Over the past two decades I’ve seen a well implemented RESTful API exactly once, in a relatively small project. The rest of REST apis are ad-hoc RPC over HTTP, I’d argue because it isn’t complex and complexity moves to the client.

At the least, tools that minimise the usage of certain languages (i.e. JS if you're not a JS shop) or general frontend boilerplate will also do this.

See: Rails Hotwire, Laravel Livewire, Alpine.js

Or Elixir + Phoenix + LiveView.

I guess this depends a bit on the project but pretty often yes. I currently maintain Typescript SPA with PHP backend and the split between languages is very frustrating, it induces a ton of pointless busywork. If the backend language was something stronger, than I'd be willing to accept that split to get those benefits, but having two different scripting languages seems quite pointless.

IME, the productivity promise falls short. I have found major gains following an integrated framework over multiple code bases with the same language.

With the setup you described I just felt I had to write more, even if it was in the same language.

I don't understand your comment. There are plenty of integrated frameworks that work well between Node and React.

More importantly, though, you seem to be commenting from the perspective of an individual developer. The biggest productivity gains I've seen is that it makes it much easier for people on different areas of the team to understand and fix/modify parts of the code that they're least familiar. E.g. if I'm a developer that spends 99% of my time on the front end, but then I need some extra field that's not being returned by the backend, instead of having to do a full context switch, get an environment up and building that I may not have compiled in a long time, get my brain "switched over" to a different language, or worse, file a ticket and wait for the backend team to fix it, it's much easier if I can just go in quickly and add the field I need.

I've seen this in spades on small/medium teams - it really "lowers the barrier to entry" for people being able to submit PRs in parts of the codebase that is not their primary day-to-day work.

> it's much easier if I can just go in quickly and add the field I need

This assumes that just because it's the "same language" it's all the same.

It's especially true in Javascript land where the React setup is vastly different than the Node backend framework setup.

You get bundler differences, ESM/CJS, different versions of Node (or even Bun / Deno), linters or things like decorators, etc... You can be doing "functions" with React and then head to classes and modules with NestJs all of a sudden.

It pretends to be much easier. I've seen lots of real world assume-there's-a-shortcut method that just makes it worse.

Perhaps use an integrated framework with one codebase then? RedwoodJS is one of these.

Gleam might be a good fit for that.

> I've gone the other direction, which is basically "Typescript everywhere", or at least as much as possible, i.e. React on the front end, NodeJS on the backend, and Capacitor for apps (note Capacitor may not be appropriate for all types of apps but in our case it was).

Absolutely bad advice and totally disagree.

So having a language such as TypeScript which is already built on top of an even more immature language such as Javascript in critical systems software or highly regulated settings is a good idea?

Having it on the backend is also bad enough, but everywhere really an indication of not being able to adapt into using a properly designed language for the specific use-case and just being inflexible because you are 'used to the language'.

This is not even talking about the entire TS/JS ecosystem which is has a sea of libraries which most of them are also immature and not production-grade at all.

The ecosystem is a bit insane, JavaScript is a disaster, but typescript itself is very, very good. IMO it’s better for complex backends than Python, and I’ve been doing Python since before Django 1.0.

That said I’m patiently waiting for dotnet renaissance.

Sounds like a straw man to me

Would love to see profiling to show where the React approach was falling short.

I get their reasoning and I admire the courage.

But IMO they should have went with Rust -- smaller WASM binaries and even better memory footprint. And they said these were concerns. So IMO they didn't go far enough.

But it's also completely understandable. They already had a Golang codebase. So it was either go all in in the JS/TS ecosystem or all in in the Golang ecosystem. They made the right choice but again, they could have went even further and kill all birds with one stone. A heavy and quite time-consuming stone, granted.

The large binary size isn't because of the language. It's just really poor optimization.

I've been searching for something like https://go-app.dev/ for years and never knew it existed. I wonder what else I'm missing.

>> We had some very good reasons to do it: a team of strong Go engineers; a complex UI that TypeScript/React didn't scale well for;

I simply do not believe the "complex UI that TypeScript/React didn't scale well for; "

That's just piffle.

It's them saying they don't know how to use React.

Without much more detail/evidence we must assume this is just a way of excusing themselves for doing something that makes no sense.

Here is a demo I made of React getting plenty of scaling done:

https://static.crowdwave.link/index.html

And the source: https://static.crowdwave.link/sveltetest.zip

This is pretty interesting. I have some questions.

Since I don't know the product, I don't understand why doing all of this data crunching on the frontend. Seems like the same motivation could be applied to moving more of the heavy work to the backend before sending results to the frontend. Making the app more of a thin client. Am I missing something, is there a reason to keeping the work on FE?

Cost. To take it to an extreme, you could render everything on the back end and stream video, like GeForce Now or Stadia, but in doing so, the backend needs to be quite beefy. As clients these days usually have some modicum of processing power, doing it on the front end so you're not also playing for an extra fleet of VMs on the backend saves money and increases revenue. At a high level, you want the line for revenue to have a higher slope than the line for costs. Not a huge deal from 0-1 customers or 1-10, but does become an issue at scale.

That doesn't seem to be the case here - they already mentioned that the data is heavy, which means they have to send a huge amount of data over the network, only to crunch it down and show a subset of it (I don't think the UI shows all of that data at once). This seems more costly than sending some UI updates over the wire, for example.

Is there a video of this ui??

Here's one of our public traces if you want to try the real thing: https://v3.dagger.cloud/dagger/traces/6898273d59ad62a6df1e9e...

I think some of it is shown on this page:

https://docs.dagger.io/features/visualization/

So, this is similar to .NET's Blazor. The same issues apply. Startup should be faster for Go's smaller runtime.

I never imagined I would say I miss flash. Flash somehow worked while loading.

We don’t just reinvent the wheel, we forget to reinvent airbags and all nice stuff too

Wait until Blazor switches from Mono-WASM to NativeAOT-LLVM. There will be zero chance for Go to compete :)

AFAIK It can also do SSR, SSG and hybrid rendering, I keep being skeptical on Blazor but everyone I know who tries it out keeps signing it praises so...we'll see how it goes.

Is it even possible to make this combination screenreader accessible?

I guess there may be a way to do that using a parallel DOM structure that exists to give the screenreader something to hook into, but at that point it's probably easier to go back to using HTML.

This seems to use the DOM. I don’t think it’s like Flutter, unless I’m missing something.

Yes, a DOM structure, parallel or otherwise, is needed. Dioxus does this with rust and WebAssembly and it seems it should be able to do just about everything a js app does and it’s competitive in the rendering benchmarks.

It is HTML, it uses WASM to DOM bindings. That being said, Flutter does have screen reader accessibility, if you look at their docs.

Seems like a bunch of go programmers really wanted to use go, no matter how impractical.

DOM based UI in WASM is kinda pointless. It's both slower and hard to debug.

The same can be said about React Native on mobile, but everyone is doing it nowadays

Going by the article and not having had a look at the code I assume you replaced React but not all JavaScript. In that light, did the fact that WASM can't access the DOM directly pose any obstacles?

This is the power of WebAssembly. It brings every language to the browser.

The golang compiler that came out 3 days ago builds much smaller WASM binaries .

Still doing tests and benchmarks marks

I wish the source for this were public, it seems like a really interesting example codebase to peek at and try to learn all the little details of a real-life application.

That's awesome! I hope to see tutorials on this, and how to use Brotli compression to reduce the size of WASM file

Oh boy. Resume driven development if I've ever seen it. Ugly "functions as HTML." Big binaries. This is going to be a nightmare to maintain and onboard new developers to.

I get it, React is so very uncool and those ninja rockstar developers are too good for React. I suppose Alpine or HTMX are too "simple" for the ninja rockstars. Enjoy writing the world's ugliest markup until someone with some sense gets hired and makes everyone re-write the font end in 6 months.

You can't convince me this was a good idea

I was excited to try it out but the necessity of using either GH or Google SSO is a bit of a turn off.

Everyone wants your data.

> a complex UI that TypeScript/React didn't scale well for

why do I have the feeling that virtual tables on tanstack would have solved their use case using typescript/react

Tanstack is supposed to be about headless UIs right? Didn't that trend kind of die down? It doesn't seem to hit a sweet spot between something prebuilt and something custom. I took a look this and tried reading several and it seems all right, but not especially interesting:

https://github.com/TanStack/table/tree/main/examples/react

Died down? In what sense?

It's a low level table implementation, it's not supposed to be that sweet spot, there are many other table libraries, often written in top of TanStack table, like AG Grid.

Headless stuff died in the sense that it got integrated into the mainstream ecosystem and people stopped buzzing about it.

My initial reaction was to be horrified for these guys, and ooh boy the comments didn’t disappoint.

But this is an open telemetry data aggregation and analysis tool (at least that’s what my half hearted perusal of the post led me to believe).

Probably not too heavyweight for such a tool, although my default response would be a Tannenbaum-like admonishment. Or maybe the Jurassic Park response.

I will say I have seen worse wastes of resources.

Let them have their fun. Either they learn from this implementation for v4, or it works out and there is no need for v4, in which case, as they say, the proof will have been in the pudding. Win-win.

They probably won’t like their egress bills tho.

Just use the left tool for the job.

Not much to see here. Just backend developers hating on JavaScript and looking for workarounds to avoid it that will come back and bite in the neck the poor souls that will have to pick up the project after the current Go devs leave.

I've been writing client-side JS/TS for many years and still enjoy it, but there are scenarios—quite a few in my opinion—where targeting WASM is a better technical and business choice. It's just a "right tool for the job" kind of thing.

> Our switch from React to WASM has resulted in a more consistent user experience across all Dagger interfaces,

That doesn’t sound like an issue with React

> and better overall performance and lower memory usage, especially when rendering large and complex traces.

That doesn’t sound like a problem that WASM is more suited to than well written html/css/js

Reply on news.ycombinator.com