4 ms·

Personally I appreciate being able to choose my linter, compiler, dialect etc. I also tend to prefer distributed solutions. Deno running the entire environment

Personally I appreciate being able to choose my linter, compiler, dialect etc. I also tend to prefer distributed solutions. Deno running the entire environment is a negative for me, at least for now. To me, it just shows an approach of ignoring what already exists and reinventing the wheel. I've tried to get Deno to work before in production, but it had so many compatibility issues last I tried it would take weeks or months to refactor things so it would work.

bartlomieju 6y ago
> Personally I appreciate being able to choose my linter, compiler, dialect etc. I completely agree with that! But on the other hand with plethora of tools available it can be quite overwhelming to configure all the tools, especially for new users. > I've tried to get Deno to work before in production, but it had so many compatibility issues last I tried it would take weeks or months to refactor things so it would work. Work on compatibility layer with Node is ongoing [1]. With every release there's some new API being compatible, but far from over. [1] https://deno.land/x/std@0.80.0/node https://deno.land/x/std@0.80.0/node
apatheticonion 6y ago
I did too, but the amount of compiler configurations out there kills me. If you write a library, you need to support several export types for node packages. In your `package.json` you must include a `main` `module` and `exports` object and provide two compiled outputs, one commonjs and one es modules. Then you need to worry about mutating import paths to include the file extension, which can cause trouble when you keep the commonjs and esmodule files in the same folder. Also the esmodule loader in node doesn't have access to things like `__dirname`, so certain things can break. not to mention node_modules... It's like IE support but on the back end. Then you step into the front end and it's another whole layer of chaos. Give me opinionated compilers with minimal configuration and let me write code.
- pimterry 6y ago
  > If you write a library, you need to support several export types for node packages. This is a hassle, but didn't used to be true for node - you could say the same as all the above for commonjs, wasn't it nice to have a single opinionated standard. In the short term, deno avoids this by dropping backwards compat, great! But in the long term, I don't see how it doesn't end up in exactly the same place as soon as the next big change to JS modules comes out, or the next new build environment or wasm integration becomes bigger or... Unless they have a fundamentally different strategy for the future (either 'we will never evolve' or 'we will evolve with ecosystem-wide breaking changes') they're going to end up in the same state as node today, eventually. I haven't seen any discussion of such a strategy at all. It's just a temporary reset - unlike node, they get to break backward compat and support the One True Format because they're new, that's all.
mark_and_sweep 6y ago
> Personally I appreciate being able to choose my linter, compiler, dialect etc. (...) Deno running the entire environment is a negative for me, at least for now. Nobody forces you to use the deno dev tools. You can still run eslint, prettier and closurescript, if that's your sort of thing. Personally, I prefer deno lint over eslint and deno fmt over prettier since they are much faster. I'm even using dprint (which is a standalone project for code formatting, https://dprint.dev/ https://dprint.dev/) in Node projects. Similarly, before deno test, I created my own deno testing tool. Now I use deno test instead since it's just better - not because anyone's forcing me to use it. The integrated dev tools are a convenience feature. I hope that's kinda obvious.

bartlomieju 6y ago

> Personally I appreciate being able to choose my linter, compiler, dialect etc. I completely agree with that! But on the other hand with plethora of tools available it can be quite overwhelming to configure all the tools, especially for new users. > I've tried to get Deno to work before in production, but it had so many compatibility issues last I tried it would take weeks or months to refactor things so it would work. Work on compatibility layer with Node is ongoing [1]. With every release there's some new API being compatible, but far from over. [1] https://deno.land/x/std@0.80.0/node https://deno.land/x/std@0.80.0/node

apatheticonion 6y ago

I did too, but the amount of compiler configurations out there kills me. If you write a library, you need to support several export types for node packages. In your `package.json` you must include a `main` `module` and `exports` object and provide two compiled outputs, one commonjs and one es modules. Then you need to worry about mutating import paths to include the file extension, which can cause trouble when you keep the commonjs and esmodule files in the same folder. Also the esmodule loader in node doesn't have access to things like `__dirname`, so certain things can break. not to mention node_modules... It's like IE support but on the back end. Then you step into the front end and it's another whole layer of chaos. Give me opinionated compilers with minimal configuration and let me write code.

pimterry 6y ago
> If you write a library, you need to support several export types for node packages. This is a hassle, but didn't used to be true for node - you could say the same as all the above for commonjs, wasn't it nice to have a single opinionated standard. In the short term, deno avoids this by dropping backwards compat, great! But in the long term, I don't see how it doesn't end up in exactly the same place as soon as the next big change to JS modules comes out, or the next new build environment or wasm integration becomes bigger or... Unless they have a fundamentally different strategy for the future (either 'we will never evolve' or 'we will evolve with ecosystem-wide breaking changes') they're going to end up in the same state as node today, eventually. I haven't seen any discussion of such a strategy at all. It's just a temporary reset - unlike node, they get to break backward compat and support the One True Format because they're new, that's all.

mark_and_sweep 6y ago

> Personally I appreciate being able to choose my linter, compiler, dialect etc. (...) Deno running the entire environment is a negative for me, at least for now. Nobody forces you to use the deno dev tools. You can still run eslint, prettier and closurescript, if that's your sort of thing. Personally, I prefer deno lint over eslint and deno fmt over prettier since they are much faster. I'm even using dprint (which is a standalone project for code formatting, https://dprint.dev/ https://dprint.dev/) in Node projects. Similarly, before deno test, I created my own deno testing tool. Now I use deno test instead since it's just better - not because anyone's forcing me to use it. The integrated dev tools are a convenience feature. I hope that's kinda obvious.