21–30 of 242 posts
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
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…
With the setup you described I just felt I had to write more, even if it was in the same language.
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 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.
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…
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.
I wish it got more love.
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…
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.
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.