Since the release of Deno, people keep posting about their experience with this new runtime. I'll never install this piece of software and this is ...
For further actions, you may consider blocking this person and/or reporting abuse
I don't use TS. I think I will but I have not made the transition yet, and at this point it frustrates me because it makes it hard to read source code on Github haha. Deno, I'll wait a year for it stabilize before I try it.
I don't much care for the JS celebrities and the drama, so I don't have any skin in this game. But take a look at these bits:
I'm saying this in case you don't realize it, but those words don't position you as a fair and balanced writer. You're stating your conclusions as facts. It's like you're putting words in my mouth when I read it. And even though you explain your train of thought later, it was infuriating when I first read it.
And then you say:
This is my constructive feedback: if you want to state facts, do so. But dressing opinions and personal judgments as facts will only go well with those who agree already and are looking for confirmation.
And you end with:
I don't know for sure, but it sounds like you knew some of this was unnecessarily inflammatory.
I agree with you.
Stating somebody's previous failed attempt to do something might be stating facts, but it's nothing but a logical fallacy. It's Ad Hominem.
I could list a whole bunch of people who created brilliant technology but flunked various degrees. But it feels like wasted time to list them after reading a article like this.
I'm also not convinced, neither by TS nor by Deno.
The problem I see with Deno is that it's yet another distraction and yet another bandwagon that people are jumping on and wasting time on.
From what I've seen, Deno isn't advancing the "state of the art". The decision to dump package.json and simply use "import" to pull in all of your dependencies (and then having to use an ugly URL syntax if you want to specify versions) seems a step back. Npm, Yarn, package.json and so on are useful tools and proven technology, why throw it out the window and reinvent the wheel?
Most of all, I just see it as a distraction and a waste of time, which takes away people's focus from doing useful things. It's yet another toy to play around with, to learn the ins and outs of, and to waste time on instead of doing something productive (as in, create apps or useful software).
Less is more. Enough is enough. We don't need yet another way to do essentially the same thing.
Hats off and kudos big time to Ryan for inventing Node.js, but no I don't see the point of Deno.
If there's something new to invest time to learning, then it's only Dart and Flutter (or Go, but it doesn't have the web app framework like Flutter, not that I know of).
You're right ... Rust is also a good one
Although I definitely agree that Deno is simply a "reboot of Node.js" (so to speak), I feel as though your "general spectrum of TS users" underrepresents those who truly value from the tooling TS provides.
For me, my main use case for TypeScript is the tooling for IDEs. Debugging JS-powered web applications is much easier with type-checking because of some "contractual guarantees". I must concede that it doesn't solve all bugs, but the contracts do provide some helpful autocompletion suggestions during development.
In response to your suggestion of using JSDoc instead, I would agree to this to some extent because it is indeed a nice substitute for the "JS purists" out there who also want a piece of the TS tooling's cake.
I tried JSDoc myself before migrating my side projects to TypeScript, but I found the comments to be a bit too verbose and cumbersome for my liking. Furthermore, the JSDoc tooling for IDEs (such as in VS Code) is vastly inferior to actual TypeScript. Basic support for types are included, which is good for small projects, but I would imagine that larger projects would simply be better off using TS altogether instead of JSDoc.
And just to add a few more bits of information here, TypeScript also powers the JavaScript "language servers" for many IDEs. At least in VS Code, TypeScript powers the autocompletion for JavaScript and JSDoc. To say that TypeScript is just a fad misrepresents the value of JS tooling we have nowadays.
Sure, one can opt to write pure JS, but at the end of the day, many of our tools (for JS) depends on TypeScript to provide rich developer experiences.
In defense of Deno, Deno simply supports this kind of tooling "out-of-the-box" without the hassle of installing a plethora of NPM packages. That, to me, is the main selling point of Deno. Perhaps not the runtime itself, but the native support for the incredible tooling of the TS ecosystem.
you're
i genuinely didn't mean it in derogatory sense, i do appreciate the value TS provides for many people. sorry for any harsh feelings i do see that on the background of other points it might have looked negatively
No offense taken at all! 😉
This is a great discussion about what Deno really provides to the community. I just plopped in my two cents to the table.
yeah thanks for your comments they're really useful. as i said there are (and many) people who find salvation in ts and for the right reasons, like contractual obligations.
ah it's true ts provides jsdoc support for us so sure it deserves 👍 on that but it might have been just anything else. it's just because MS give vs code for free nobody wants to or needs to do that job because they won't be able to compete with the IDE. I don't know what webstorm uses for example, it might be TS it might not be, but sure it's possible to perform static analysis without TS isn't, so the implementation can be anything.
it's true jsdoc is pain for larger projects and your comment about it is very much appreciated. i don't use blank jsdoc i use a type manager that generates jsdoc on top of types, so that the types model is actually decoupled from implementation. that also hides away all those bulky /** */ comments in the implementation source code. It's true there's a lot of junk, and Go uses a different format and
/// natural language to describe [attributes], but once you put it away, it doesn't get in a way and one can focus on writing code. Finally, personally I'm doc maniac and want every public API param to be documented. I know in TS, you can type params to functions(s: string), but if you want to describe it, you still need to write jsdoc.I totally agree, man. I see what you mean. 👍
For me, the "bulkiness" of JSDoc comments is what threw me off the first time. The two code blocks below are semantically equivalent, but TypeScript frankly does it more elegantly.
But relating back to Deno, the whole point of my comment earlier was to shed some light on the perspective that Deno's goal as a runtime is to provide native support for what used to be a cumbersome process of installing and configuring various NPM packages. It's basically the best of JS, but in one neat executable.
As a disclaimer, though, I am certainly not advocating for it's production use yet, but it really is an interesting "toy" to look out for.
how do you mean various npm packages? what would you need apart from actual
typescript? aren't packages compiled into js with types.d.ts provided so that you don't really need anything.this i get 100% it's more natural to flow types like that (for PRIVATE code). Yet I still don't mind to write the first kind if it spares me installing 50mb binary :P
yet when you come writing APIs, in both cases you need
I mean you could've do
But then you're not generating full doc. Maybe it's not needed to have full docs with description of params, but I like it. In any way, I believe that documentation CAN be decoupled from code altogether so that you have your types defined completely independently of implementation, and can convert them into an interface in any language, be it js, ts, dart, go... the design stage i mentioned in the post involves object modelling, which can be split into Conceptual (business stakeholders), logical (db entities) and physical (data types). So that types are not even part of implementation. By taking a step back, we can take those out of the actual source code, and design "abstract" types. This means that we can then distribute those designs between members of the team, and they can communicate and work on them in their own time, such that the front-ender will do his job in JS/TS, and back-ender can work with the same data types in say Go or anything else and they'll be consistent with each other. there are many times web development is a one-man job, but for larger, and truly scalable projects we need a better approach :)
I can't really argue against your separation of concerns (as in documentation and implementation). I actually agree with it. Unfortunately, it's really just a matter of taste when it comes to the discussion of syntax.
In regard to the "NPM packages" I mentioned, I will particularly note Webpack and Babel for more advanced TypeScript projects. Testing TypeScript is a whole other beast in and of itself, too. That's what I mean by TypeScript being a hassle in the default Node environment (compared to Deno).
NodeJS is still really cool, I appreciate you taking the time to provide your perspective on this new topic.
I personally wish Ryan would've stuck with Node and just iterated on the project instead of resorting to a complete rewrite. I'm still happy with Node.
Nice! I'm 100% agree with you.
Whilst I enjoyed this article because of your writing skills, I couldn't agree with almost any of your points. As Mikael mentioned in his comment, it seems you were inflammatory on purpose and just wanted to vent (and not make actually valid arguments against Deno). But to each their own.
The biggest controversy to me here was that you have issues with Deno's take on package management and at the same time preach how great Go is (which handles its dependencies the same way).. Anyone else see the irony? 🙄
Thank you for the write-up though
I look at coding as the right tools for the right job. I'm not sure about Deno — my job doesn't involve a lot of JavaScript on the server or client at the moment; I also feel that servers are better handled by closer-to-the-metal structures. However, I disagree on TypeScript for one fundamental reason: It's easier to fail-safely.
Development is hard. Debugging and testing is hard. This is why we can command significant salaries for what is basically turning requirements into machine-langauges. If it was easy, there'd be an automated way to do that translation, but because of the inevitable number of moving parts, it needs a lot of thought, attention to detail and consideration before a simple requirement statement can become something that runs on a client or a server; and that's before you start looking at OWASP or other security requirements.
TypeScript makes it harder to make stupid mistakes. Type Security makes it harder to make stupid mistakes, is a better way of saying things. The default is to go, "Oh — this is wrong, did you really mean that?" I want that in my life, because I want to have the 'easy' to check stuff checked for me, I don't want to have to remember to write a unit test just to make sure that internal movements are right. That's the equivalent of contract testing, and should be automateable. TypeScript gives me that.
I don't really have an opinion on the other parts — I approve of more tools, but I don't see TS or JS as server-side suitable tools at their heart. They've been used that way, and they make amazing utilities and tooling, which constantly impresses me.
Really good article!! We share the same opinion on TS and Deno! :)
"Design Doc: Use JavaScript instead of TypeScript for internal Deno Code"
docs.google.com/document/d/1_WvwHl...
Ryan Dahl:
"So - to make a long story short - we're removing the types from internal code and making it pure JS
this reduces complexity and helps us ship a faster product."
Condescending, hot garbage.
I think the claim that deno is less safe than node is intellectually dishonest. The only reason malware hasn't killed npm is because it has spent enormous amounts of money on tooling to keep track of possible vulnerabilities, and bitcoin miners still exist. Deno is sandboxed, and does not need to pull dependencies from a single authority. Someone deleting left-pad should not bring down the internet.
Would you travel on an airplane developed in JS? Highly productive Dynamical Safety 😂 Ups, I forgot some unit test...
FYI, parsing and serializing inputs are performant-killers but for a great safety in runtime. Check Zod.