131–140 of 242 posts
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?
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'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 s…
That said I’m patiently waiting for dotnet renaissance.
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?
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…
"Consistency is the hobgoblin of little minds"
-- Ralph Waldo Emerson
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.
Earlier quoted context omitted.
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…
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.
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.
Earlier quoted context omitted.
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.
stitching libraries together is the essense of soctware engineering
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…
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?!
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…
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?
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.
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.