[its-summertime]

Javascript is not a language that is good for making basic comprehensive abstractions in.

Typescript is not a language that is good for making basic comprehensive abstractions in.

JSX is not a language that is good for making basic comprehensive abstractions in.

[jfengel]

I concur about Javascript, but I don't think it's true for Typescript. Typescript is a remarkably powerful typing language.

It's still got some baggage left over from Javascript, to be sure. But the typing is genuinely very good, and more than sufficient for "basic comprehensive abstractions".

JSX is just Javascript with syntactic sugar for HTML. It's not really intended as a general-purpose language. TSX is a fine language, but I wouldn't use it for "basic comprehensive abstractions".

[Imustaskforhelp]

Depends...

Like if you want to make a basic dashboard, things like alpine/htmx should make more sense to you and you should definitely go for it

But I have found that if you are writing ever so slightly complex code, you might be then forced to write js code (not sure about blazor but even that suffers a little in benchmarks but the fact that somebody can fully stop to never touch js sounds a bit intriguing even though it maybe slow but sure)

So when you are forced to use js to write complex software, frameworks especially frameworks like svelte / maybe solid could definitely help you out

Honestly, sveltekit is just html css js and some opinionated stuff and I kinda feel like that this might be the sane thing but maybe that's because I was there when svelte 3 was launched and I was 15 so svelte was something sooo interesting to me (still is! but golang is also love, man I know that svelte and go could be integrated and maybe I would), I never really went around learning pure js dom manipulation / ts / jsx if I am being honest so I am not that much of an expert

[nawgz]

This is quite a large set of things to hand wave away with no additional justification. Makes it sound more like personal bias than meaningful insight

[its-summertime]

You are right, my reasoning is as follows (though still 100% personal bias).

For writing a web server library, like oak or flask or etc etc:

First, resources own the methods, methods don't own the resources, so the path comes first, easy enough, its just a string with potentially placeholders whose values need to be shunted down the line

Next is the method, for some reason a lot of libraries like to hardcode these? Immediately jumping away from comprehensive, unless you have a language that makes identifier-like things possible, e.g. symbols in ruby, or `__getattr__` in python, or proxies in javascript, of the 3, proxies are probably the most cumbersome in implementation.

then the request handling, that is fine for all languages

Templating is more of a bother: Either you use JSX, which in most cases is not XML, but instead DOM, subtle but a pain, additionally requires a compilation step before you can run the code, and also requires a DOM or DOM-lite library. Or you do chained calls with an ending call, e.g. https://sonnet.js.org/, or you do something like lit-html which is quite practical. You can't do something like title("hi") vs title({attr:123}, "hi"), as everything is an object and {} are objects, so you need to have fixed function signatures unless you want to have a lot of bother in implementing things. This is all less of a problem in other languages (e.g. Python, Ruby, Raku)

In short, Javascript does not flex when you push on it, that is great for a lot of tasks, but not so much for building frameworks where instead of having systematic ways of extending the language, either tricks are used which break other things down the line ( https://news.ycombinator.com/item?id=45472119 ), or you have opinionated narrow frameworks, which results in more churn as instead of frameworks, its more, frame-specific-use-cases.

[reissbaker]

Not sure I follow the first part of what you're saying.

For the part where you're describing what's possible or not in TypeScript/JS, though, you're incorrect:

You can't do something like title("hi") vs title({attr:123}, "hi")

Yes, you can. In JS it's trivial; in TypeScript, you can even do it while preserving type safety. Here's the function in TypeScript:

    // First define which signatures are allowed
    function title(content: string): string;
    function title(attrs: Record<string, any>, content: string): string;

    // Then, implement the function, handling the two possible cases:
    function(contentOrAttrs: string | Record<string, any>, maybeContent?: string) {
      const content = typeof contentOrAttrs === "string" ? contentOrAttrs : maybeContent!;
      const attrs = typeof contentOrAttrs === "string" ? {} : contentOrAttrs;

      // now use content and attrs as you please
    }

This will be typechecked by the compiler so that if you call title("hi"), it'll know there are no more arguments, and if you call title({ attr: 123 }, "hi"), it'll validate that the first argument is a Record<string, any> and the second argument is a string.

[its-summertime]

that part was clarified later, "so you need to have fixed function signatures unless you want to have a lot of bother in implementing things"

I should not have used "can't" at that point, correct

To be more clear, you "can't" have a difference between an arbitrary object and a record, unless you know the type of the object and a way to disambiguate that from a record.

Of course, you "can" have a difference, a record "is" `typeof record === 'object' && Object.getPrototypeOf(record) === Object.getPrototypeOf({})` (At least as long as no one uses plain objects as non-recordy things), but, this isn't something I've ever had to care about in any other language. In some you have multiple dispatch built into the language, in some you can just pass named arguments arbitrarily. Javascript and Typescript are very inflexible in this aspect.

[fancyswimtime]

it feels like a fad to hate on js and js frameworks; esp from people who parrot what others are saying without any actual insight

[masfuerte]

A fad? People have been pointing out flaws in js for about thirty years. That's long enough to have become a tradition.