Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming Open Source

Addressing 'Design Mistakes' in Node.js, Its Developers Release JS/TypeScript Runtime Deno 1.0 (zdnet.com) 62

Posted by EditorDavid from the Deno's-not-Node dept.
"The makers of the widely used JavaScript server-side runtime, Node.js, have released Deno 1.0, a new runtime for JavaScript and TypeScript that addresses 'design mistakes' in Node.js," reports ZDNet: Just like Node.js or Node, the Deno runtime is for executing JavaScript outside a web browser. However, unlike Node.js, Deno offers first-class support for Microsoft's increasingly popular Typescript, a superset of JavaScript designed for large projects... "With the changing JavaScript language, and new additions like TypeScript, building Node projects can become an arduous endeavor, involving managing build systems and other heavy-handed tooling that takes away from the fun of dynamic language scripting," writes Node.js creator Ryan Dahl in a blogpost co-authored by fellow Deno developers Bert Belder and Bartek Iwanczuk...

Deno is based on Google's Chromium V8 JavaScript engine.
While its standard modules are all written in TypeScript, Infoworld points out that Deno "can be a replacement for utility scripts that may have been written in Python or Bash... Deno was designed as a series of Rust crates to allow integration at different layers." (A blog post by its developers notes Deno "makes it easy to bind Rust future-based APIs into JavaScript promises.")

But "Like a web browser, it knows how to fetch external code," the developers wrote, calling Deno "a web browser for command-line scripts" while arguing that with Node, "the mechanism for linking to external libraries is fundamentally centralized through the NPM repository, which is not inline with the ideals of the web... Also like browsers, [Deno] code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission." In an interview Dahl tells JAXenter they're already keeping an index of third party modules that work on Deno at https://deno.land/x/.

"It's important to understand that Deno is not a fork of Node," the developers' blog post explains. "It's a completely new implementation..."

"One last thing," the blog post concludes. "Consider supporting this open source software work by pre-ordering a Deno v1.0 hoodie."
This discussion has been archived. No new comments can be posted.

Addressing 'Design Mistakes' in Node.js, Its Developers Release JS/TypeScript Runtime Deno 1.0 More

Addressing 'Design Mistakes' in Node.js, Its Developers Release JS/TypeScript Runtime Deno 1.0

Comments Filter:

  • I'm really looking forward to rewriting my existing bash scripts in another interpreted language.

    Also, why release a separate project? Typescript is a superset of javascript, so why not just add it into node as a new feature (if you're into node, anyway)? It shouldn't break existing stuff.

    • in another interpreted language

      Is it still the case that V8 doesn't even have an interpreter? I know it started like that but I don't know if they've added one later.

    • Re: (Score:3, Informative)

      by Anonymous Coward
      Why not just add a Node feature?

      Well Node has been forked many times (eg io.js), or had wrappers around it (eg ts-node, babel-node), but like any software Node has a particular architecture and going against the grain by having more configuration options and more code paths could be a maintenance problem, and could slow down feature development.

      Dano is a major breaking change from Node. It does break existing stuff in Node because so much code depends on that architecture. Dano affects module resolu

      • My favourite feature is importing from urls while having sandboxing.

        Ah, I see the dream of Bracha's Newspeak lives on.

      • Re: (Score:2)

        by znrt ( 2424692 )

        My favourite feature is importing from urls while having sandboxing.

        for some reason this sentence made me shudder a bit ...

        looking a bit more into it, afaik it ends up doing exactly what node does just with different workarounds, except you just hand manage urls instead of relying on a combination of sources and package manager workflow.
        https://deno.land/manual/linki... [deno.land]

        it doesn't even address the problem of trust. change everything so everything can stay the same?

        now, sandboxes are indeed a nice thing to have but i'm skeptic that defaults and an "all or nothing" approach wi

    • Re: (Score:2)

      by jblues ( 1703158 )
      I was thinking the same. If I wanted this to take off quickly, call it "Node 14 - built on a new architecture and now with built-in TypeScript support.". You can still run your transpiled projects, but as soon as you have a greenfield project you can skip all that.

    • Re: (Score:2)

      by AmiMoJo ( 196126 )

      The idea of pulling code off the web sounds like a bad one too. At least with a repo you have some quality control, some attempt at security and a way of managing versions.

      • But "pulling code off the web" is a superset of pulling it from a repo. What prevents you from pulling code from the places *you* want it to? Assuming that *you* are in control of quality, security, and managing versions of those places, of course.

      • Re: (Score:2)

        by Tailhook ( 98486 )

        The idea of pulling code off the web

        import "file:///not/off/the/web/index.js"?

        "URL" is not synonymous with "random crap." Should Deno eventually matter 99% of the URLs will doubtless end up pointing to some (at least somewhat) trusted repository with version controlled releases, signatures and all the rest a la npm. This Deno 1.0 news is old now and from the moment it appeared till now it has been plauged by people chiming in with this same simple minded "concern;" that because URL Deno users will somehow be required to use dubious shit "o

    • Also, why release a separate project? Typescript is a superset of javascript

      It's not just typescript, they made a lot of changes, including writing parts of it in Rust. Here are some main differences from Node:

      *) Deno does not use npm, it uses modules referenced as URLs or file paths

      *)Deno does not use package.json in its module resolution algorithm.

      *) All async actions in Deno return a promise. Thus Deno provides different APIs than Node.

      *) Deno requires explicit permissions for file, network, and environment access.

      *) Deno always dies on uncaught errors.

  • Insecurity by design (Score:3)

    by Burdell ( 228580 ) on Saturday May 16, 2020 @03:45PM (#60068118)

    I have never heard anybody requesting a "web browser for command-line scripts"... the last thing I want for CLI scripting is a language that is expected to go download things at runtime and then run them. Any language can do that of course, but the others don't have that as a primary design goal and expectation.

    • And if you want "a web browser for command-line scripts", wget and curl have been around forever - and both work very well (almost certainly much better than this new thing).

    • Re: (Score:2)

      by Tawnos ( 1030370 )

      What about partial/full pre-processing of web sites or parts thereof to optimize client-side access for different platforms or scenarios?

    • You'd think nobody would want to deal with JS/Node if they don't have to, and yet AWS lets you write lambdas with the Node runtime. Of course three of the other options are Java, Ruby and Python so it's a "pick your poison" type of thing.

  • Fragmentation (Score:5, Insightful)

    by backslashdot ( 95548 ) on Saturday May 16, 2020 @03:54PM (#60068142)

    The more languages and technologies there are, the harder it becomes to find people to become experts that can develop and maintain code. Who cares? Well it also means a lot of people end up wasting time and money betting on the wrong horse. Think about it, if you have a web application .. you have to find someone who knows that specific technology (react, angular, or vue.js? etc.). Oh, and that's just on the front end .. on the backend there's a ton of different technologies too .. java, php, node.js, even C++ and God knows what else. And each database is different enough too. It means resources are diverted to duplicating efforts rather than developing new and interesting end products. That's not including the fact that people specializing in some esoteric technology can charge big money (unlike it goes out of fashon). It's better for the industry, for the overall employment rate, for productivity, for the economy, to live with the quirks of the existing languages and maybe patch or refine them rather than re-creating whole new technologies with all new kinds of bugs and shortcomings.

    • you have to find someone who knows that specific technology (react, angular, or vue.js? etc.).

      These are interchangeable. If you want to get hired as a frontend dev these days, you have to know at least one Javascript framework, but you don't have to know all of them. You do have to know CSS and HTML.

      on the backend there's a ton of different technologies too .. java, php, node.js, even C++

      In practice, if you know one stack, it's fairly easy to move around. Fundamentally most websites are just databases, business logic, and APIs. There are a few newer things that are becoming more common, like micro-services (so, message queues, basically), and learning how to use AWS.

      And each database is different enough too.

      Nah, databases are m

      • If you join a new company with a different stack than you've used before, then you'll find the biggest time suck is not learning the stack, it's learning to work your way around their crappy codebase.

        And THAT is what most managers and HR drones fail to understand.
        Let be X and Y different implementations of of $THING (Where THING can be a programming language, framework, database, CRM, you-name-it), most people assume they are so different that an expert must start from scratch to switch from one to the other. In truth, any interested party who worked long enough with X would be able to work very well with Y after a few months tops.

        I told this to a HR drone insisting with "experience using Y, not X": loo

      • If you want to get hired as a frontend dev these days, you have to know at least one Javascript framework, but you don't have to know all of them. You do have to know CSS and HTML.

        Then maybe you don't know to need that one JS framework. (Aside from the big one, of course - the common browser API.)

        Nah, databases are mostly the same. It's either a relational database, or a K/V store like Redis.

        Or a transactional object engine like AllegroCache or GemStone, right?

    • .. as proven empirically time and again in the software industry. It's why enterprise software tends to be way behind the curve - stability and quantifiability are underrated. It's a lot more fun and motivating to be working with the latest technologies but it's not as productive as we fool ourselves into thinking it is.
      I guess it also relates to goal and expectation management: if the software needs to be 99.99% bug-free, you need all your tools to be a known quantity to at least that degree. You can alway

    • I get it, but you're critique doesn't apply here IMHO. If the Deno people did improve on node js, which was their aim after all, then Deno will simply replace node. I do php and php does have significant advantages over node. If the Deno people did things right, this might actually be a good reason to finally look into server side js.

      But in general I agree with your assessment of the overall situation in IT. We're spread too far out and too many people want to reinvent the wheel without greasing the existin

  • This thing is far more of a problem than a help. It allows semi-competent people to do dangerous things far too easily.

  • "Javascript is a shitty language and a shitty runtime for getting things done."

    As one would expect, I've met up against many different responses when I say that, those that. Some people agree, some disagree but are interested in a real discourse, and of course the zealots that vehemently defend javascript against all naysayers.

    Whether you love it or hate it, it's the only well understood choice for running browser-side code right now, which means almost every developer out there either knows enough of it to

    • Never mind multi threading. The fact that JavaScript is completely event driven means that you need to use callbacks or promises or async/await to take one step after the other. This is horrifying. From the beginning of computer time, programming languages had this thing called the ; operator. Yes, in many languages it is an operator. A ; B means “do A first and then do B”.

      It is an utterly fundamental thing, it embodies the concept of time itself. He fact that you need a complicated syntactic c

      • Re: (Score:2)

        by narcc ( 412956 )

        What on earth are you talking about? This is timecube level insanity.

      • Re: (Score:1)

        by leptons ( 891340 )
        It's funny to watch neckbeards that don't have a clue about Javascript try to rip it apart. You're falling over yourselves in your rage while making complete fools of yourselves.

    • Re: (Score:1)

      by leptons ( 891340 )
      Javascript has native binary data strings, you just don't know Javascript.

  • Really -- much of the strength of JavaScript is in its many freedoms, such as dynamic typing and lack of constraints. Typescript is expressly for the purpose of doing the exact opposite with JavaScript, often cited as trying to "fix" JavaScript. These people don't realize that the freedom in JavaScript is not a mistake but an escape from the tyranny they are trying to put into the language.

    It is a typical to respond to complex or suboptimal code by trying to put constraints and controls to enforce a boile

    • Typescript may "corrupt" Javascript, but it also reduces your bug count by 15%.

      • Re: (Score:2)

        by znrt ( 2424692 )

        Typescript may "corrupt" Javascript, but it also reduces your bug count by 15%.

        maybe if you only hire programmers that don't really care what actual datatype they're passing to a function, and that's your problem right there. along with the 'know one framework, know them all' cut&paste mentality.

        typescript is cool and has its uses. it's being abused though to address problems that aren't technical, but social, by shoehorning a tool into what it never was and which isn't technically necessary. just like that object oriented fanaticism mess all over again.

        • maybe if you only hire programmers that don't really care what actual datatype they're passing to a function

          This is a really weird statement, since in Typescript you know what type you are passing in to a function, but in Javascript you don't.

          • Re: (Score:2)

            by znrt ( 2424692 )

            on the contrary, in javascript you have to know. with typescript you just wait for a preprocessor to tell you that you didn't.

            this is not picking on static typing which has a load of benefits (as do dynamic languages), this is on the collective fiasco of trying to force an "untyped" language into a typed one as a silver bullet for sloppy and cheap production, which doesn't really solve anything and just creates more problems.

        • I look at it again and again and thank myself for choosing a web design))) Everything is much simpler with me. Did Photoshop become uncomfortable? No need to worry, just use Figma! Is there a need to speed up the work? Choose from any templates to choose from, just check page [saasdesign.io]. Do I understand that coders hate me for this simplicity? Oh yeah)) But it was their choice to rebuild for each change.

    • Re: (Score:1)

      by leptons ( 891340 )
      Absolutely agree with everything you said. Typescript is like having 10 training wheels on a bike while wearing a suit of steel armor, just because someone doesn't trust the people they hire to write code. It's overbearing for those who actually have discipline and know how to ride a 10 speed without causing it to crash.

  • But node.js really helps to bridge JavaScript code to the desktop. Why would you want to do this, you ask? Well I would normally agree that NEVER is the correct response, But it;'s not always up to you, and when you are tasked with taking a HUGE JavaScript code base and get it running in Unity, being able to drop it into node.js and only fix up missing APIs (specifically DOM) and replace the frontend with a HTTP serever (for example) is a lot easier than manually converting the entire codebase to C#, while

  • At least 5 years Deno experience required, At least 10 years bash experience, At least 15 years python 3 experience
  • Node.js has so many dependencies for a windows installation, that the installation [for me] fails miserably due to dependencies of the installation itself. Can't debug js code if I have to debug the js code runtime installer first.

  • Mistakes have been made (Score:3)

    by sad_ ( 7868 ) on Monday May 18, 2020 @03:52AM (#60072916) Homepage

    Mistakes have been made in Node.js,
    these are now corrected in Deno, but new mistakes have been made, that will surface in a few years.

    Making room for a new framework correcting all of Deno's mistakes and having new ones of itself.

Slashdot Top Deals

To be awake is to be alive. -- Henry David Thoreau, in "Walden"

Close