Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We replaced our React front end with Go and WebAssembly

dagger.io

Post reply on HN
Print view View original

141–150 of 242 posts

Re: We replaced our React front end with Go and WebAssembly

#141

Post by fragmede »

panstromek wrote: post #131

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.

Re: We replaced our React front end with Go and WebAssembly

#142

Post by physicsguy »

xmprt wrote: post #75
hn_throwaway_99 wrote: post #73

Earlier quoted context omitted.

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 the…

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.

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

Re: We replaced our React front end with Go and WebAssembly

#143

Post by strken »

emseetech wrote: post #86
xmprt wrote: post #74

Earlier quoted context omitted.

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, ea…

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.

Re: We replaced our React front end with Go and WebAssembly

#144

Post by voidr »

hansonkd wrote: post #48
hn_throwaway_99 wrote: post #14

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 ou…

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. Chan…

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

Re: We replaced our React front end with Go and WebAssembly

#145

Post by panstromek »

hn_throwaway_99 wrote: post #14

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 ou…

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.

Re: We replaced our React front end with Go and WebAssembly

#146

Post by Muromec »

jeswin wrote: post #137
kabes wrote: post #120

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…

> 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…

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.

Re: We replaced our React front end with Go and WebAssembly

#148

Post by xlii »

adtac wrote: post #45
braindeadly wrote: post #31

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 parti…

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

Re: We replaced our React front end with Go and WebAssembly

#149

Post by panstromek »

jmyeet wrote: post #134
hn_throwaway_99 wrote: post #14

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 ou…

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…

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.

Re: We replaced our React front end with Go and WebAssembly

#150

Post by mozey »

Maxence wrote: post #114

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) { 
    Hello, { name } 
  }
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!

Post reply on HN