My experience with the Deno/Fresh ecosystem

7/11/2023, 7:50:19 AM

First of all, I want to preface this blog post by saying that I LOVE the developer experience of working with Deno and I have no intention to going back to Node. While the good parts section might be smaller than the bad parts section, I'm 100% aware that there are only two types of languages.

The good parts

You might read this post and think that I hate Deno, but it's actually quite the opposite, I LOVE using Deno since I've first start using it. These are the best parts of using Deno daily:

Built-in linter
Built-in formatter
Built-in testing suite
No typescript configuration needed
No build step
How all of the above helps me focusing on writing code
How all of the above makes different code bases have a similar development workflow
Deploys/Previews/Hosting on Deno Deploy
Very supportive community

The ability to write typescript with zero configuration, the internal tooling (linting, formatting, etc), Deno Deploy providing such an amazing experience all around, projects/packages/modules all using the same configuration... there is just so much to love here.

There is nothing like being able to contribute to different projects and not needing to setup your IDE, not needing to learn another test runner. You just clone the repo, run the command to run on --watch mode and you are good to go.

The community support is unmatched. I never had a question that went unanswered. The community is very welcoming to new members. Community support is especially important because we all gather on the same single Discord server, unlike Node where developers are spread out everywhere. That being said...

The bad parts

I've had a ton of issues when I started out building this website and I would like to go over them now to better align people expectations on what they should expect if they also want to dip into using Deno on a weekly basis:

Third party packages are abandoned/outdated
Few community resources to start projects
No easy syntax highlighting on demand
Twind v0 in Fresh

Abandoned packages

I'll say it before you feel like you have to: this is not a problem exclusive to Deno. Neither to Javascript/Typescript. Trust me, I've been there before with Dart/Flutter as well, but it doesn't matter that this happens in other languages/runtimes, it sucks when it happens and it does happen a lot here.

The reason why I think that this is especially painful in Deno is because (and this is just me assuming with 0 evidence to back up this claim) that a lot of experienced developers jumped on the Deno hypetrain when it came out, assuming there would be a lot of room to foster business opportunities and create a supporting package for the new runtime that could eventually become backed by large companies. I mean, why wouldn't they, it was literally created by Ryan Dahl, the original creator of Node. If someone out there understands about writing Javascript runtimes, it is the guy who made three¹ of them.

Another thing that made a lot of developers abandon their Deno modules was the fact thatNPM packages are now supported in Deno by using the npm: specifier. Why would you create something like a driver for MongoDB if NPM support allows you to simply use Mongoose, which has a proven production track record and is maintained full time? It just doesn't make sense to do it, the potential return on investment just isn't there.

The issue here is that these experienced developers made packages are good enough to use (because they obviously know what they are doing), but still have a plethora of bugs that aren't being fixed since those packages did not evolve with the runtime, so you have to decide between:

Forking and maintaining your own personal version
Creating a new package to supersede this package

Don't get me wrong, I'm not here to point fingers or imply that these people are awful human beings. No one is forced to maintain OSS for free, but it does add a lot of technical overhead when you want to start a project and realize that you don't have those foundational building blocks readily available for you to use and jumpstart your creation, allowing you to focus on the core business logic of your project.

If I had to suggest how to fix this (and once again, I'm no expert in this field), I would suggest that the Deno team opened a submission form that allowed developers to request sponsorship to develop Deno-related packages. It doesn't need to be a ton of money, but $50 to $500 monthly (depending on package size/adoption) would do wonders to improve community support.

Lacking community resources

Being able to find tutorials to build basically anything is not something the average Node developer struggles with. Being 15 years old means that the ecosystem around it has matured enough that people have done dozens of tutorials on about basically everything at this point. This, however, is not the case for Deno. When trying to search for a resource with Deno, you will often find articles about Deno itself and not its modules. While I'm doing my part and also writing about it and making modules to be used in Deno, I'm only one man.

I feel like this block wouldn't make justice to the Deno community if it didn't also mention some very notable contributions like Craig's Deno Diary, Deno by Example and Jollytoad. I'm sure there are more people out there contributing to creating resources, I just didn't meet them yet. Kevin Whinnery has also been making livestreams on the Deno Discord Server every ~2 weeks and building stuff with Deno with the community and that's a very nice experience. You don't get to have a very experienced developer sharing their line of thought on how to build a product every day, it's a very enlightening experience.

I have recently had a conversation on Discord about the difficulty to find resources on Deno and the moderation joined the conversation. I ended up suggesting that we could maybe have a #resources channel to share blog posts and articles around Deno, so let's see how that's gonna develop over the coming weeks. Maybe having a centralized location to gather all resources on how to build software with Deno helps alleviating the difficulty of finding that content through Google.

Syntax Highlight

If you have already visited my tools page, you might be wondering why I've created a syntax highlighter. Well, this is the reason: There is no easy way to easily create highlighted JSX for Preact/React components. Deno offers some form of conversion from .md files to HTML, but that's not exactly helpful for this Fresh-based website. Not only I didn't need the HTML files, but I also needed that only a portion of the content was highlighted, not the whole thing.

I eventually gave up and resorted to using a syntax highlighting JS package that updates the page content after load, but that deviates from the intend of Fresh to ship as little Javascript to the client as possible, none at all if it can help it. The problem with this approach is that it caused Cumulative Layout Shift and a jarring experience whenever the script took considerable time to be fetched. Since the script requires the DOM to be loaded and ready, I had to defer the script so that it could manipulate the DOM. While this did work, it wasn't ideal.

I eventually pivoted from this approach and tried to find a way to render .md files programatically as JSX blocks and syntax highlighted them individually. Later I realized that this would also not be ideal, not only because I would be adding (or creating!) another dependency to my website, but it was also unnecessary overhead to parse those files and highlight them again and again on every render. Wouldn't be better if I could just convert a code block directly as JSX and use that on my code instead?

So that's why I've created Syntax Highlight and how I solved the problem, by creating a tool that creates the JSX for me that I can just copy and paste in my files. If it wasn't for the fact that I chose to add a theme switcher to this website, this page would be one of the many that ship 0 Javascript since I got rid of that requirement.

Twind (v0) in Fresh

Ok, so the choice to use Twind v0 slowed down significantly my development of this website. I have a lot to say on this topic, so it's probably better that I write an entire piece about it alone instead of shoving it here, which would honestly be as rich in words as this very post.

UPDATED August 1st, 2023: I've created said post, you can read it here or by clicking Next on the Navigation header at the top of the page.

For now, I'm only gonna mention that the Fresh, until this day (July 7th, 2023), uses an implementation of Twind v0, which is based on Tailwind v2 (superseded by v3 in December of 2021). If you are used to Tailwind v3 (which I had nearly 1 year of experience when I started this website), a lot of things don't exist in this version and a lot others are completely mismatched and will make you question how much you really know of Tailwind.

It's a very gaslighting experience to type out some class, have it not work and then wonder if you wrote it correctly or not. You inspect the element and see that the class wasn't attached, then you check tailwind documentation and see that the class exists as you tried to use it, then you eventually realize that the issue is that it exists in Tailwind v3, but not in v2. It's an experience that I don't wish upon anyone, really.

Conclusion

I want to iterate one more time that I LOVE working with Deno. The experience is unmatched and I'm in the process of porting all of my current projects to it and use it for all the future ones.

That might not make sense because this blog post is quite long and it mostly talks about the things I dislike, but I promise that it is still a net positive for my workflow. While annoying, none of those things mentioned managed to strangle how enjoyable it is to work with Deno.

Deno wasn't built in a day (in fact, it has recently turned 5 years old) and the Deno team is very hard-working. I wasn't there for the first 5 years of Node either, but I'm sure it faced from a myriad of issues as well, probably even more than Deno did because the team running Deno now is more experienced than the team that started Node 15 years ago. I don't know exactly where Deno is going to be in the next 5 years, but I'm buckled up and ready for the ride. Onto the 10th birthday! 🚀

1 Deno Deploy is the third runtime, if you are wondering.