We replaced our React front end with Go and WebAssembly

Re:We replaced our React front end with Go and WebAssembly by jmyeet on Tuesday February 11, 2025 @01:25AM (#43009625)

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.

[ Parent | on HN ]

Re:We replaced our React front end with Go and WebAssembly by panstromek on Tuesday February 11, 2025 @01:40AM (#43009713)

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.

[ Parent | on HN ]