3 ms·
I think Deno is fine, and I think the project is interesting, but I also think those who want to use Typescript should do so, and stop pretending they're doing
by russellbeattie 6y ago
I think Deno is fine, and I think the project is interesting, but I also think those who want to use Typescript should do so, and stop pretending they're doing anything with Javascript. If I wanted deal with repetitive code like "function add(x: number, y: number): number {...}" I'd just use Java. There's reasons I love JavaScript, and not dealing with types is one of them. When is Typescript going to have its own version of the V8 engine and just leave JavaScript out of it? Honestly, it harkens back to the classic Microsoft Embrace, Extend, Extinguish strategy that I though we left behind in the early 2000s...
I like that Deno is resetting some of the underlying assumptions that Dahl made in Node. But I think he's throwing the baby out with the bath water. I actually like and prefer an explicit node_modules directory. Grabbing everything I need, and then being able to zip it up as needed to save or share is convenient and easy. Not sure why so much effort was made to avoid this module pattern. I really think using URLs is going to be a maintenance nightmare. Instead of changing one entry in package.json (great for testing new code or tweaking something locally), I have find/replace all the imports? Seems very odd unless I'm missing something big. Also, not a fan of the hidden .deno cache directory, but whatever.
Having to send along a shell script in order to even start an app is another problem. "Here's a JavaScript file which will do some task. In order to run it, you need to make sure you include these 10 command-line flags for security purposes. To make sure you don't forget them, I've included various shell scripts you can run depending on your platform." That's not improving anything.
- msndlensn 6y ago> If I wanted deal with repetitive code like "function add(x: number, y: number): number {...}" I'd just use Java. I don’t even like TS, but it’s pretty clear I can discount your opinion because you don’t even know what you’re talking about.
- dnissley 6y ago> Grabbing everything I need, and then being able to zip it up as needed to save or share is convenient and easy Isn't there a risk of cross platform incompatibility with some of the packages that compile on install?
- qudat 6y ago> Instead of changing one entry in package.json (great for testing new code or tweaking something locally), I have find/replace all the imports? This is my biggest beef. When building large scale applications there are many more files with imports than a typical large scale golang project that uses the url import scheme. It's just going to be a really annoying thing to deal with. ATM I see deno being great as a replacement for nodejs scripts and smaller scale projects. But for massive projects I don't see the gain.
- hombre_fatal 6y ago> I also think those who want to use Typescript should do so, and stop pretending they're doing anything with Javascript. It's constructive to make claims like people using Typescript are "pretending" to do something and should stop. People use Typescript because they've decided that Javascript with static typing is useful.
- smt88 6y agoHow much time have spent with TypeScript? I'm sincerely asking, because the answer is either "not much" or you didn't do a lot of research. You've misunderstood (or chosen not to investigate) some very fundamental things about TypeScript. > function add(x: number, y: number): number {...} You don't have to do this in TypeScript. In fact, you can use TypeScript without transpiling your code and without creating any types yourself. Why would you do that? Because a lot of open-source libraries now come with types included, so you get type-checking for those APIs essentially for free. > I'd just use Java Java has a nominal type system. If you want a new type, you have to create it. TypeScript has structural typing with type inference. That means you "just code" and the compiler will pick up your types if you go. If you write inconsistent code, it'll warn you. If you want to refactor a type, you now have enough metadata for your code to do that confidently. > When is Typescript going to have its own version of the V8 engine and just leave JavaScript out of it? Microsoft has had its own V8 competitor since around the time TypeScript was released[1]. They literally can't leave JavaScript out of TypeScript because every JavaScript program is a valid TypeScript program. TypeScript is a superset of Javascript. Other than the type system, it does not introduce any new features that are not on the EcmaScript roadmap. > harkens back to the classic Microsoft Embrace, Extend, Extinguish strategy Uh, no, it doesn't, because they have (A) open-sourced all of it, and (B) they haven't extinguished anything. Even if they did, there are massive numbers of people, including Google, who use TypeScript in production and would keep it going. There is no practical way to extinguish anymore. In fact, all of their behavior (e.g. with the .NET ecosystem) suggests that Microsoft doesn't do those things anymore. 1. https://en.wikipedia.org/wiki/Chakra_(JavaScript_engine) https://en.wikipedia.org/wiki/Chakra_(JavaScript_engine)