9 ms·

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 s

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 complete thought but I hope someone knows what I'm getting at.

vagrantJin 5y ago
In other words, the tooling and setup have become more complicated than the pieces of code we are writing? I feel like that sometimes. Not all bad though. I've learned that being spartan with your approach not only frees the mind of clutter but your stack wont be delicate shitshow of obscure tools 3-4 years down the line.
xyzzy_plugh 5y ago
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 massive impenetrable abstractions like React eons ago and I'm saner for it. Abstractions are supposed to remove complexity, not treat users like morons.
- nicoburns 5y ago
  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. You can just think in terms of React concepts (which are quite straightforward and have excellent documentation).
  - agentwiggles 5y ago
    I got a good chuckle at the silliness of the mental image of hooking up a scope to diagnose a JS error. Thanks for the laugh. (tl;dr: lol)
  - xyzzy_plugh 5y ago
    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.
    - nicoburns 5y ago
      > 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.
- nsonha 5y ago
  not a good example, knowing how things work is not a reason not to use debugger or similar tools
- diob 5y ago
  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.
  - axelf4 5y ago
    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.
    - jokethrowaway 5y ago
      this, I understood how react is supposed to be used by reading the preact codebase
  - xyzzy_plugh 5y ago
    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 https://hotwire.dev
    - amenod 5y ago
      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.
- nawgz 5y ago
  > 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?
- azangru 5y ago
  > 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.
- deleted 5y ago
  [deleted]
- lr4444lr 5y ago
  You're not wrong, but I think you're missing the value of React: the simplicity is not having to worry about the correctness or efficiency of your render engine. You get to go back to a more declarative way of writing code that comes with a modular composable style. There's a cost to pay for this: surrendering control (and easy insight) of the DOM you once knew to React's core logic. You do get a variety of callbacks to hook into, and I always encourage people to learn more about their frameworks, but you're not buying a set of convenience methods like you were with jQuery: this is effectively an interpreter between your data and its rendering.
- schwartzworld 5y ago
  The react extension is pretty powerful. You can work without it, but it enables debugging techniques that would be much harder without it.
- flippinburgers 5y ago
  I have a deep love/hate relationship with react so I largely agree with you. The last time I used the extension, it was obnoxious to use to try to find "state" within the page. Using redux makes things easier to debug from this perspective but you do need yet another extension for that too... I really think this is a sign of young engineers who have no experience with older approaches just memorizing "how things are done". They have no perspective on the tooling or experience.
- apatheticonion 5y ago
  Try to implement a website without React or Angular/Vue. When you hit your first list of elements and need to rerender the contents of just one of the elements, you will begin writing your own React. If you try to implement some kind of "two way databinding", you will first create React, then create Angular. However, unreadable and disorganised code can be written at any abstraction level. I have found React projects to be particularly hideous due to the fixation engineers have for tools like Redux. Angular tends to be a bit better because it's got some decent software design principles built in - but you know front end engineers. Any project with ngrx is a write off from an readability perspective. Isomorphic applications are also a meme that kill readability. I write most of my personal projects using Preact and some kind of reactivity helper (RIP `Object.observe`, I grieve for you).
meheleventyone 5y ago
The nice thing is you don’t need all this stuff it’s just one persons opinion of what you need. It’s mostly that you get a bunch of extra functionality with it. Additive rather than required. I feel like I went through exponentially more faffing about setting up the web server and forwarding to the accompanying Go server on DigitalOcean than I did getting my project running in modern browsers just using tsc.
rbtprograms 5y ago
This has also become my biggest issue with Typescript, and a lot of the people I have talked to about it agree this is the biggest pain point. I am not sure what a better system for this would be, but I do hope the Typescript team takes a hard look at this because I could see it being Typescript's Achilles heel.
- deleted 5y ago
  [deleted]
- smt88 5y ago
  This is an issue with JavaScript that TypeScript inherited. The many module systems and ES versions that need support are insane.
- wonnage 5y ago
  You don't actually need to do any of this stuff to run typescript. You could use Deno, ts-node, etc. to run code outside of a browser without a separate build step. And there's nothing wrong with using tsc to compile your code to JS for browsers, it's just slower for big projects. If you have an existing JS project that's being converted to TS, you likely have bundling, linting, and CI handled already; for the most part, you just add `preset: typescript` to your existing Babel config and you're done.
droobles 5y ago
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!
knubie 5y ago
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.
f00zz 5y ago
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.
- idolaspecus 5y ago
  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 5y ago
    [deleted]
  - Sindisil 5y ago
    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.
    - fiddlerwoaroof 5y ago
      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.
    - evan_ 5y ago
      computers don't need to boot "close to instantly" because nobody ever turns them off now. The "open browser" step in the previous comment is probably a noop because who even closes their browsers?
- twistedpair 5y ago
zackify 5y ago
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
- Groxx 5y ago
  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.
- jokethrowaway 5y ago
  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.
  - nicoburns 5y ago
    Have you tried esbuild. IMO it's a big step back in the right direction. We're not quite ready to switch to it on the frontend, but we're using it for our node.js (typescript) code. Configuration is 2 lines, and most of that's specifying which files to compile!
- aphexairlines 5y ago
  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) ?
  - 5y ago
rglover 5y ago
Yep, understand this completely. Love that talk, too. 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.
twistedpair 5y ago
Is it really that hard? > npm init > npm i --save-dev typescript Add "build":"tsc" to your package.json "scripts" Add a tsconfig.json file > npm run build Finito - you've compiled a TS project to JS
- PetahNZ 5y ago
  tsc doesn't bundle, or resolve imports, or transpile for cross browser though, does it?
  - TechSupportJosh 5y ago
    Using something like Parcel means it's usually as easy as adding parcel serve or parcel build to package.json and it handles the transpile, module resolution, bundling, tree shaking and hot reload for development.
- dboreham 5y ago
  What mystery meat is in that tsconfig.json though?
bcrosby95 5y ago
I watched the talk and didn't find it that interesting. Worst case scenario you can experiment to figure it out. Experiments in software are cheap. Compare it to the hardware level. The technology required to build a modern CPU is fucking amazing compared to things like being aware of cache coherency when writing code. The amount of time and experimentation to regain the knowledge required for building the full supply chain a modern CPU would be monumental compared to learning to go from something like JS to C.

vagrantJin 5y ago

In other words, the tooling and setup have become more complicated than the pieces of code we are writing? I feel like that sometimes. Not all bad though. I've learned that being spartan with your approach not only frees the mind of clutter but your stack wont be delicate shitshow of obscure tools 3-4 years down the line.

xyzzy_plugh 5y ago

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 massive impenetrable abstractions like React eons ago and I'm saner for it. Abstractions are supposed to remove complexity, not treat users like morons.

nicoburns 5y ago
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. You can just think in terms of React concepts (which are quite straightforward and have excellent documentation).
- agentwiggles 5y ago
  I got a good chuckle at the silliness of the mental image of hooking up a scope to diagnose a JS error. Thanks for the laugh. (tl;dr: lol)
- xyzzy_plugh 5y ago
  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.
  - nicoburns 5y ago
    > 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.
nsonha 5y ago
not a good example, knowing how things work is not a reason not to use debugger or similar tools
diob 5y ago
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.
- axelf4 5y ago
  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.
  - jokethrowaway 5y ago
    this, I understood how react is supposed to be used by reading the preact codebase
- xyzzy_plugh 5y ago
  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 https://hotwire.dev
  - amenod 5y ago
    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.
nawgz 5y ago
> 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?
azangru 5y ago
> 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.
deleted 5y ago
[deleted]
lr4444lr 5y ago
You're not wrong, but I think you're missing the value of React: the simplicity is not having to worry about the correctness or efficiency of your render engine. You get to go back to a more declarative way of writing code that comes with a modular composable style. There's a cost to pay for this: surrendering control (and easy insight) of the DOM you once knew to React's core logic. You do get a variety of callbacks to hook into, and I always encourage people to learn more about their frameworks, but you're not buying a set of convenience methods like you were with jQuery: this is effectively an interpreter between your data and its rendering.
schwartzworld 5y ago
The react extension is pretty powerful. You can work without it, but it enables debugging techniques that would be much harder without it.
flippinburgers 5y ago
I have a deep love/hate relationship with react so I largely agree with you. The last time I used the extension, it was obnoxious to use to try to find "state" within the page. Using redux makes things easier to debug from this perspective but you do need yet another extension for that too... I really think this is a sign of young engineers who have no experience with older approaches just memorizing "how things are done". They have no perspective on the tooling or experience.
apatheticonion 5y ago
Try to implement a website without React or Angular/Vue. When you hit your first list of elements and need to rerender the contents of just one of the elements, you will begin writing your own React. If you try to implement some kind of "two way databinding", you will first create React, then create Angular. However, unreadable and disorganised code can be written at any abstraction level. I have found React projects to be particularly hideous due to the fixation engineers have for tools like Redux. Angular tends to be a bit better because it's got some decent software design principles built in - but you know front end engineers. Any project with ngrx is a write off from an readability perspective. Isomorphic applications are also a meme that kill readability. I write most of my personal projects using Preact and some kind of reactivity helper (RIP `Object.observe`, I grieve for you).

meheleventyone 5y ago

The nice thing is you don’t need all this stuff it’s just one persons opinion of what you need. It’s mostly that you get a bunch of extra functionality with it. Additive rather than required. I feel like I went through exponentially more faffing about setting up the web server and forwarding to the accompanying Go server on DigitalOcean than I did getting my project running in modern browsers just using tsc.

rbtprograms 5y ago

This has also become my biggest issue with Typescript, and a lot of the people I have talked to about it agree this is the biggest pain point. I am not sure what a better system for this would be, but I do hope the Typescript team takes a hard look at this because I could see it being Typescript's Achilles heel.

deleted 5y ago
[deleted]
smt88 5y ago
This is an issue with JavaScript that TypeScript inherited. The many module systems and ES versions that need support are insane.
wonnage 5y ago
You don't actually need to do any of this stuff to run typescript. You could use Deno, ts-node, etc. to run code outside of a browser without a separate build step. And there's nothing wrong with using tsc to compile your code to JS for browsers, it's just slower for big projects. If you have an existing JS project that's being converted to TS, you likely have bundling, linting, and CI handled already; for the most part, you just add `preset: typescript` to your existing Babel config and you're done.

droobles 5y ago

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!

knubie 5y ago

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.

f00zz 5y ago

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.

idolaspecus 5y ago
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 5y ago
  [deleted]
- Sindisil 5y ago
  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.
  - fiddlerwoaroof 5y ago
    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.
  - evan_ 5y ago
    computers don't need to boot "close to instantly" because nobody ever turns them off now. The "open browser" step in the previous comment is probably a noop because who even closes their browsers?
twistedpair 5y ago

zackify 5y ago

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

Groxx 5y ago
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.
jokethrowaway 5y ago
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.
- nicoburns 5y ago
  Have you tried esbuild. IMO it's a big step back in the right direction. We're not quite ready to switch to it on the frontend, but we're using it for our node.js (typescript) code. Configuration is 2 lines, and most of that's specifying which files to compile!
aphexairlines 5y ago
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) ?
- 5y ago

rglover 5y ago

Yep, understand this completely. Love that talk, too. 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.

twistedpair 5y ago

Is it really that hard? > npm init > npm i --save-dev typescript Add "build":"tsc" to your package.json "scripts" Add a tsconfig.json file > npm run build Finito - you've compiled a TS project to JS

PetahNZ 5y ago
tsc doesn't bundle, or resolve imports, or transpile for cross browser though, does it?
- TechSupportJosh 5y ago
  Using something like Parcel means it's usually as easy as adding parcel serve or parcel build to package.json and it handles the transpile, module resolution, bundling, tree shaking and hot reload for development.
dboreham 5y ago
What mystery meat is in that tsconfig.json though?

bcrosby95 5y ago

I watched the talk and didn't find it that interesting. Worst case scenario you can experiment to figure it out. Experiments in software are cheap. Compare it to the hardware level. The technology required to build a modern CPU is fucking amazing compared to things like being aware of cache coherency when writing code. The amount of time and experimentation to regain the knowledge required for building the full supply chain a modern CPU would be monumental compared to learning to go from something like JS to C.