51–60 of 242 posts
Earlier quoted context omitted.
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
Scala is more similar to traditional Java while letting functional programming shine.
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…
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…
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.
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…
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.
Earlier quoted context omitted.
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.
Nobody wants that culture in their workplace. Also the dysfunction is visible in the technical fragmentation of the ecosystem
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.
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…
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…
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
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.
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…
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....