Starting a TypeScript Project in 2021 • Hacker News Board

Re: Starting a TypeScript Project in 2021

#131

Post by Groxx » Wed, Apr 21, 2021, 9:34 PM UTC

zackify wrote: post #121

joshghent wrote: post #64

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…

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

My interactions with Gradle have been with Android, and... oh boy do I hate it.

It's a noticeably-more-concise-and-flexible option than what came before it, and the net result has probably been good. But it's next to impossible to understand and troubleshoot when things don't go perfectly. And similarly difficult to figure out what you need to do to achieve X, because who knows, it could be in any of thousands of locations, called anything, and there's not enough structure to let you infer what's reasonable and what isn't.

Re: Starting a TypeScript Project in 2021

#132

Post by jokethrowaway » Wed, Apr 21, 2021, 9:39 PM UTC

zackify wrote: post #121

joshghent wrote: post #64

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…

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.

Re: Starting a TypeScript Project in 2021

#133

Post by vaughan » Wed, Apr 21, 2021, 9:40 PM UTC

diob wrote: post #90

xyzzy_plugh wrote: post #75

Earlier quoted context omitted.

I recently was trying to diagnose a bug with React state in someone else's project. Everything I found said "install the React extension". Okay but this thing boils down to just JavaScript right? I ultimately failed to find out how to inspect anything meaningful without the extension -- it's almost as if nobody knows how React works. The abstraction is bananas. Sure, JavaScript sucks but is this better? I swore off m…

Honest question though, what abstraction do you use in place of React? I don't disagree that it's pretty obtuse, despite loving working in it. I miss being able to look up the source of Backbone.js and gain a real understanding of why something was happening. Maybe I'll get to that point in React, but it seems much harder to grasp what the source is doing.

I miss Backbone too. You could just step through the code in the debugger and it was so compact.

With React you can’t really do that. It’s always following an error message saying: “look near this component” which is often deep in the hierarchy of some third party package’s component hierarchy that is transpiled into a single line with no source maps.

I think there is a huge benefit in making things easy to step-through in a debugger when something goes wrong.

Re: Starting a TypeScript Project in 2021

#134

Post by jokethrowaway » Wed, Apr 21, 2021, 9:41 PM UTC

axelf4 wrote: post #92

diob wrote: post #90

Earlier quoted context omitted.

Honest question though, what abstraction do you use in place of React? I don't disagree that it's pretty obtuse, despite loving working in it. I miss being able to look up the source of Backbone.js and gain a real understanding of why something was happening. Maybe I'll get to that point in React, but it seems much harder to grasp what the source is doing.

I consider part of the blame to lie with React. The React source code structure is pretty obtuse. Compare that to the Inferno.js source code which is easy to understand and navigate for anyone familiar with how a VDOM library should work.

this, I understood how react is supposed to be used by reading the preact codebase

Re: Starting a TypeScript Project in 2021

#135

Post by xyzzy_plugh » Wed, Apr 21, 2021, 9:43 PM UTC

hmsimha wrote: post #113

xyzzy_plugh wrote: post #100

Earlier quoted context omitted.

As someone who works on and fixes bugs in databases and filesystems, perhaps we don't look at things the same way.

When you have to debug something in postgres, are you going to communicate with it by using netcat and writing your own TCP messages by hand, or use psql? Both should work, but you wouldn't say postgres is obfuscating things intentionally so that you have to use psql (or some other postgres client). The fact of the matter is that complex tools are much more useful if they also come with tools to pave over (some of) t…

The Postgres protocol is documented extremely well such that it is actually trivial to write messages by hand, and yes, I have used netcat instead of psql.

I honestly couldn't find anything remotely similar in my search for to unearth React runtime internals. Maybe I'm missing something but literally every answer was "just use the extension."

Re: Starting a TypeScript Project in 2021

#136

Post by Sindisil » Wed, Apr 21, 2021, 9:51 PM UTC

idolaspecus wrote: post #111

f00zz wrote: post #106

Earlier quoted context omitted.

I can't even imagine how painful it must be for a curious kid to get started in programming these days. I feel so lucky to have started with a little 8-bit computer with a built-in BASIC interpreter. You turned it on and could start typing your program right away.

It’s about a million times easier today. Open a browser, open dev tools, open console tab, console.log(“hello world”). It’s even easier than that though. Open chrome, type “how to write computer programs” and go from there.

Not sure how that's easier than: Turn computer (which boots close to instantly), print "hello world".

It is certainly true that there are more informational resources available, but honestly, there was plenty of good info available at most decent libraries, and the manuals that came with computers were typically troves of information back in the 8-bit days.

Re: Starting a TypeScript Project in 2021

#137

Post by nawgz » Wed, Apr 21, 2021, 9:58 PM UTC

xyzzy_plugh wrote: post #75

joshghent wrote: post #64

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…

I recently was trying to diagnose a bug with React state in someone else's project. Everything I found said "install the React extension". Okay but this thing boils down to just JavaScript right? I ultimately failed to find out how to inspect anything meaningful without the extension -- it's almost as if nobody knows how React works. The abstraction is bananas. Sure, JavaScript sucks but is this better? I swore off m…

> Okay but this thing boils down to just JavaScript right

I am not really sure I understand this stance. My JavaScript ultimately just boils down to C++, no? C++ ultimately just boils down to machine code, right? Yet you clearly wouldn't try to tackle those things at that layer.

Without more statements on what this bug was and why there weren't error messages or why it was so hard to recreate you felt you could only look at it thru a debugger, I really completely fail to understand your point.

> Abstractions are supposed to remove complexity

React does remove a ton of complexity from writing frontend - good luck composing HTML & JS components with just jQuery - but in exchange it also introduces some, of course. So they make that new and different complexity easier to handle with their dev tools.

> I swore off abstractions ... [that] treat users like morons

I really have a tough time to read this charitably. What on earth are you on about?

Re: Starting a TypeScript Project in 2021

#138

Post by aphexairlines » Wed, Apr 21, 2021, 9:58 PM UTC

zackify wrote: post #121

joshghent wrote: post #64

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…

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) ?

Re: Starting a TypeScript Project in 2021

#139

Post by azangru » Wed, Apr 21, 2021, 9:59 PM UTC

xyzzy_plugh wrote: post #75

joshghent wrote: post #64

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…

I recently was trying to diagnose a bug with React state in someone else's project. Everything I found said "install the React extension". Okay but this thing boils down to just JavaScript right? I ultimately failed to find out how to inspect anything meaningful without the extension -- it's almost as if nobody knows how React works. The abstraction is bananas. Sure, JavaScript sucks but is this better? I swore off m…

> I recently was trying to diagnose a bug with React state in someone else's project. Everything I found said "install the React extension"

Really curious what you mean by that.

There are two possible Chrome (not React) extensions for dev tools that I can think of — one is the "official" extension by React core team that helps visualise components better and also helps understand why they may have rerendered. The other is a redux extension that's very helpful to inspect all the actions that were dispatched against the store and the changes they caused in the redux state. None sounds like what you are describing. Bugs with React state should be easy to diagnose just with a handful of console logs.

Re: Starting a TypeScript Project in 2021

#140

Post by eliseumds » Wed, Apr 21, 2021, 10:04 PM UTC

wereHamster wrote: post #127

sod wrote: post #36

Earlier quoted context omitted.

We should let linters written javascript die IMO. ESLint is soooo slow. My hope is that the ecosystem will slowly shift to deno, and we just gonna use `deno lint` ( https://deno.land/manual/tools/linter , based on swc, written in rust) for linting from then on. What tslint does in 6 seconds, `deno lint` does in 0.2 seconds.

Same for build tools, esbuild is multiple orders of magnitude faster than babel.

Yes, but it does much less. There are still many projects out there relying on Babel plugins (Loadable Components, Styled Components, Tailwind, Apollo, etc).

I love esbuild though, and use it a few of our packages, it flies