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.
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?
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!
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.
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!
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.
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.
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!
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.
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.
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
- 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 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.
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
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.
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.
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.
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?
