7 ms·

But on the flip side, you can program the backend in anything you like, instead of being bound to javascript.

by freeone3000 1y ago

sroussey 1y ago
JS/TS is fine. Why switch back and forth between languages and frameworks and data models and…
- baq 1y ago
  If your axiom is ‘JS is fine’ then yeah. It isn’t, though. TS is much closer to ‘fine’, but still can’t avoid some dumb JS decisions.
  - chipsrafferty 1y ago
    It is fine, though.
    - const_cast 1y ago
      No, it’s footgunny and riddled with bugs. Most JS barely works and edge cases just aren’t addressed. I’ve seen undefined make it all the way to the backend and get persisted in the DB. As a string. JS as a language just isn’t robust enough and it requires a level of defensive programming that’s inconvenient at best and a productivity sink at worst. Much like C++, it’s doable, but things are bound to slip through the cracks. I would actually say overall C++ is much more reasonable.
      - Capricorn2481 1y ago
        > I would actually say overall C++ is much more reasonable. This is where I know that, some people, are not actually programming in either of these languages, but just writing meme driven posts. JS has a few footguns. Certainly not so many that it's difficult to keep in your head, and not nearly as complex as C++, which is a laughable statement. You've "seen null make it to the database," but haven't seen the exact same thing in C++? Worse, seen a corrupted heap?
        hombre_fatal 1y ago
        Yeah, I don't know how someone can say that with a straight face to other engineers. It's like people just talk in memes or something. This is how a lot of discourse feels these days. People living in very different realities. Though in this case, seeing the most complex C++ app they've built would illuminate what's going on in theirs.
        const_cast 1y ago
        It's not a different reality. To give perspective to what JS I've dealt with - I worked a couple years on a legacy webapp. It used vanilla JS and the only library used was jQuery. It heavily used iframes for async functionality in combination with XSLT to translate backend XML apis to HTML. Opening up a 10K lines JS file is like jumping into the ocean. Nothing is obvious, nothing makes sense. You're allowed to just do whatever the fuck in JS. Bugs where always ephemeral. The behavior of the code was impossible to wrap your head around, and it seemed to change under your feet when you weren't looking. Now, the backend was written in old C++. And yes, it was easier to understand. At least, I could click and go to definition. At least, I could see what was going in and out of functions. At least, I could read a function and have a decent understanding of what it should be doing, what the author's intention is. The front end, spread across a good thousand JS files, was nothing of the sort. And it was certainly more buggy. Although, I will concede, bugs in C++ are usually more problematic. In JS usually it would just result in UI jankyness. But not always.
        sroussey 1y ago
        > You're allowed to just do whatever the fuck in JS. I think that’s a feature not a bug. But then again, I generally like and use Typescript.
        const_cast 1y ago
        It's definitely a feature when you're starting out. But as the codebase grows and ages, it becomes a bug. The problem is that the behavior becomes so complex and so much is pushed to runtime that there's no way to know what the code is actually doing. There's paths that are only going to be executed once a year, but you don't know which ones those are. Eventually, editing the code becomes very risky. At this particular codebase, it was not uncommon to see 3, 4 or 5 functions that do more or less the same thing. Why? Because nobody dared change the behavior of a function, even if it's buggy. Maybe those bugs are the only thing keeping other bugs from cropping up. It's like wack-a-mole. You fix something, and then the downstream effects are completely unpredictable. It becomes a self-eating snake. Because the codebase is so poor, it ends up growing faster and faster as developers become more risk-averse.
      - sroussey 1y ago
        You really need to learn a language to use it. As for undefined vs null, I fine it useful. Particularly in a db setting. Was the returned value null? You know because the value is null. Did you actually load it from the database? sure, because the value is not undefined.
  - CuriouslyC 1y ago
    I've been a professional programmer for ~20 years and worked in a variety of languages on a variety of different types of projects, and Typescript with Bun is mostly just fine. It lacks some low level primitives I'd like to have available for certain projects (e.g. Go channels), and the FFI interface isn't as nice as I'd like, but it's basically serviceable for for a very broad range of problems. You should still know a language like Rust or Zig for systems work, and if you want to work in ML or data management you probably can't escape Python, but Typescript with Bun provides a really compelling development experience for most stuff outside that.
    - baq 1y ago
      I agree, nowadays working on mostly TS backend with some parts in JS written before async/await was introduced and I’m inclined to say TS is better than Python at most things bakcendy. I’m missing sqlalchemy and a sane numerical tower pretty much.
      - freeone3000 1y ago
        Python suffers from the same problems: its type system has many escapes and implicit conversions, making soundness opt-in and impossible to statically verify. Any language with an implicit cast from its bottom type to an upper type is unsuitable for use.
    - AlchemistCamp 1y ago
      It reminds me of an older dev I met when I was just beginning who had worked even more years and said Fortran 95 was "fine". And he could use it to build pretty much anything. That doesn't mean that more powerful language features couldn't have increased his productivity (if he learned them).
      - CuriouslyC 1y ago
        There's something to be said for using the right tool for the job. There's also something to be said for maximizing your ability to hire developers. Software is a game of tradeoffs, and while I can and do still pick up modern hotness when warranted (e.g. Zig), sometimes the path to minimum total software cost (and thus maximum company value) is to take well trodden paths. As fun side anecdote, if you're doing scientific computing in a variety of fields, Fortran 95 is mostly still fine ;)
- hjgjhyuhy 1y ago
  If you already know another backend language and framework, all you need to do is tell LLM or some code generator to convert your models between languages. There is very little overhead that way. I greatly prefer Java with Spring Boot for larger backend projects.
- aweiland 1y ago
  What is 0.1 + 0.2 in JavaScript. I'll give you a hint, it's not 0.3. Is that fine?
  - viraptor 1y ago
    That's not a JavaScript issue. It's the same for almost any language where you don't use some bignum type/library. This is something all developers should be extremely aware of.
  - baq 1y ago
    https://en.m.wikipedia.org/wiki/IEEE_754 https://en.m.wikipedia.org/wiki/IEEE_754 To answer your question directly - yes, it’s fine, it’s actually expected behavior.
SJC_Hacker 1y ago
You haven’t had to deal directly with JS on front end since Dart released over 10 years ago
- freeone3000 1y ago
  Dart hasn’t been much better in my experience, but you have reminded me to revisit Kotlin/JS!
  - freeone3000 1y ago
    I tried getting json deserialization into my app and ended up with a 2MB runtime, so it’s not going great.
- catgirlinspace 1y ago
  Does anyone use Dart without Flutter? I've never seen it used separately.
  - SJC_Hacker 1y ago
    Yeah sorry I meant Flutter ... 99% of people use Dart with Flutter, they are basically synonymous
- yawaramin 1y ago
  No, you still need to deal directly with JS even with a transpiler like Dart or whatever other language you want to use. When things go wrong, and they will, you'll need to deal with the JS errors. When you're trying to debug or even call out to JS APIs, you better be intimately familiar with how your transpiler interops with JS, otherwise you're kinda screwed.

But on the flip side, you can program the backend in anything you like, instead of being bound to javascript.

sroussey 1y ago

JS/TS is fine. Why switch back and forth between languages and frameworks and data models and…

baq 1y ago
If your axiom is ‘JS is fine’ then yeah. It isn’t, though. TS is much closer to ‘fine’, but still can’t avoid some dumb JS decisions.
- chipsrafferty 1y ago
  It is fine, though.
  - const_cast 1y ago
    No, it’s footgunny and riddled with bugs. Most JS barely works and edge cases just aren’t addressed. I’ve seen undefined make it all the way to the backend and get persisted in the DB. As a string. JS as a language just isn’t robust enough and it requires a level of defensive programming that’s inconvenient at best and a productivity sink at worst. Much like C++, it’s doable, but things are bound to slip through the cracks. I would actually say overall C++ is much more reasonable.
    - Capricorn2481 1y ago
      > I would actually say overall C++ is much more reasonable. This is where I know that, some people, are not actually programming in either of these languages, but just writing meme driven posts. JS has a few footguns. Certainly not so many that it's difficult to keep in your head, and not nearly as complex as C++, which is a laughable statement. You've "seen null make it to the database," but haven't seen the exact same thing in C++? Worse, seen a corrupted heap?
      - hombre_fatal 1y ago
        Yeah, I don't know how someone can say that with a straight face to other engineers. It's like people just talk in memes or something. This is how a lot of discourse feels these days. People living in very different realities. Though in this case, seeing the most complex C++ app they've built would illuminate what's going on in theirs.
        const_cast 1y ago
        It's not a different reality. To give perspective to what JS I've dealt with - I worked a couple years on a legacy webapp. It used vanilla JS and the only library used was jQuery. It heavily used iframes for async functionality in combination with XSLT to translate backend XML apis to HTML. Opening up a 10K lines JS file is like jumping into the ocean. Nothing is obvious, nothing makes sense. You're allowed to just do whatever the fuck in JS. Bugs where always ephemeral. The behavior of the code was impossible to wrap your head around, and it seemed to change under your feet when you weren't looking. Now, the backend was written in old C++. And yes, it was easier to understand. At least, I could click and go to definition. At least, I could see what was going in and out of functions. At least, I could read a function and have a decent understanding of what it should be doing, what the author's intention is. The front end, spread across a good thousand JS files, was nothing of the sort. And it was certainly more buggy. Although, I will concede, bugs in C++ are usually more problematic. In JS usually it would just result in UI jankyness. But not always.
        sroussey 1y ago
        > You're allowed to just do whatever the fuck in JS. I think that’s a feature not a bug. But then again, I generally like and use Typescript.
        const_cast 1y ago
        It's definitely a feature when you're starting out. But as the codebase grows and ages, it becomes a bug. The problem is that the behavior becomes so complex and so much is pushed to runtime that there's no way to know what the code is actually doing. There's paths that are only going to be executed once a year, but you don't know which ones those are. Eventually, editing the code becomes very risky. At this particular codebase, it was not uncommon to see 3, 4 or 5 functions that do more or less the same thing. Why? Because nobody dared change the behavior of a function, even if it's buggy. Maybe those bugs are the only thing keeping other bugs from cropping up. It's like wack-a-mole. You fix something, and then the downstream effects are completely unpredictable. It becomes a self-eating snake. Because the codebase is so poor, it ends up growing faster and faster as developers become more risk-averse.
    - sroussey 1y ago
      You really need to learn a language to use it. As for undefined vs null, I fine it useful. Particularly in a db setting. Was the returned value null? You know because the value is null. Did you actually load it from the database? sure, because the value is not undefined.
- CuriouslyC 1y ago
  I've been a professional programmer for ~20 years and worked in a variety of languages on a variety of different types of projects, and Typescript with Bun is mostly just fine. It lacks some low level primitives I'd like to have available for certain projects (e.g. Go channels), and the FFI interface isn't as nice as I'd like, but it's basically serviceable for for a very broad range of problems. You should still know a language like Rust or Zig for systems work, and if you want to work in ML or data management you probably can't escape Python, but Typescript with Bun provides a really compelling development experience for most stuff outside that.
  - baq 1y ago
    I agree, nowadays working on mostly TS backend with some parts in JS written before async/await was introduced and I’m inclined to say TS is better than Python at most things bakcendy. I’m missing sqlalchemy and a sane numerical tower pretty much.
    - freeone3000 1y ago
      Python suffers from the same problems: its type system has many escapes and implicit conversions, making soundness opt-in and impossible to statically verify. Any language with an implicit cast from its bottom type to an upper type is unsuitable for use.
  - AlchemistCamp 1y ago
    It reminds me of an older dev I met when I was just beginning who had worked even more years and said Fortran 95 was "fine". And he could use it to build pretty much anything. That doesn't mean that more powerful language features couldn't have increased his productivity (if he learned them).
    - CuriouslyC 1y ago
      There's something to be said for using the right tool for the job. There's also something to be said for maximizing your ability to hire developers. Software is a game of tradeoffs, and while I can and do still pick up modern hotness when warranted (e.g. Zig), sometimes the path to minimum total software cost (and thus maximum company value) is to take well trodden paths. As fun side anecdote, if you're doing scientific computing in a variety of fields, Fortran 95 is mostly still fine ;)
hjgjhyuhy 1y ago
If you already know another backend language and framework, all you need to do is tell LLM or some code generator to convert your models between languages. There is very little overhead that way. I greatly prefer Java with Spring Boot for larger backend projects.
aweiland 1y ago
What is 0.1 + 0.2 in JavaScript. I'll give you a hint, it's not 0.3. Is that fine?
- viraptor 1y ago
  That's not a JavaScript issue. It's the same for almost any language where you don't use some bignum type/library. This is something all developers should be extremely aware of.
- baq 1y ago
  https://en.m.wikipedia.org/wiki/IEEE_754 https://en.m.wikipedia.org/wiki/IEEE_754 To answer your question directly - yes, it’s fine, it’s actually expected behavior.

SJC_Hacker 1y ago

You haven’t had to deal directly with JS on front end since Dart released over 10 years ago

freeone3000 1y ago
Dart hasn’t been much better in my experience, but you have reminded me to revisit Kotlin/JS!
- freeone3000 1y ago
  I tried getting json deserialization into my app and ended up with a 2MB runtime, so it’s not going great.
catgirlinspace 1y ago
Does anyone use Dart without Flutter? I've never seen it used separately.
- SJC_Hacker 1y ago
  Yeah sorry I meant Flutter ... 99% of people use Dart with Flutter, they are basically synonymous
yawaramin 1y ago
No, you still need to deal directly with JS even with a transpiler like Dart or whatever other language you want to use. When things go wrong, and they will, you'll need to deal with the JS errors. When you're trying to debug or even call out to JS APIs, you better be intimately familiar with how your transpiler interops with JS, otherwise you're kinda screwed.