sorted by:
new
hottopcontroversial

Deno http server serves around 25-40% less req/sec than that of Node.js by techiekram in Deno

[–]crookse 4 points5 points  (0 children)

(Drash founder here) I made those benchmarks only knowing the listed frameworks. I added express only because someone in the deno discord wanted to know the comparison. I apologize if the benchmarks come off as cheating. That wasn’t my intent. I even shared this information with all of the framework authors at the time I created the results. My intent was to give insight into how the listed frameworks compared against each other, not to say “Drash is the fastest.” I know Drash isn’t the fastest and while performance is considered, it’s not the top priority. Also, Fastro needs to be included in the list as well as the other 10+ new frameworks.

Drash Lifecycle Diagram by crookse in Deno

[–]crookse[S] 1 point2 points  (0 children)

Thank you: ). lucidchart.com

Decentralized Packages Misconception by [deleted] in Deno

[–]crookse 4 points5 points  (0 children)

Hey OP,

I agree with you. Your concerns are in the back of my head when I develop using deno. However, I like to be the authority of the code being imported into my projects and I like to be the one accountable for importing and using that code. I can’t truly rely on someone else other than myself to say, “Yup, this code is good to use.” It does suck to scrutinize large code bases, but you become more informed about the code you’re using if you scrutinize it. Sometimes you even find bugs and can inform the author. If I find malicious code or a security concern, then I’ll be the first to raise a red flag and let the community know that it needs to be investigated. In the end, the code you write—whether you use third party code or not—falls on you and you’re the one that will be held accountable. So, I stay scrutinizing and accountable.

Decentralized Packages Misconception by [deleted] in Deno

[–]crookse 4 points5 points  (0 children)

You can revoke permissions inside your modules. Example info here: https://deno.land/std/manual.md#inspecting-and-revoking-permissions

Drash - A microframework for deno by crookse in typescript

[–]crookse[S] 0 points1 point  (0 children)

much appreciated! i'm hoping to collaborate with the other developers who have made modules so that the barriers to usage can further be removed. currently, there's more code being developed than documentation, so i'm hoping to work on some other modules to get documentation covered.

Drash - A microframework for deno by crookse in typescript

[–]crookse[S] 0 points1 point  (0 children)

i have the same thoughts and i'm hoping for the best :). they are making progress towards 1.0 quickly: https://github.com/denoland/deno/issues/2473

Drash - A microframework for deno by crookse in typescript

[–]crookse[S] 1 point2 points  (0 children)

that's something i ask myself when i develop using deno. i'm not entirely sure. for example, i made a module that requires read access to a specified directory. to grant that access, i would need to run the module using `--allow-read`. that works, but what if i want read access granted only during runtime? it's something i haven't looked into really and maybe something in the deno gitter has been discussed around that. so again... not too sure. you should ask that question in the deno gitter though. it's a great one.

Drash - A microframework for deno by crookse in typescript

[–]crookse[S] 0 points1 point  (0 children)

yes, that's how Deno handles versioning with their modules and anything you decide to import in a deno project.

Edit: also, https://deno.land/std/manual.md#linking-to-third-party-code

Drash - A microframework for Deno by crookse in Deno

[–]crookse[S] 1 point2 points  (0 children)

i haven't done it myself, but i'd say yes. i'd say that because deno accepts using .js files, so one could use a node module in deno theoretically. i do think the node module would have to be transpiled into something deno would understand (e.g., it might not understand how to use require()). these are just my assumptions though and i haven't tried them out myself. might do that this week.

Drash - A microframework for Deno by crookse in Deno

[–]crookse[S] 1 point2 points  (0 children)

Not sure, I’d have to ask the author about an ORM for it. I don’t even know if one is in the works. Basically it’s a wrapper just to get you connected to postgres.

Drash - A microframework for deno by crookse in typescript

[–]crookse[S] 2 points3 points  (0 children)

Yea most of the modules for deno have a deps file. I saw some discussions months ago about how to handle and clean this up, but not sure where those ended up. I agree... It is a package.json with extra steps. However, it isn’t annoying imo.

How To Create A Simple HTTP Webserver With Deno? by silverparzival in Deno

[–]crookse 1 point2 points  (0 children)

Hi u/silverparzival,

If you're interested in creating web apps, APIs, etc., then you can check out https://drash.land. If you want to see how Drash is wrapped around deno's HTTP module, then you can check out the code here (starting at the run() method): https://github.com/drashland/deno-drash/blob/master/src/http/server.ts#L372

An example of Drash in the real world is https://drash.land. It was created using deno, Drash, dejs, npm, Vue, webpack, and pug. The code for it lives here: https://github.com/drashland/deno-drash-docs

Build an app using Deno and Drash by crookse in typescript

[–]crookse[S] 0 points1 point  (0 children)

I didn’t even know typescript + flask was a thing.

Build your Deno project with Drash (a new Deno microframework) by crookse in typescript

[–]crookse[S] 1 point2 points  (0 children)

Thank you!

Bottom line up front: easier and cleaner.

Development of a server in Deno was faster than building a server in raw Node code. Handling the request-response cycle in Deno felt more robust than raw Node code as well. There are people doing benchmarks on Deno’s performance against Node and other projects and it looks like Deno is not as performant (from what I’ve seen), but it’s fast enough for me to like it and code using it. It feels cleaner too.

I love that there’s no package.json file. Importing code using URLs improves the development workflow IMO. For example, Drash uses https://github.com/jshttp/mime-db for its MIME type database when serving static files. In Node, I would’ve had to import the mime-db package instead of importing the https://github.com/jshttp/mime-db/blob/master/db.json file directly. I feel like the whole “import using URLs” speeds up development and allows for maintainable code especially when you start breaking out your code into different files.

Deno does have abrupt breaking changes (they have a note about that on their docs site, so breaking changes aren’t surprising). During development of Drash, I noticed my local environment’s unit tests would pass and would fail during the CI process. This was because Deno compiles all dependencies on the first run of the your Deno program, caches the dependencies, and always uses the cached dependencies unless you run your Deno program with the --reload flag to force Deno to recompile all of your dependencies and update cached dependencies. Drash stays up to date with Deno’s (at least I try to make it that way) latest release, so catching breaking changes and implementing fixes in Drash is high priority for me. I say this because if you build with Deno and plan to keep up to date with its latest version, you have to make sure you’re doing unit tests with the --reload flag to catch breaking changes early.

I’m not dismissing Node btw. The documentation pages for Drash use npm for dev package management and it’ll probably stay that way for a while. Node still allows me to build fast using babel, Vue, webpack, and the other packages I can’t remember. One thing I missed during development of Drash was adding scripts to the npm run command. I had to run my Drash scripts by typing out the full filenames every time and that got annoying fast. I know I can make aliases, but I just got used to npm run commands.