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

141–150 of 190 posts

Re: Starting a TypeScript Project in 2021

#141

Post by __s »

xyzzy_plugh wrote: post #123
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…

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…

Here's your 0.1%: a card game, https://etg.dek.im before React I was using PIXI.js, over the years it's transitioned from being fully rendered in canvas to not using canvas at all (& now uses webpack, but years ago I had my own bundler mkcjs https://github.com/serprex/mkcjs which was pretty vanilla js, using require let me share code for awhile between server/client until server was rewritten in Rust)

react-motion made animating card transitions very straight forward

During a game you can click on history items to look at previous game states, this is very straight forward with React's model

Sure you could get this all by rolling your own state dom renderer, but that's like saying you can do everything Lisp does in C. Greenspun's tenth rule rephrased as "Any sufficiently complicated JavaScript UI contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of React."

Re: Starting a TypeScript Project in 2021

#142

Post by fiddlerwoaroof »

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…

The difference between a language and a library is arbitrary: it’s all an artifact of programming ecosystems that place a hard division between the “language implementors” and the “programmers”: every library of sufficient complexity is an embedded language with annoying syntax.

Re: Starting a TypeScript Project in 2021

#143

Post by fiddlerwoaroof »

xyzzy_plugh wrote: post #135
hmsimha wrote: post #113

Earlier quoted context omitted.

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

If you really wanted to, you could write your own renderer. there’s already several: react-dom, react-native, react-test-renderer. Also, I believe there’s at least one conference talk where a renderer was live coded

Re: Starting a TypeScript Project in 2021

#144

Post by fiddlerwoaroof »

Sindisil wrote: post #136
idolaspecus wrote: post #111

Earlier quoted context omitted.

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.

Yeah, people forget (or just never experienced) how easy it was to learn something like Delphi pre-Internet: the software box had good manuals and you just hit F1 for context-sensitive help that was actually useful.

Re: Starting a TypeScript Project in 2021

#145

Post by [deleted] »

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…

[deleted]

Re: Starting a TypeScript Project in 2021

#146

Post by TechBro8615 »

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…

It's a bit unfair to expect a framework not to provide new abstractions. That's required almost by definition.

In React's defense, it's far from "impenetrable." In fact, its API exposes less than a dozen attachment points (considering render + lifecycle methods or their hook equivalents). It's a small and stable interface on top of a simple tree structure and an intuitive reconciliation algorithm. Most of the time you don't even need to reason about its logic, but when you do, it's understandable and debuggable.

I'm also skeptical that we should consider framework-specific dev tools as evidence of an impenetrable abstraction. As long as the tools strictly enhance the debugging experience, they are a feature, not a smell. They are evidence of a problem when they only exist because it's impossible to debug the API without them.

For example, Apollo Dev Tools "strictly enhances" the debugging experience. It provides a nice UI for GraphQL specific debugging sessions, but it doesn't break the "network" tab of Dev Tools. If you want to use apollo-client without its dev tools, you're no worse off than you were before adopting apollo-client. But you do gain something if you choose to use them.

Re: Starting a TypeScript Project in 2021

#147

Post by nicoburns »

xyzzy_plugh wrote: post #135
hmsimha wrote: post #113

Earlier quoted context omitted.

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

If you want to debug a performance issue in postgres, then the answer will be similar: "just use EXPLAIN ANALYZE". You could get out a C debugger and step through the source code, and there are cases where that is appropriate (e.g if you're working on Postgres itself, or you're trying to diagnose a bug in postgres), but if all you want to do is debug your query then you should use the postgres-specific debugging tool (EXPLAIN ANALYZE).

Same for React. If you are working on React itself, or you need diagnose an actual bug in the runtime then you'll want to use the JavaScript debugger and step through. If all you need to do is work out why your component isn't updating then you can use the React-specific tool (the extension) to make your life much easier.

Re: Starting a TypeScript Project in 2021

#148

Post by TechBro8615 »

tompazourek wrote: post #101
TechBro8615 wrote: post #91

Earlier quoted context omitted.

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

I've read about NixOS here on HN which aims to do something similar. Does your approach with using docker heavily have some disadvantages you experienced? Just curious, it sounds interesting...

Yes, lots. You need to pay operational complexity early and often. A lot of tools don't work out of the box due to volume sharing, permission issues, etc. You need to figure out dev vs. prod images, how to do incremental builds locally (e.g. you switch branches) and in CI (new push). Lots of issues like this.

Overall it's worth it in the end if you're making a long term investment, IMO. It forces you to build modular infrastructure from the beginning, so there are few surprises when pushing to prod.

Re: Starting a TypeScript Project in 2021

#149

Post by fiddlerwoaroof »

NikhilVerma wrote: post #70

Very much appreciate boilerplate tools, they often come with sane defaults and avoid configuration hell when you just want to get started. I just wish there was some easy way to version them, so you can migrate from an older boilerplate to a new one. I quite like how React Native does it. They have git diffs of a created project for each released version. So if you want to migrate from version A to B you just see the…

I’d recommend just trying to set up a webpack 5 build from scratch: I’ve done it twice recently, and it’s been a pleasant surprise how much easier it was than it was four years ago.

Also, parcel Just Works for a lot of problems.

Re: Starting a TypeScript Project in 2021

#150

Post by kbenson »

coldtea wrote: post #107
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.

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 referred you to a special debugger they provided, and you had to rely on that instead, making use of gdb or the equivalent much more complicated.

Post reply on HN