RDF, Typescript and Deno - Part 3b
One of my all-time favourite programming languages is Prolog. In Prolog terms, my investigation of RDF, Typescript and Deno has reached this step:
!,
fail.
“Cut, fail” indicates to the Prolog interpreter to stop exploring this branch of the evaluation tree, and go back to a previous choice point to try a different path. It won’t cause the program to halt altogether (unless the program has run out of choices to make), but will make it back up to a previously non-cut choice point.
So to make this relevant to the topic at hand (finally!): I’m giving
up on Deno as vehicle for exploring the JavaScript rdflib package.
Deno is, for certain purposes, great. rdflib is, for certain purposes,
great. They just don’t play nice together.
Some of the issues I ran into included:
-
rdflib uses
importstatements that import relative modules. I actually asked about this on StackOverflow. Deno likes fully-qualified module specifiers. Tbh, I don’t fully understand the details of the explanation, but suffice to say that I couldn’t get the suggested fix to work. -
importing types with the
@deno-types="..."annotation I also couldn’t get to work, so VsCode wasn’t able to typecheck my Typescript code. This even though rdflib has.tssource files -
some rdflib imports use Node packages that Deno doesn’t support yet, including
https.
What I did like
There are definitely things to like about Deno. It’s fast. It’s nicely
optimised for running small scripts effectively: I would imagine that
it’s a perfect vehicle for AWS Lambda functions, for example. When the
type checking is working (see above), it works well in VsCode. It’s nice
not having to start a project with a load of package.json wrangling.
The security model is a good idea in principle, although I’d anticipate
adding --allow-read, --allow-net, etc, as reflexes without properly
thinking about it. The weakest part of any security protocol is the
humans!
For all of the good things above, I think (extrapolating from just one data point: always a dubious idea!) that Deno isn’t going to be a good choice for large NPM modules or libraries that were written firmly during a “pick any runtime engine you like, as long as it’s Node” era. Which means waiting for libraries to get updated or rewritten, or taken on writing that functionality yourself. For something big and hairy like RDF (and SPARQL, and JSON-LD, and etc etc) that’s a deal-breaker for most teams and non-superhuman individuals.
What next
To ponder. I still have a desire to write an rdflib tutorial, because
there aren’t many good ones around. On the other hand, I’m not that
into writing in Node Express. Previous to this experiment with Deno,
my tools-of-choice for writing the server-side element of an app were
Ruby-on-Rails or Python Flask.
All-in-all, I’m glad I tried the experiment. And I might come back to Deno in future, to see if the integration with larger NPM modules has changed significantly.
I am not done with Deno (see what I did there? :))