Out of curiosity: does the support for automatic JSX incur any startup or deployment penalty? I'd assumed Deno didn't have a "build step" per se, but maybe I'm mistaken.
https://github.com/denoland/fresh/blob/main/www/routes/docs/...
Using MDX is a little trickier as the .mdx file needs to be compiled to a javascript file which is then interpretted. When running Deno yourself this isn't hard as you can use a dynamic import, but if you're planning on using Deno Deploy you'll be out of luck as it doesn't support dynamic imports currently.
https://github.com/denoland/fresh/issues/640
Deno Deploy has an open issue asking for support if you want to give it a star. ;)
https://github.com/denoland/deploy_feedback/issues/1
As a workaround, you can always setup a watcher and preprocess MDX files before deploying to Deno Deploy, but that seems against the spirit of what Fresh is trying to accomplish by getting rid of preprocessors.
Let me know if you figure out a way to get MDX on Deno Deploy working without precompile as I'd like to use it myself!
Was Twind chosen to stay true to the "no build step" idea?
The only thing I'm missing to try it out is some sort of SASS support.
Not sure what you mean about an ORM. Next doesn’t have one either! These frameworks are agnostic about what happens inside your server-side GET and POST handlers — if you want to call an ORM-like library like Prisma from there, you can.
Fresh and deno are the embodiment of: ergonimic, performant, secure — pick three.
thank you (and all the contributors) for your work :)
Shameless-self promotion: I've been working on a similar web framework built on Deno and Cloudflare Workers. It's called Keywork[1] and it's made for folks who would like to create web apps for the V8 runtime, without getting too attached to a single cloud provider.
Keywork has powered all my projects as of recently, but Fresh looks like a serious contender. I would love to chat with the Deno team if they're floating around this HN thread! You're creating amazing stuff!
- [1] https://keywork.app
:)
Off-topic but how does the video[2] under Preact Dev Tools look so sharp yet only weight 43KB? Edit: nevermind, the downloaded file's 2.9MB. Must be something up with Chrome's network tab.
[1]: https://deno.com/blog/v1.25#new-experimental-http-server-api
Just use --unstable to enable it.
I forgot to add this to the post initially. Have retroactively added it now :)
deno run -A -r https://fresh.deno.dev my-project
Sending fatal alert BadCertificate error: error sending request for url (https://fresh.deno.dev/): error trying to connect: invalid peer certificate contents: invalid peer certificate: UnknownIssuer
---
https://deno.com/blog/v1.13#use-system-certificate-store-for...
- there's a bunch of mildly annoying paper cuts due to not running the full set of npm/JavaScript (yet?). I had to Google for and debug deno specific versions of libraries I wanted to use. Felt similar to trying to write Web Worker subset JS for Cloudflare Workers. Hope this improves. Though being able to address packages at import location by URL was neat.
- Deno Deploy was outrageously fast at deploying. It made updating the live site a joy compared to other FaaS stuff I've used
- I liked that I could process multiple domains on the same project (I was able to make 3 sites https://thisclowndoesnotexist.com https://thisbernerdoesnotexist.com and https://thisghostdoesnotexist.com live with their own domains within 5 mins or so each which was neat). Their https certificate tool was sometimes being rate limited so required a couple retries
- the deno runtime itself is fast as heck. I know bun goes even further but dang, stuff installs and executes so quickly it feels broken at first
- the Deno Deploy edge is quite fast, and there seems to be no major cold start issues. See https://bench.t3.gg/ for some comparisons (I found it fun use `fly curl` to test global response times)
I love the idea of eliminating lots of build boilerplate but I do ultimately want to output static assets for a read-only webpage.
For ahead of time static sites in Deno, check out Packup https://packup.deno.dev/
Thanks!
One could argue the adoption of JSX actually allows for better seperation and cleaner code as you can group all the necessary pieces of your component together, and use components declaratively without introducing some DSL seen in some frameworks like Vue, Angular etc.
Vue's concepts in the v-* are more pleasant than the React way, imho. Learning a bit of DAL is not a blocker for me, given how many tools already require this
Alternatively, try organising your cutlery by "implement" and "handle". Surely, separating what goes in your mouth from what your grubby hands touch is the right thing to do. The two concerns that should be kept separate!
To push this analogy over the edge, the former is how I see JSX. And my admittedly facetious proposal is how I view the "classical" approach of strict HTML|CSS|JS separation.
Which poses the question: after seven+ years of JSX and it having become the most prominent approach to building UIs, can the "classical"way even be called that anymore?
You can just use the std lib to loop, filter, reduce, conditionally render, etc. rather than looking up how to loop in this specific framework with v-if, v-for, etc.
Angular 1 did that and it was limiting. Two-way data binding also failed.
Templates are dead, long live JSX.
Are you more likely to use it knowing that?
And no I'm not interested in Vue due to many reasons. I can expand if you're interested.
But why would you switch to copy cat frameworks when you have React and React Native?
My main point was for JS DSL and against proprietary template syntax, what are your thoughts on that specifically?
I don’t agree with your point about copy cat frameworks generally, as we’ve reached the point where all the major players are adapting each other’s ideas constantly. I think any of the modern JS frameworks are more than capable of handling any use case.