Fresh 1.1 – Automatic JSX, plugins, DevTools, and more(deno.com)
deno.com
Fresh 1.1 – Automatic JSX, plugins, DevTools, and more
https://deno.com/blog/fresh-1.1
56 comments
Hey folks, author of Fresh here. Very excited for this rather significant release. Happy to answer any questions you may have :)
Terrific update! You resolved the only two pain points I'd experienced (`tw` template literal and JSX pragma stuff).
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.
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.
Nope, no startup penalty. It is just as performant as the classic JSX pragma. The actual JavaScript that is executed by the runtime is pretty much identical.
I really want to try fresh together with edgedb. Any chance a builtin authentication will be added soon? Or is there a recipe to implement something like auth0?
One of the next releases will improve the plugin API to the point where authentication providers can be very easily added as plugins.
How big is the “team” working on Fresh? Is there a primary product which it spawned off of (the demo website?)?
Yes, it was a tech demo for some internal projects. I maintain the framework itself, but a lot of the work in other parts of the Deno system (Deno Deploy, Deno CLI) that are related to Fresh are done by other folks on the team :)
I'd be interested to see a more built in solution for Markdown and MDX, as with Astro or NextJS, since I've been mainly using either for blog type websites and I'd love to use Fresh as well.
It's my understanding that GFM is already easy to do, in fact there's an example of using it with Fresh in the fresh repository as it's used for the docs!
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!
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!
Solid release! It fixes most of the rough edges I encountered.
Was Twind chosen to stay true to the "no build step" idea?
Was Twind chosen to stay true to the "no build step" idea?
Indeed it was :)
Fresh is looking awesome Luca!
The only thing I'm missing to try it out is some sort of SASS support.
The only thing I'm missing to try it out is some sort of SASS support.
This is actually something I am planning a plugin for, just like we have for Twind.
I've been writing a simple single page form app the past few days and I like Fresh a lot. I really appreciate the simplified project layout vs my last setup of a react app project nestled in a parent express project. It just makes the devops, if you would even called it that, of writing a one-person full stack app easier. Deno running TypeScript without a compile to JS adds to this. I'm happy to see the Preact Signals demo to help manage state between islands in 1.1. Thank you for this great framework. :)
How does it compare to using Next? Looking through the Fresh docs I don't see references to an ORM, mutations, etc. I'm probably missing or misunderstanding something.
Mutations: https://fresh.deno.dev/docs/getting-started/form-submissions
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.
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.
[deleted]
Thanks for the kind words!
this update fixed all the drawbacks I experienced while building my webpage: www.hazn.deno.dev
Fresh and deno are the embodiment of: ergonimic, performant, secure — pick three.
thank you (and all the contributors) for your work :)
Fresh and deno are the embodiment of: ergonimic, performant, secure — pick three.
thank you (and all the contributors) for your work :)
your webpage is down
Wow, great work! One question - isn't doing the tailwind processing on every page load pretty CPU intensive? Could you foresee opting-in to that as a build step in the future?
Fresh looks seriously cool! I'm especially fond of the plugins concept for bringing in compiled assets like Markdown and SCSS. And Getting started with a `deno run` command is very exciting for new-comers too!
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
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
> built on [...] Cloudflare Workers [...] without getting too attached to a single cloud provider
:)
:)
Great update! I wonder if Fresh plans to use Deno's (new) HTTP server[1]. Benchmarks for that look incredible (compared to Express).
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
[2]: https://deno.com/fresh-1.1/preact_devtools.mp4
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
[2]: https://deno.com/fresh-1.1/preact_devtools.mp4
https://deno.com/blog/fresh-1.1#experimental-denoserve-suppo...
Just use --unstable to enable it.
Just use --unstable to enable it.
You also need to pass a `experimentalDenoServe: true` option in the options bag passed to `start()` in your `main.ts` file.
I forgot to add this to the post initially. Have retroactively added it now :)
I forgot to add this to the post initially. Have retroactively added it now :)
Are there any benchmarks with the new server yet? Would be keen to see how it compares to the existing server as benchmarking on my machine showed a significant improvement over the existing http server in stdlib.
I just ran this and got a bad cert error. How should I fix it?
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
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
Are you behind a corporate firewall? Can you set `DENO_TLS_CA_STORE=system` and try again?
Is deno using a custom cert store by default?
---
https://deno.com/blog/v1.13#use-system-certificate-store-for...
---
https://deno.com/blog/v1.13#use-system-certificate-store-for...
It uses the Mozilla certificate store by default.
yes and thanks so much. that did the trick!
Anybody here used Fresh for a non-toy project yet? Have anecdotal experiences to share?
Not exactly what you're looking for but in case helpful, I used Fresh/Deno/Deno Deploy for a toy project & have some takeaways that might apply more broadly:
- 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)
- 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)
Is it easy to support other CSS frameworks? I haven’t checked the docs yet.
Is there a plan to allow Vue (and other frameworks) on Fresh? I'm also looking at Prisma+Deno issue for my dream stack.
Is Fresh primarily a server side rendering tool? Or might it be an option for static-ish webpages hosted by GitHub.io?
I love the idea of eliminating lots of build boilerplate but I do ultimately want to output static assets for a read-only webpage.
I love the idea of eliminating lots of build boilerplate but I do ultimately want to output static assets for a read-only webpage.
It’s a server-side framework that delivers static content - but the static content is rendered just in time rather than ahead of time.
For ahead of time static sites in Deno, check out Packup https://packup.deno.dev/
For ahead of time static sites in Deno, check out Packup https://packup.deno.dev/
AFAIK the static content is cached somehow with Fresh/Deno. It's not compiled on every request.
Ahhh gotcha. So unlikely to be a good fit for my needs.
Thanks!
Thanks!
I seriously cannot wrap around my head how in 2022 people really like JSX and all that X-in-JS crap, it's like people doesn't know about separation of concerns or clean code at all.
For almost anything more interactive than a static document, modularizing UI code primarily based on component boundaries makes a lot more sense than modularizing primarily based on markup / interactivity / styling boundaries.
Exactly, it comes from a bygone era when there was a clear separation between frontend developers (i.e. people that wrote markup, CSS, and jquery style JS) and backend developers (people that wrote PHP, ASP, java, etc. to spit out markup that frontend devs wrote). Nowadays everyone is basically full stack with specializations or focus in specific parts.
Seperation of languages != seperation of concerns
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.
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.
Isn't className custom DSL in React?
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
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
I'd rather just use JS syntax than learn a random v-* syntax.
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.
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.
Vue doesn’t do two way data binding.
Are you more likely to use it knowing that?
Are you more likely to use it knowing that?
The data binding was a comment for React and against Angular and similar frameworks. The template syntax was a comment against Vue.
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?
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 particularly care one way or the other. I like Vue because it offers flexibility and some opinions. If I want to write a jsx render function, I can do that. If I have a simple functional component for an icon or whatever, I can use the DSL and it’s statically compiled for the final build.
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.
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.
No, `className` is the DOM property exposed to JavaScript that corresponds to the `class` attribute in HTML: https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...
React JSX mostly uses JS DOM property naming (className, style, tabIndex) but converts a few HTML-style attributes (data-, aria-)
There are quite a few motivations for this, but the primary advantage is that it causes markup elements to become first-class entities within your code, allowing your view composition to be checked by the compiler as well as allowing you to design your own reusable markup elements that fold up application level concerns. It's also nice when your views have lexical access to your application state variables so you don't have to pre-render a big string template and interlace it with an explicit map of serialized parameters - it's very nice when the compiler lets you know a view simply cannot display the type of data you're trying to shove into it rather than rendering a broken looking page.
Separating which concerns?
I guess software is like your cutlery drawer. You want to keep your knives, forks and spoons separate.
True. I like keeping my knives, forks, and spoons separate.
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?
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?
There's hope: https://github.com/cheatcode/joystick.