[HN Gopher] Fresh 1.1 - Automatic JSX, plugins, DevTools, and more
___________________________________________________________________
Fresh 1.1 - Automatic JSX, plugins, DevTools, and more
Author : gripfx
Score : 163 points
Date : 2022-09-08 13:28 UTC (9 hours ago)
(HTM) web link (deno.com)
(TXT) w3m dump (deno.com)
| Waterluvian wrote:
| 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.
| rough-sea wrote:
| 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/
| Waterluvian wrote:
| Ahhh gotcha. So unlikely to be a good fit for my needs.
|
| Thanks!
| pier25 wrote:
| AFAIK the static content is cached somehow with Fresh/Deno.
| It's not compiled on every request.
| robofanatic wrote:
| 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
| lucacasonato wrote:
| Are you behind a corporate firewall? Can you set
| `DENO_TLS_CA_STORE=system` and try again?
| verdverm wrote:
| Is deno using a custom cert store by default?
|
| ---
|
| https://deno.com/blog/v1.13#use-system-certificate-store-
| for...
| lucacasonato wrote:
| It uses the Mozilla certificate store by default.
| robofanatic wrote:
| yes and thanks so much. that did the trick!
| obviyus wrote:
| 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
| rough-sea wrote:
| https://deno.com/blog/fresh-1.1#experimental-denoserve-suppo...
|
| Just use --unstable to enable it.
| lucacasonato wrote:
| 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 :)
| MarkBennett wrote:
| 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.
| gibbonsrcool wrote:
| 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.
| :)
| lucacasonato wrote:
| Thanks for the kind words!
| hazn wrote:
| 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 :)
| [deleted]
| winrid wrote:
| 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?
| brundolf wrote:
| Anybody here used Fresh for a non-toy project yet? Have anecdotal
| experiences to share?
| bcjordan wrote:
| 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)
| TeffenEllis wrote:
| 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
| AbraKdabra wrote:
| 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.
| n3pg wrote:
| 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.
| verdverm wrote:
| 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
| hunterb123 wrote:
| 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.
| jakelazaroff wrote:
| 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...
| AgentME wrote:
| 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.
| qbasic_forever wrote:
| 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.
| gherkinnn wrote:
| Separating which concerns?
| richeyryan wrote:
| I guess software is like your cutlery drawer. You want to
| keep your knives, forks and spoons separate.
| gherkinnn wrote:
| 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?
| rglover wrote:
| There's hope: https://github.com/cheatcode/joystick.
| root_axis wrote:
| 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.
| redonkulus wrote:
| Is it easy to support other CSS frameworks? I haven't checked the
| docs yet.
| lucacasonato wrote:
| Hey folks, author of Fresh here. Very excited for this rather
| significant release. Happy to answer any questions you may have
| :)
| jplhomer wrote:
| 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.
| lucacasonato wrote:
| 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.
| teebot wrote:
| 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?
| cercatrova wrote:
| 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.
| MarkBennett wrote:
| 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!
| gherkinnn wrote:
| Solid release! It fixes most of the rough edges I encountered.
|
| Was Twind chosen to stay true to the "no build step" idea?
| lucacasonato wrote:
| Indeed it was :)
| pier25 wrote:
| Fresh is looking awesome Luca!
|
| The only thing I'm missing to try it out is some sort of SASS
| support.
| lucacasonato wrote:
| This is actually something I am planning a plugin for, just
| like we have for Twind.
| dmix wrote:
| How big is the "team" working on Fresh? Is there a primary
| product which it spawned off of (the demo website?)?
| lucacasonato wrote:
| 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 :)
___________________________________________________________________
(page generated 2022-09-08 23:01 UTC)