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

121–130 of 190 posts

Re: Starting a TypeScript Project in 2021

#121

Post by zackify »

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

Re: Starting a TypeScript Project in 2021

#122

Post by [deleted] »

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.

[deleted]

Re: Starting a TypeScript Project in 2021

#123

Post by xyzzy_plugh »

qudat wrote: post #103
xyzzy_plugh wrote: post #94

Earlier quoted context omitted.

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

> I just write JavaScript? This is the tell. If you are able to satisfy your business requirements with "just JavaScript" then you are in a completely different world than the people building production-grade web apps and there's absolutely nothing wrong with that. If you can be productive with "just JavaScript" then that's awesome! However, I'm sure you understand there's a massive difference between simple pages th…

I'm curious -- what is not possible with just JavaScript? Why do you assume "a full-blown app inside a web browser" isn't possible without React or something like it?

Is client-side rendering strictly necessary? Do your websites actually run offline?

I've built websites with React, used React Native -- none of it is necessary, nor the end-all-be-all. There's nothing truly novel going on. You can accomplish the exact same experience with server-side rendering and a tiny smattering of vanilla JS (you can use modern JS and polyfills and webpack/esbuild without React, you know).

For 99.9% of the web, I'd argue you don't need it. I have yet to encounter the 0.1% personally.

If you don't believe me, know that I'm not alone. Take a look at https://levels.io/deviance/ -- PHP and jQuery. What would React provide that isn't possible with his stack?

There is a disturbing amount of kool-aid being consumed around React/Vue/etc. Sure, you can slap together a website in record time with massive boilerplate/templates -- but so can I.

Re: Starting a TypeScript Project in 2021

#124

Post by xyzzy_plugh »

amenod wrote: post #99
xyzzy_plugh wrote: post #94

Earlier quoted context omitted.

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 cas…

I've tried it. And yes, I want full control. The abstractions mostly work, but when they don't -- there you are again, thinking about transitions in native JS again. What was the point?

Re: Starting a TypeScript Project in 2021

#125

Post by InvertedRhodium »

gmfawcett wrote: post #105
qudat wrote: post #103

Earlier quoted context omitted.

> I just write JavaScript? This is the tell. If you are able to satisfy your business requirements with "just JavaScript" then you are in a completely different world than the people building production-grade web apps and there's absolutely nothing wrong with that. If you can be productive with "just JavaScript" then that's awesome! However, I'm sure you understand there's a massive difference between simple pages th…

> ...than the people building production-grade web apps... Please don't co-opt the word "production" to mean what you're implying here. Production doesn't mean single-page, reactive, etc. applications, it just means "in production."

I agree. My workplace has at least a dozen applications deployed to production with "just JS" and they're just at production ready as a react stack would be.

Source: Running "just JS" in production for more than 6 years.

Re: Starting a TypeScript Project in 2021

#126

Post by wwweston »

lenkite wrote: post #97
wwweston wrote: post #88

Earlier quoted context omitted.

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

brew is nice. I have a rule for myself, though, that if I'm picking up something I'm likely to deploy on an environment that's not my mac, I don't use brew to install it. That can make some things harder up front, but I have my eyes open from the start and get fewer surprises between beta and deployment.

On the other hand, having added `--locked` to the cargo invocation, it works for me now too, so apparently (a) I should look into what that means and (b) I should consider using brew for hints even in situations where I don't intend to rely on it. Thanks!

(On the other other hand, even finding the way through this issue reinforces the point about a certain complexity/opacity to tooling that's supposed to make things easier.)

Re: Starting a TypeScript Project in 2021

#127

Post by wereHamster »

sod wrote: post #36
jherdman wrote: post #34

TSLint is deprecated in favour of ESLint. See https://palantir.github.io/tslint/ .

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.

Re: Starting a TypeScript Project in 2021

#128

Post by wereHamster »

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

  % nix-shell -p deno
    these paths will be fetched (18.39 MiB download, 57.83 MiB unpacked):
      /nix/store/vr6lw60nav6kd0qjkb61lbb78mpx4pry-deno-1.8.2
    copying path '/nix/store/vr6lw60nav6kd0qjkb61lbb78mpx4pry-deno-1.8.2' from 'https://cache.nixos.org'...
  [nix-shell:~]$ deno --version
  deno 1.8.2 (release, x86_64-apple-darwin)
  v8 9.0.257.3
  typescript 4.2.2

Re: Starting a TypeScript Project in 2021

#129

Post by spinningarrow »

andrew_ wrote: post #15

Ava ( https://github.com/avajs/ava ) gets too little love from the blogging machinery. It's a breeze to use with TS, faster than Jest (YMMV of course), and I love the snapshot output over any other snapshot producing unit test tool. Use with NYC for coverage is a breeze.

It's been a while (4 years) since I used Ava. Back then, it was impossibly slow - something about running tests in parallel even though they don't have any blocking operations being a significant overhead. Any idea if that's changed?

Re: Starting a TypeScript Project in 2021

#130

Post by jorblumesea »

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…

Debugging a popular library is not at all equivalent to those layers of abstraction. This argument is so flawed it almost feels malicious.
Post reply on HN