4 ms·

This looks so tempting but each time I try to use something to avoid Javascript, I end up spending more time debugging the Javascript. In your experience, how

This looks so tempting but each time I try to use something to avoid Javascript, I end up spending more time debugging the Javascript. In your experience, how much time do you spend in the JS layer?

mxuribe 5y ago
Same here...i don't know about others, but over the years, the reason i have tried avoiding javascript is that the browsers/targets differ enough that its annoying...whereas it *feels* like coding in python (or other languages) seems to achieve more of the "write once, run everywhere" consistency concept...whereas javascript forces me to know about, and code for all those tiny, little browser differences. Ugh! Or, maybe i'm the only one who thinks this? Maybe it is my brain definitively telling me that i should just stick to the backend? (I'll admit that i code alot less nowadays.)
- Kaze404 5y ago
  I can't remember the last time I had to deal with browser inconsistencies wrt JavaScript. That's only ever a recurring problem with CSS in my experience, and even then it would be a stretch to call it a consistent problem in my experience.
  - mxuribe 5y ago
    That's encouraging to hear wrt JavaScript!
- chmod775 5y ago
  If you're not using features on the bleeding edge, you won't have to worry about browser differences nowadays. And even if you want to use those features, you could just use (even automatic!) polyfilling or a library that abstracts any differences away. No application I've got my hands in nowadays (and there are some with a total of more than 100k LOC) contains a single line like "if (isMicrosoftEdge) { ... }". If you're doing that, you're not writing idiomatic JavaScript. Of course you can do things that aren't portable, but writing open("/tmp/mytempfile.txt", "a") in python isn't portable either. Avoiding that is just knowing your job.
kiesel3rde 5y ago
I think one 20% of the total development time was spent on the javascript client. The client is not very complex. It pretty much makes DOM manipulation API's usable for the backend only
IshKebab 5y ago
I agree. Typescript is much nicer than Python and doesn't suffer from the problem you describe. I think you'd be mad not to use it at this point.
- haolez 5y ago
  TypeScript, if you use its strong points, has a much slower development pace than a language such as Python. To each their own.
  - refactor_master 5y ago
    How so? After having used typescript, Mypy and static languages, I could never go back.
    - haolez 5y ago
      I've started with static languages and I prefer dynamic ones over static. Code is a liability and static typing can create incentives for adding more and more boilerplate that brings little value to the table. I'm preferring dynamic languages and lots of tracing and rollback capabilities in production in 2021.
      - brundolf 5y ago
        I've found this to be a common mindset among people who started out with Java/C#/C++/etc. Modern statically-typed languages are a totally different beast. Type inference is widespread and powerful, and you end up writing very little additional boilerplate. On top of that, guarantees like the prevention of null values greatly increase the value you get from having static types. If you haven't tried one in a few years, I recommend revisiting them. TypeScript is a great place to start. PS: It's totally possible, but also totally unnecessary, to write TypeScript like you would Java or C# (lots of classes, nullable-everything, explicit types for everything). To get the most out of it you honestly have to do the exact opposite of that (turn on strict null checks, use plain types, leverage type inference as much as possible).

This looks so tempting but each time I try to use something to avoid Javascript, I end up spending more time debugging the Javascript. In your experience, how much time do you spend in the JS layer?

mxuribe 5y ago

Same here...i don't know about others, but over the years, the reason i have tried avoiding javascript is that the browsers/targets differ enough that its annoying...whereas it *feels* like coding in python (or other languages) seems to achieve more of the "write once, run everywhere" consistency concept...whereas javascript forces me to know about, and code for all those tiny, little browser differences. Ugh! Or, maybe i'm the only one who thinks this? Maybe it is my brain definitively telling me that i should just stick to the backend? (I'll admit that i code alot less nowadays.)

Kaze404 5y ago
I can't remember the last time I had to deal with browser inconsistencies wrt JavaScript. That's only ever a recurring problem with CSS in my experience, and even then it would be a stretch to call it a consistent problem in my experience.
- mxuribe 5y ago
  That's encouraging to hear wrt JavaScript!
chmod775 5y ago
If you're not using features on the bleeding edge, you won't have to worry about browser differences nowadays. And even if you want to use those features, you could just use (even automatic!) polyfilling or a library that abstracts any differences away. No application I've got my hands in nowadays (and there are some with a total of more than 100k LOC) contains a single line like "if (isMicrosoftEdge) { ... }". If you're doing that, you're not writing idiomatic JavaScript. Of course you can do things that aren't portable, but writing open("/tmp/mytempfile.txt", "a") in python isn't portable either. Avoiding that is just knowing your job.

kiesel3rde 5y ago

I think one 20% of the total development time was spent on the javascript client. The client is not very complex. It pretty much makes DOM manipulation API's usable for the backend only

IshKebab 5y ago

I agree. Typescript is much nicer than Python and doesn't suffer from the problem you describe. I think you'd be mad not to use it at this point.

haolez 5y ago
TypeScript, if you use its strong points, has a much slower development pace than a language such as Python. To each their own.
- refactor_master 5y ago
  How so? After having used typescript, Mypy and static languages, I could never go back.
  - haolez 5y ago
    I've started with static languages and I prefer dynamic ones over static. Code is a liability and static typing can create incentives for adding more and more boilerplate that brings little value to the table. I'm preferring dynamic languages and lots of tracing and rollback capabilities in production in 2021.
    - brundolf 5y ago
      I've found this to be a common mindset among people who started out with Java/C#/C++/etc. Modern statically-typed languages are a totally different beast. Type inference is widespread and powerful, and you end up writing very little additional boilerplate. On top of that, guarantees like the prevention of null values greatly increase the value you get from having static types. If you haven't tried one in a few years, I recommend revisiting them. TypeScript is a great place to start. PS: It's totally possible, but also totally unnecessary, to write TypeScript like you would Java or C# (lots of classes, nullable-everything, explicit types for everything). To get the most out of it you honestly have to do the exact opposite of that (turn on strict null checks, use plain types, leverage type inference as much as possible).