Nerd02

Axios for requests - easier than working with the Fetch API in some cases

May I ask what cases? I used to use Axios on Node, before they implemented the fetch API over there but I haven’t touched it since. And defintiely never used it on the client. Could you make an example of some case where it’d be easier to work with Axios than with fetch?

your fascist fucking grandpa is literally Mussolini

That’s not Meloni, I think you might be confusing her with Alessandra Mussolini. Even then, I don’t think it’s fair to hold people accountable for the actions of their ancestors, even when said ancestors are dictators such as “literally Mussolini”.

and it’s one of his old colonies

If anything what made the country so destabilized, ultimately leading to Gaddafi’s rise, was the “liberation” (read as neocolonialism) brought by the British. A similar fate happened to all the other former Italian colonies such as Ethiopia, Somalia and Eritrea.

I’m all for the right of self determination of people and decolonization was a traumatic process for many African countries (think of French Algeria for one), but it’s probably not a coincidence that all of those territories are now failed or war torn states. A smoother and more democratic process after WW2 might probably have helped the regions, but it’s not fair to blame Italy for it’s lack.

Interesting idea. I’m currently working on a Lemmy-ui fork for my instance and including a feature of this kind in the frontend would be kinda nice.

I’ll bookmark this and come back if I ever get to it.

Then I guess this is what you get for talking about something without knowing what it is lol.

As another user pointed out, TypeScript is a different language (.ts extension) that extends JavaScript, meaning JS code is valid TS code, but TS adds various language features for type checking. Your editor is then able to interpret your code according to these type structures and warn you if you are making any stupid type errors like this one:

The problem many people have with TS (such as the “big projects” mentioned by Fireship) is that sometimes you end up having code that works but still have to do some weird type gymnastics to please the TS compiler and have it remove any errors and warnings.

That being said, frameworks that “create really weird undecipherable minified JS” do have their place, as they allow you to seamlessy do things that would be either very inelegant and verbose or significantly more complex in vanilla JS, but I won’t bore you with an excessively long wall of text.

PS: I love your Czech flag website. Had me jump on my chair when the music started blasting through my headphones.

How is that related to TS? Aside from the fact that your comment might have just started a civil war (no, vanilla JS is not “good enough”, they created libraries for a reason) this isn’t about using libraries / frameworks. It’s about needing some system to handle type annotations to avoid falling in the bottomless pit of:

Uncaught TypeError: Cannot read property of undefined

There’s no real alternatives to JS “for websites” (meaning on the frontend, the part of your code that gets executed on your client’s browser). That’s what JS was invented for and what it does best.

I say “no real alternative” because technically we also have WebAssembly, which is a tool that allows you to run code written with any language on the web, but if you indeed are a beginner approaching to web development you should just forget about this for now and stick to JS as you learn.

Of course this doesn’t mean that you can’t use Python on your backend, your server.

I think there’s a positive coming from this competition, though. Apparently this infighting has re-lit the want for type annotations to be embedded in vanilla JS (ECMAScript proposal). I feel like this would be the ideal scenario: things working right out of the box without needing a compile step or additional tooling.

You can get as close as it gets to this experience by using alternative runtimes such as Deno or Bun, which have native TS support (meaning you can just execute a .ts file without having to transpile it), but of course as soon as you have to write code for a browser you are back in the middle ages.

The backend is quite alright. The Rust backend makes it indimidating to approach, but I know it has many advantages.

The frontend could use LOTS of changes. I don’t like Inferno, it’s messy and confusing to work with. Instead, I would have opted for a Svelte+Tailwind stack for the UI.

Nah I didn’t say that it’s bad lol. Didn’t mean it that way, at least. The way I understand the “fuck, marry, kill” game is that:

• Fuck: down to play with it every once in a while
• Marry: always down to use it
• Kill: never want to use it

but if someone else wants to play with Rust who am I to stop them

There’s plenty of applications that aren’t critical enough to require precise memory management and where a GC is a worthy tradeoff for the simplicity that Go brings to the table, but sure, if you are interested in going super low level that’s what you are left to work with.

And it’s probably fine. If I had to pick between C++ and Rust I would choose the latter any day of the week but thankfully not every developer has to go that low.

I was under the impression that the Go compiler was written in C/C++, though don’t quote me on this one. My browser however is Firefox, so touché on that one.

Hot take:
Fuck TS, marry Go, kill Rust.