You are right, my reasoning is as follows (though still 100% personal bias). For writing a web ser...

its-summertime • last Wednesday at 10:17 PM • 1 reply • view on HN

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.

Replies

reissbaker • yesterday at 2:16 AM

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.

➕ show 1 reply

alt Hacker News

Replies