Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Starting a TypeScript Project in 2021

metachris.com

Post reply on HN
Print view View original

91–100 of 190 posts

Re: Starting a TypeScript Project in 2021

#91

Post by TechBro8615 »

tompazourek wrote: post #61
TechBro8615 wrote: post #58

Earlier quoted context omitted.

> probably be a single bash or PowerShell script The fact that it could be either bash or PowerShell is a primary reason why this tooling is there. Bash scripts work great (I use them) if everyone coding on the project shares an operating system. Not so much once you cross that boundary. To give a sense of the lengths the JS community goes to address these compatibility issues, consider that Yarn 2 actually implement…

FYI PowerShell is pretty cross-platform these days. But I see having it all written in JS is still simpler.

I don't know about simpler :)

My preference is to eliminate the OS discrepancy by making Docker images the building block of the stack in dev environments, CI pipelines, and production deployments. This means you pay a constant and predictable amount of operational complexity, but eliminate the entire class of constraints caused by cross-platform variability. Seems like a good deal, trading a variable cost for a constant one.

Then you can use Bash! Or fish, or some hipster shell you found on lobste.rs. Just install it in the Docker image.

Re: Starting a TypeScript Project in 2021

#92

Post by axelf4 »

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 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.

Re: Starting a TypeScript Project in 2021

#93

Post by xyzzy_plugh »

nicoburns wrote: post #78
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…

When you're trying to debug a JavaScript error do you use Chrome's built in JavaScript debugger, or do run Chrome in GDB? Or perhaps you get out your oscilloscope and try attaching it to your CPU? Debugging at multiple levels of abstraction is nothing new. The fact that there are debugging tools at the React level does reduce complexity. It means you don't need to understand the details of how React is implemented. Y…

Is React language or a library? Does it have its own virtual machine? If I'm debugging something that compiles down to assembly, sure, I can use GDB. Why shouldn't I be able to use the JavaScript debugger? Why does React go though so much effort to obfuscate its internals to such an extreme?

There are a million other JavaScript libraries that do not have this problem, for what it's worth.

> It means you don't need to understand the details of how React is implemented.

Isn't this the topic of discussion? Why shouldn't it be as simple as "React stores state in this variable" and I can just poke at it like any other variable?

Abstractions are great, but they all leak eventually. Being able to see through the abstraction is immensely valuable, regardless of where you are in the stack.

Don't confuse simplicity for its pernicious cousin convenience, which usually does not actually reduce complexity, but heralds it.

Re: Starting a TypeScript Project in 2021

#94

Post by xyzzy_plugh »

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 just write JavaScript? The concepts of Basecamp's Hotwire[0] are particularly simple and elegant enough for the 1% of stuff that isn't just a static page or can't be solved in a single JS function.

I've never been like "boy I really need a virtual DOM" so I guess I've never really seen the appeal of React. It just seems like a bundle of complexity, obfuscation and anti-patterns.

0: https://hotwire.dev

Re: Starting a TypeScript Project in 2021

#95

Post by droobles »

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 found it to be a really cool experience setting up Nodemon with TS myself with a few Medium guides – because of that I know my app's build system inside and out!

Re: Starting a TypeScript Project in 2021

#96

Post by nicoburns »

xyzzy_plugh wrote: post #93
nicoburns wrote: post #78

Earlier quoted context omitted.

When you're trying to debug a JavaScript error do you use Chrome's built in JavaScript debugger, or do run Chrome in GDB? Or perhaps you get out your oscilloscope and try attaching it to your CPU? Debugging at multiple levels of abstraction is nothing new. The fact that there are debugging tools at the React level does reduce complexity. It means you don't need to understand the details of how React is implemented. Y…

Is React language or a library? Does it have its own virtual machine? If I'm debugging something that compiles down to assembly, sure, I can use GDB. Why shouldn't I be able to use the JavaScript debugger? Why does React go though so much effort to obfuscate its internals to such an extreme? There are a million other JavaScript libraries that do not have this problem, for what it's worth. > It means you don't need to…

> Is React language or a library? Does it have its own virtual machine?

It's a library, but it does provide a runtime. As such it IMO makes sense that it would have it's own debugging tools. This is pretty common for complex frameworks. Other frontend frameworks like Angular and Vue do it. As do backend frameworks like Rails and Laravel. Or as another example you could look at Unity (the game framework).

You can still use the JavaScript debugger, and I do all the time with React code. But for React specific concepts the React specific tools provide a better experience.

> Why does React go though so much effort to obfuscate its internals to such an extreme? There are a million other JavaScript libraries that do not have this problem, for what it's worth.

It doesn't do it intentionally. It's internals are somewhat complex for performance reasons. Which other JavaScript libraries allow you to inspect their current state with the JavaScript debugger? That's what the React dev tools give you: state inspection. IME, lot's libraries make inspecting that quite difficult (unless they're using global variables).

> Why shouldn't it be as simple as "React stores state in this variable" and I can just poke at it like any other variable?

The problem is that you can't typically poke variables using the JavaScript debugger. To do so you need to get a reference to the variable. And you can only reasonably do that for globals.

> Abstractions are great, but they all leak eventually. Being able to see through the abstraction is immensely valuable, regardless of where you are in the stack.

I guess I've just never hit into the limitations of the React abstraction (and I've done pretty complex things). Nor have I ever hit a bug in the implementation. To me it's like my database or my filesystem: sure it's great to be able to peak under the hood if I really need to, but 99.9% of the time I'm super glad that I don't. I've had much worse experiences with Angular (1 and 2) where I frequently felt like the abstraction was leaking a lot.

Re: Starting a TypeScript Project in 2021

#97

Post by lenkite »

wwweston wrote: post #88
lenkite wrote: post #84

As someone who has returned to webdev after a few years, I find deno to be far easier to setup and get started than all the mega-complex node stuff.

> cargo install deno ... Compiling swc_ecma_transforms v0.45.3 error[E0004]: non-exhaustive patterns: `MaxFilesWatch` not covered --> /Users/weston/.cargo/registry/src/github.com-1ecc6299db9ec823/deno_runtime-0.11.0/errors.rs:75:9 | 75 | match error.kind { | ^^^^^^^^^^ pattern `MaxFilesWatch` not covered

Admittedly as someone who doesn't code Rust, I have never tried to use cargo to install deno. On macOS I use brew.

brew install deno # works with no issues and much faster

Though, at the bottom of https://deno.land/#installation, one sees the incantation:

cargo install deno --locked

I removed brew's deno, installed rust (via brew) and then tried this. No compile errors. And swc_ecma_transforms compiled successfully.

   ...

   Compiling swc_ecma_transforms_proposal v0.13.1

   Compiling swc_ecma_transforms_optimization v0.15.3

   Compiling swc_ecma_transforms_typescript v0.14.1

   Compiling swc_ecma_transforms_react v0.14.1

   Compiling swc_ecma_transforms v0.45.1

   Compiling gfx-auxil v0.8.0

   ...

   Installing /Users/i034796/.cargo/bin/deno

   Installing /Users/i034796/.cargo/bin/denort

   Installed package `deno v1.9.0` (executables `deno`, `denort`)

Re: Starting a TypeScript Project in 2021

#98

Post by knubie »

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’m reminded of Rich Hickey’s talk Simple made easy. The gist being that easy is not always simple (yarn install hairball) and simple may not seem easy at first (unfamiliar).

Back then the comparison was made with rails, but it still holds true with modern web development now more than ever.

Re: Starting a TypeScript Project in 2021

#99

Post by amenod »

xyzzy_plugh wrote: post #94
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 just write JavaScript? The concepts of Basecamp's Hotwire[0] are particularly simple and elegant enough for the 1% of stuff that isn't just a static page or can't be solved in a single JS function. I've never been like "boy I really need a virtual DOM" so I guess I've never really seen the appeal of React. It just seems like a bundle of complexity, obfuscation and anti-patterns. 0: https://hotwire.dev

While you don't _need_ React (or a similar powerful library / framework), it takes one's productivity to a whole different level.

I have a feeling that you have already made up your mind not to like it, but if you ever give it a fair try, you might find it useful for some projects. It is very complex under the hood, of course, so if you want to have total control you might need to dig into the internals. But to a casual user it gives a very nice abstraction, very powerful, easy to use (granted - and abuse) and performant. The thing that sold it for me is the declarative programming. You have state, state translates to rendering... and that's pretty much it. Compared to thinking about transitions in native JS (or jQuery or whatever) it is like night and day in any non-trivial project.

Re: Starting a TypeScript Project in 2021

#100

Post by xyzzy_plugh »

nicoburns wrote: post #96
xyzzy_plugh wrote: post #93

Earlier quoted context omitted.

Is React language or a library? Does it have its own virtual machine? If I'm debugging something that compiles down to assembly, sure, I can use GDB. Why shouldn't I be able to use the JavaScript debugger? Why does React go though so much effort to obfuscate its internals to such an extreme? There are a million other JavaScript libraries that do not have this problem, for what it's worth. > It means you don't need to…

> Is React language or a library? Does it have its own virtual machine? It's a library, but it does provide a runtime. As such it IMO makes sense that it would have it's own debugging tools. This is pretty common for complex frameworks. Other frontend frameworks like Angular and Vue do it. As do backend frameworks like Rails and Laravel. Or as another example you could look at Unity (the game framework). You can stil…

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