5 ms·

Man the things that pass for innovation in the node-adjacent space continues to blow my mind. It feels like hte horrors of /r/programmerhumor meets generic inte

Man the things that pass for innovation in the node-adjacent space continues to blow my mind. It feels like hte horrors of /r/programmerhumor meets generic internet hype-beast cycles.

moritzwarhier 4y ago
What kind of innovation would you prefer? (removed snark) Web code is made of duct-tape, nothing new. Deno is a pretty big departure from Node in some respects as far as I can see. I admit I haven't used it, but if it keeps only half of its promises to simplify frontend bundling and compilation/transpilation, I think it's innovative.
agency 4y ago
A poor craftsman blames their tools.
- hinkley 4y ago
  Because a good craftsman picked his tools and knows it’s his fault if they’re garbage. This pattern of “thinking” pisses me right off. It’s an axiom about quality and avoiding deflection and it’s always used in a low-quality reply as a form of deflection. I can’t recall the last time I heard someone use that phrase the way it’s meant to be used.
- dathinab 4y ago
  A good craftsman knows not to use bad tools.
  - simplotek 4y ago
    > A good craftsman knows not to use bad tools. In your opinion, what's so wrong in prefering to just run your JS/TS code without having to maintain a build/bundling step? To me, Deno's approach is undoubtedly a killer feature with regards to the status quo of the whole nodejs ecosystem. Don't you agree?
    - horsawlarway 4y ago
      Eh... I don't really think this is a killer feature. If you don't want to maintain a build step, use a framework that's configured it for you and avoid customizing it. Lots of frameworks already do that, this is just Deno's implementation of the same thing. There's STILL a build step, they're running esbuild in the background for you. You've just lost visibility and control, exactly the same as if you picked a framework that gives you a default webpack config. If anything, I see esbuild as the real "killer feature" here, since it's just really fast. Fast enough to bundle at request time.
    - kelnos 4y ago
      Builders and bundlers fail sometimes. I don't want to introduce an extra point of failure in my production services. Maybe this is nice for local development. But really it just feels like the tooling version of a "code smell". If people think bundling/building is too slow, then people should work on making that faster. Maybe that means people need to stop writing JS builders/bundlers in JS, and use a language like Rust that has better performance characteristics. I wouldn't consider that a failure; it's just an admission that we should use the right tool for each job. Speaking of Rust, the Rust compiler is fairly slow, but my proposed solution wouldn't be "get rid of it and have it dynamically compile at runtime", it's "profile it and make it faster" (which people are doing!).
    - claytongulick 4y ago
      Alternately, you can just stick close to standards and not really worry about it. I write plain CSS. I use Web Components as my unit of isolation, generally sticking with the light dom. I have a small state utility [1] that I wrote years ago and works great. I do have a build step before deployment, but I use vite during development so I have zero "make a change, wait, test, rinse, repeat" downtime. When it's time to deploy, vite build does the trick nicely. I don't use frameworks. I don't use JSX. I don't use typescript, for types I use jsdoc in vscode which gives me 90% of the benefits of TS without the downsides. My pages are light, fast and easy to maintain. I don't have to deal with painful build steps, or framework churn. Debugging is simple. No multiple layers of transforms and sourcemaps, WYSIWYG. I'm pretty passionate about the "keep it simple" philosophy. I chose to innovate in the problem domain, not the technical one. Anecdotally, I had a new developer join my team and he was initially very confused. He said "it's just so strange using this tech stack. You make a change, and you see it..." I didn't know whether to laugh or cry. [1] https://www.npmjs.com/package/applicationstate https://www.npmjs.com/package/applicationstate
  - geysersam 4y ago
    The web is not a bad tool.
pianoben 4y ago
Conceptually, I don't see how this is much different from JIT compilers in the JVM, CLR, and similar runtimes. You don't hear so much from Java devs about how they can't* see the machine code their customers are running. They talk about cold-start performance, but accept that the first few requests will be slower in exchange for the productivity and eventually-high-performance. Now that I think about it, this is how V8 works too, for JS code itself! Why wouldn't this principle apply to bundling?
- nine_k 4y ago
  JIT compilers at least do the work incrementally, profile the code to provide the best (or several) versions of native code, etc. That is, they adapt to the particular invocation, doing stuff an AOT compiler cannot do (especially for dynamic languages like JS). I wonder if running the bundler on startup, and throwing away the (identical) result of a previous invocation of the bundler, makes much sense. It at least could persist it optionally, like Python does with .pyc files.
- derefr 4y ago
  JITs exist because 1. certain compilation can't be done at compile time, because the code is dynamically synthesized at runtime from data only available at runtime; and 2. knowing how the code is already being used at runtime through an interpreter, can help optimize the compiled code ("profile-guided JIT.") Bundling on first request has neither of these advantages: everything that is getting compiled at runtime could have been compiled at compile-time; and no information is yet available on how the code will be used.
- kelnos 4y ago
  The difference is that the JIT doesn't "fail". Builds and bundling can fail, and I wouldn't want to trust that all the machinery the builder/bundler depends on (especially if it needs to fetch things over the internet) are available and working properly. Put another way, as long as the `java` command is present and working on the production machine, I can be pretty sure my service is going to run and work (aside from any bugs in my code, of course). With Deno, more moving parts on the production machine need to be working properly in order to ensure things work properly.

Man the things that pass for innovation in the node-adjacent space continues to blow my mind. It feels like hte horrors of /r/programmerhumor meets generic internet hype-beast cycles.

moritzwarhier 4y ago

What kind of innovation would you prefer? (removed snark) Web code is made of duct-tape, nothing new. Deno is a pretty big departure from Node in some respects as far as I can see. I admit I haven't used it, but if it keeps only half of its promises to simplify frontend bundling and compilation/transpilation, I think it's innovative.

agency 4y ago

A poor craftsman blames their tools.

hinkley 4y ago
Because a good craftsman picked his tools and knows it’s his fault if they’re garbage. This pattern of “thinking” pisses me right off. It’s an axiom about quality and avoiding deflection and it’s always used in a low-quality reply as a form of deflection. I can’t recall the last time I heard someone use that phrase the way it’s meant to be used.
dathinab 4y ago
A good craftsman knows not to use bad tools.
- simplotek 4y ago
  > A good craftsman knows not to use bad tools. In your opinion, what's so wrong in prefering to just run your JS/TS code without having to maintain a build/bundling step? To me, Deno's approach is undoubtedly a killer feature with regards to the status quo of the whole nodejs ecosystem. Don't you agree?
  - horsawlarway 4y ago
    Eh... I don't really think this is a killer feature. If you don't want to maintain a build step, use a framework that's configured it for you and avoid customizing it. Lots of frameworks already do that, this is just Deno's implementation of the same thing. There's STILL a build step, they're running esbuild in the background for you. You've just lost visibility and control, exactly the same as if you picked a framework that gives you a default webpack config. If anything, I see esbuild as the real "killer feature" here, since it's just really fast. Fast enough to bundle at request time.
  - kelnos 4y ago
    Builders and bundlers fail sometimes. I don't want to introduce an extra point of failure in my production services. Maybe this is nice for local development. But really it just feels like the tooling version of a "code smell". If people think bundling/building is too slow, then people should work on making that faster. Maybe that means people need to stop writing JS builders/bundlers in JS, and use a language like Rust that has better performance characteristics. I wouldn't consider that a failure; it's just an admission that we should use the right tool for each job. Speaking of Rust, the Rust compiler is fairly slow, but my proposed solution wouldn't be "get rid of it and have it dynamically compile at runtime", it's "profile it and make it faster" (which people are doing!).
  - claytongulick 4y ago
    Alternately, you can just stick close to standards and not really worry about it. I write plain CSS. I use Web Components as my unit of isolation, generally sticking with the light dom. I have a small state utility [1] that I wrote years ago and works great. I do have a build step before deployment, but I use vite during development so I have zero "make a change, wait, test, rinse, repeat" downtime. When it's time to deploy, vite build does the trick nicely. I don't use frameworks. I don't use JSX. I don't use typescript, for types I use jsdoc in vscode which gives me 90% of the benefits of TS without the downsides. My pages are light, fast and easy to maintain. I don't have to deal with painful build steps, or framework churn. Debugging is simple. No multiple layers of transforms and sourcemaps, WYSIWYG. I'm pretty passionate about the "keep it simple" philosophy. I chose to innovate in the problem domain, not the technical one. Anecdotally, I had a new developer join my team and he was initially very confused. He said "it's just so strange using this tech stack. You make a change, and you see it..." I didn't know whether to laugh or cry. [1] https://www.npmjs.com/package/applicationstate https://www.npmjs.com/package/applicationstate
- geysersam 4y ago
  The web is not a bad tool.

pianoben 4y ago

Conceptually, I don't see how this is much different from JIT compilers in the JVM, CLR, and similar runtimes. You don't hear so much from Java devs about how they can't* see the machine code their customers are running. They talk about cold-start performance, but accept that the first few requests will be slower in exchange for the productivity and eventually-high-performance. Now that I think about it, this is how V8 works too, for JS code itself! Why wouldn't this principle apply to bundling?

nine_k 4y ago
JIT compilers at least do the work incrementally, profile the code to provide the best (or several) versions of native code, etc. That is, they adapt to the particular invocation, doing stuff an AOT compiler cannot do (especially for dynamic languages like JS). I wonder if running the bundler on startup, and throwing away the (identical) result of a previous invocation of the bundler, makes much sense. It at least could persist it optionally, like Python does with .pyc files.
derefr 4y ago
JITs exist because 1. certain compilation can't be done at compile time, because the code is dynamically synthesized at runtime from data only available at runtime; and 2. knowing how the code is already being used at runtime through an interpreter, can help optimize the compiled code ("profile-guided JIT.") Bundling on first request has neither of these advantages: everything that is getting compiled at runtime could have been compiled at compile-time; and no information is yet available on how the code will be used.
kelnos 4y ago
The difference is that the JIT doesn't "fail". Builds and bundling can fail, and I wouldn't want to trust that all the machinery the builder/bundler depends on (especially if it needs to fetch things over the internet) are available and working properly. Put another way, as long as the `java` command is present and working on the production machine, I can be pretty sure my service is going to run and work (aside from any bugs in my code, of course). With Deno, more moving parts on the production machine need to be working properly in order to ensure things work properly.