151–160 of 190 posts
Anyone here has some experience with ReScript (or ReasonML, for what it matters) to share with the rest of us?
I'm much more interested in ReScript[0] than TypeScript, but I guess that TypeScript is much more appealing to C# programmers and much more supported as a whole. Anyone here has some experience with ReScript (or ReasonML, for what it matters) to share with the rest of us? [0] https://rescript-lang.org/
Earlier quoted context omitted.
It’s interesting to see people feel this way about JS. Lately I’ve been trying to learn kotlin... and man... that stuff (gradle) adds a weird amount of boilerplate to everything. JS / TS on the other hand. It’s a package.json, or tsconfig. Not much else is required. Jump into deno and you don’t even need those. Feels like JS is one of the better languages in this regard
What's the weird amount of boilerplate in gradle compared to package.json + tsconfig (+ webpack.config.js or next.config.js, + jest.config.js, + babel.config.js, + workspaces) ?
I recommend adding `--transpile-only` to `ts-node` in npm scripts and any interactive workflows. If you have type checking in your editor or tsc --watch in a terminal you don't need to block unit tests or iterative development while ts-node runs type checks.
I disagree, I don't want my project to successfully build at all if I have type errors.
Ever since watching Jonathan blows talk "Preventing the collapse of civilisation", I've been mulling over things like this. It feels like we have this defacto set of commands you have to run to start a new Node/Typescript project, without much understand of what it does. Then you get complier or lint errors and then spend ages googling around for the answer that tells you to change a specific flag. This isn't a compl…
What I've pinned it to is a cultural problem in the JavaScript realm: everybody wants to impress everybody else about how smart they are, and in the process of doing so, creates convoluted mazes. As a side-effect, motivation dips and then quality control falls in concert, leading to an "at least it works" mentality.
That's my curmudgeon speculation/observation, at least.
I'm much more interested in ReScript[0] than TypeScript, but I guess that TypeScript is much more appealing to C# programmers and much more supported as a whole. Anyone here has some experience with ReScript (or ReasonML, for what it matters) to share with the rest of us? [0] https://rescript-lang.org/
ReScript seems to have come a long way since I last looked at it (it was just called ReasonML at the time I think), so it'd be worth looking into.
Earlier quoted context omitted.
It’s interesting to see people feel this way about JS. Lately I’ve been trying to learn kotlin... and man... that stuff (gradle) adds a weird amount of boilerplate to everything. JS / TS on the other hand. It’s a package.json, or tsconfig. Not much else is required. Jump into deno and you don’t even need those. Feels like JS is one of the better languages in this regard
while I agree on kotlin (or java, or swift, or objective c), I think early releases of node.js or frontend development pre big frameworks were much better in that regard. We're still not as bad as mobile development, but things are getting worse.
Earlier quoted context omitted.
Well, parent can find an error in a React app with a standard JS debugger, you can find an error in databases and filesystems with gdb or some such, but not vice versa. Can be as simple as that: familiarity.
I don't think that's quite it, at least not entirely. They were complaining about how everything they found on how to diagnose and inspect the problem started with downloading a third party tool. I read this as a complaint that React doesn't provide information on what's going on that you can see and inspect (whether true or not). The equivalent for Postgres would be if they didn't document their protocol and instead…
Also, the react dev tools aren't really a debugger. There's no way to step through code or similar. It just provides an insight into React's internal state (the component tree, and any state contained within it). The equivalent would be Postgres providing a tool to inspect the contents of its caches or indexes, and the OP complaining that they can't read them when using GDB.
[0]: https://reactjs.org/blog/2019/08/15/new-react-devtools.html
At what point does the complexity outweigh the benefits? Just because someone wants to control a UI element to the nth pixel doesn't mean we should let them do that. At this point I'm thinking it might be less bandwidth, complexity, and easier to maintain to just present a web page as a giant imagemap. SVG, so it scales. With screen-ratio-based media queries rather than guessing DPI based on inaccurate factors like t…
Good luck building anything interactive this way.
In 2021, I think it's safe to start a TypeScript project with Deno.