Conversation
Edited 6 months ago

I don’t know whose idea it was to decouple generating HTML/CSS with the rest of the backend code but that really seems like a bad idea to me because:

  • I have to keep the quirks of two different languages in mind (Jinja2 and Python)
  • whenever I call render() to render a Jinja template from inside of Python, my LSP is unable to verify that I’m giving it the data types that it expects, or even that I’ve typed the names of all of the variables correctly
  • that means that on the Python side I have to create stub functions whose only purpose is to add type annotations to the render() calls for my Jinja templates, to make sure I don’t give them the wrong kind of data by accident
  • and that means that every time I update any of my templates, I also have to manually update my Python render() stubs to make sure that it matches, or my templates will fail silently (Jinja’s response to getting weird data or no data at all is to just try to punt, which is understandable in production but I would really like it to fail hard if I’m in debug mode)

all of this could have been avoided if they’d just let me write the templates in Python as well

1
0
2

@kasdeya this is a big reason Node.js (JS for the backend) became popular. however, i have ✨opinions✨

1
0
1

@liese omg what opinions are those? if you don’t mind sharing. I definitely have some pretty strong feelings about JavaScript lol

1
0
0

@kasdeya mostly vibes -- i think javascript is a pretty bad language (at least at the time Node came out, certainly). despite how easy it is to get going with it (i think it's a good-to-great first language) and its excellent browser tooling (mostly forced by its status as THE web language), actually building anything at modest scale is vaguely masochistic

1
0
1

@kasdeya so of course making the backend be javascript too, and *losing* many of the advantages JS has on the frontend, seems like a net negative 🫠 even sharing code across the two is/was not trivial, and don't even get me started on the state of module import systems at the time

1
0
1

@kasdeya i kind of think that every advantage JS has is completely due to the effect of having a ridiculously outsized importance and development base, and not at all because of anything inherent to JS. so yeah, things have improved over time, but the fact that glosses over JS (typescript, also previously coffeescript, etc) are so popular is *really telling* to me

1
0
1

@kasdeya for backend i'm perfectly happy with (modern!!) Java, definitely Ruby, and would be very excited to pick up Elixir (w/ Phoenix). i also prefer to have a clear API separation between frontend and backend (so a frontend is "just" a separate project that makes use of the backend API), so using one language across both in order to blur the line just doesn't appeal to me

1
0
1

@liese omg my partner Rowan is always talking about how much she loves Elixir. she started by learning Erlang and loved that language and then moved to Elixir

and tbh I have really similar thoughts about JS: to me it feels like this cursed agglomeration of cludges in a trenchcoat, that now has been molded vaguely in the shape of a modern multi-paradigm scripting language like Python or Lua. although it’s definitely much better now than it was before, because I feel like the JS community has (as much as can be expected) figured out how to work around the terrible footguns baked into the language

to me JS is the language that you use because you have to. because you need something from the ecosystem, or it has to run in a browser, or etc. it’s definitely not a language that you go out of your way to use (except for Node people, apparently lol)

also I’m ngl I’ve had such a hard time wrapping my head around how OOP languages are meant to be used. not nearly as much as with functional languages but I still can’t wrap my head around, for example, not being able to have a function instead of a method. also in C# most people leave off the this. when referring to instance properties, which seems extremely cursed to me but might be fine; I wouldn’t know

1
0
1

@kasdeya yeah, leaving off `this` is fine because of method resolution rules, *but* i always write `this` explicitly anyway as a kindness to the reader

i struggled to learn good OOP style myself when i started; somewhere along the way i picked it up, but i couldn't really tell you what it is (and TBQH i don't think most people who claim to know the answers really do either, given how often i disagree with them)

i prefer functional by a mile 🙂😅

0
0
1