78 ms·

Fresh – Next-gen web framework

• Existenceblinks 4y ago
  I heard the word "hydration" so many times, I sort of get it, but always have question mark in mind that what's different between hydration and jquery approach?
  • kilburn 4y ago
    Hydration only makes sense when you have a vdom that you have to "synchronize" with the initial state of the page (the html you got from the server). The act of performing this synchronization is what hydration is about (notice that this includes setting up event handlers too). What you do here is to reconcile the in-memory representation (vdom) with the actual contents of the page (the dom). In the jquery aprroach the in-memory model is built straight from what's on the page (the dom). This removes an entire class of problems (there's no mis-synchronization possible) but has its own set of issues (the model you build may not end up being what you expected while coding). More importantly, "hydration" use implies that the HTML that gets sent to the client is a Server-Side Rendered version generated from the same JS code that runs in the page. The very big advantage here is that there's a single place where the page's content is controlled from (the js/jsx/whatever code) instead of having to manually maintain the html/js relationship by hand like in the jquery case. Furthermore, the jquery approach is global in nature (you can manually scope jquery-fiddling, but if you make a mistake you may end up modifying stuff elsewhere on the page) whereas this cannot happen in the vdom approach. In general, the vdom approach makes code more manageable at the cost of runtime performance. That's why many people recommend react and/or other vdom-based frameworks for the complicated cases (lots of dynamic stuff on the page) but vanilla/jquery/etc. when the in-page interactivity is lower. Today's crop of "frontend frameworks" (such as nextjs, fresh here, etc.) are trying to achieve the benefits of the vdom approach while minimizing its' drawbacks (and full-page hydration is a big drawback because it takes "a lot" of time decreasing the page's Time-To-Interactive metric).
    • Existenceblinks 4y ago
      So it's the same approach to generating html, except the part that belongs to client side (event/ui-state) is irrelevant to backend _anyway_. If you separate javascript code into 2 main parts, 1) what's only related to generating html 2) what's only related to DOM API, you get jQuery approach where on the back end javascript is just yet another backend language?
      • kilburn 4y ago
        > If you separate javascript code into 2 main parts The point is that you don't do this. You do: const App = () => { // Client-side counter const [count, setCount] = useState(0); useEffect(() => { setTimeout( () => {setCount(count+1)}, 1000 ); }, [count, setCount]); // HTML-rendering part return ( <div>Count: {count}</div> ); } The framework (next, fresh, whatever) grabs this and generates: - Some sort of "bundle.js" that contains the component (as well as the framework to render it). - An "index.html" that contains "<div>Count: 0</div>" (and references the above bundle). - When the "bundle.js" is loaded, it runs the App component in the browser and reconciles the in-memory vdom with the browser's dom (that has the div because it came in the .html) - From then on, the component runs normally (i.e.: the counter keeps increasing and you see it increase on the screen). In vanilla-land, you would: - Write "<div>Count: <span id="count">0</span></div>" in an index.html that also loads a "counter.js" - Write the counter.js file with something like: document.addEventListener('ready', () => { const count = document.getElementById('count'); let value = 0; setInterval(() => { count.innerText = value++; }, 1000); }); Less code, you don't need frameworks, hydration nor anything similar and it's probably much more performant. However: - If you want to change the counter's initial value, you have to update both the html and the js file - If another dev adds some element with id="count" to the html the whole thing breaks. - If you want to modify the generated html structure, you have to edit both the html and js file - When the logic gets more complex, you will have to implement it both in your backend-code-that-generates the html as well as in the js That is, even though it doesn't seem like it in a simple example such as this one, the developer ergonomics of having a vdom are much better when things get hairy. The million dollar question then becomes "how can we achieve a performance and code-size similar to the vanilla approach while keeping the ergonomics of the vdom".
  • rglover 4y ago
    With jQuery, your rendering is 100% dynamic, meaning, you load your JS on the client/browser and when that code executes, it fetches some data and "injects" it into the DOM (technically a form of hydration). Hydration in context here means taking some HTML that was server-side rendered with JavaScript and then, in the browser, handing off subsequent rendering (in response to user interaction) to JavaScript running on the client. Think of it like those little dinosaur sponge toys that would inflate when you poured water on them. The dry sponge is your server-side rendered HTML and the interactive JavaScript is the water being poured on it.
    • Existenceblinks 4y ago
      If you `s/Hydration/jQuery/` on your hydration description, I find it's still true.
• GirishSharma643 4y ago
  Total non sense for a new user because so called documentation is very vague and no step wise step configuration nor how to use this "wonderful" thing.
• GirishSharma643 4y ago
  Never use unmature technologies. They just lead to frustration.
• GirishSharma643 4y ago
  Why my comments removed?
• cloud_herder 4y ago
  Add it to the pile. It looks nice and clean but am I crazy in that FE is so fractured now? How can a developer choose the right direction/framework to focus on?
• sandGorgon 4y ago
  is fresh dependent on deno ? can it also be run on vanilla node?
  • norman784 4y ago
    I wouldn't run on node, deno loads the dependencies from a url directly (no need to install that) a convention is to use a `deps.ts`[0] file. Also with node you will need quite a setup to run this project (if it could run), you will need ts-node, webpack or similar, etc, while deno comes with all that tooling included by default. [0] https://github.com/lucacasonato/fresh/blob/main/src/server/deps.ts https://github.com/lucacasonato/fresh/blob/main/src/server/d...
• edmcnulty101 4y ago
  What is hydrating the client?
  • cguess 4y ago
    It's filling in the initial data in a front end app after the logic is sent and built up on the client side.
  • deleted 4y ago
    [deleted]
  • munchenphile 4y ago
    > Island based client hydration for maximum interactivity. This honestly reads like satire. It sounds like something on the sarcastic VanillaJS homepage. This gibberish being the second bullet point in a list of core features is a huge turn off. I know it’s tongue in cheek, but still
    • smoochy 4y ago
      People downvoted you, but I completely agree. It looks like this is NOT satire, but I hope you turn out to be right. Maybe someone has some sense of humor and enough time on their hands left to pull such stunt.
      • 0des 4y ago
        My bet is on someone forget to take it out of the template when the rest of the copy was added, and it will be gone in a few days with a realistic list item there. I think it's mostly like a tongue in cheek acknowledgement of how everyone in big techs is fighting so hard for a promotion that they aggressively brand the heck out of every library, exploit, and "new tech" they scheme up, even if the thing they're mentioning is using weird language for a concept that isn't new.
    • Spivak 4y ago
      It’s actually not gibberish. * Island refers to this https://jasonformat.com/islands-architecture/ https://jasonformat.com/islands-architecture/ * Island based hydration is a form of partial hydration where the boundary is the component islands.
• rgbrgb 4y ago
  Looks nice. A lot of ideas shared with remix but native to deno. Will def check it out when it’s production ready. Also, beautifully juicy hero animation.
• pcj-github 4y ago
  Excited about this! Docs should include obvious link to github repo: https://github.com/lucacasonato/fresh https://github.com/lucacasonato/fresh (edit: it's already in the footer) Also, deno/x needs an update: https://deno.land/x/deno_fresh https://deno.land/x/deno_fresh
• niix 4y ago
  Ryan Dahl is at it again?
  • Petersipoi 4y ago
    From what I can tell, Ryan Dahl doesn't have anything to do with this (other than it using Deno). At the very least, he isn't a contributer to the Repo.
    • 0des 4y ago
      Deno is repeating a lot of the same things from node, but its in typescript now, and there's some rust involved, so that makes it good. Wait till you're this deep into your career and people are still hammering square pegs into the same well worn circle holes and you'll be the same way.
      • Petersipoi 4y ago
        Did you respond to the wrong comment? I don't see any path from what I said that leads to what you said.
        • 0des 4y ago
          • Petersipoi 4y ago
            Gotcha. So you did respond to the wrong comment. Thanks for clarifying. edit: 0des edited his previous comment to be much less hostile after I wrote this one (without indicating he did so), and then told me to "settle down sport" now that my comment seems a little aggressive. Really bad etiquette.
            • deleted 4y ago
              [deleted]
            • 4y ago
• lmiller1990 4y ago
  I don't fully understand the difference between this (and something like Remix, which seems similar) and other frameworks like Next.js (React) and Nuxt.js (Vue). Can someone explain a bit about the differences, and pros/cons to each?
  • tunesmith 4y ago
    Deno vs Node appears to be one of them.
    • lmiller1990 4y ago
      Sure - this seems to be an implementation detail, though - eg, Remix and Next.js are both on Node.js but seem to have some difference that's not abstracted away, in terms of how you develop, how concerns are separated, etc.
      • norman784 4y ago
        I would say that deno vs node is the biggest difference, with node you need to setup and maintain 3rd party tools (bundlers, transpilers, etc) but with deno all that tooling is first party, so in theory is less things to install and worry about. Deno has other advantages in paper, like official ts support, all the tooling was written in rust (so it's more performant that the default ones that the others use). The only downside right now with deno is popularity and maturity of the ecosystem, it is just too new, so you will have hard time finding what you are looking for that works out of the box, while a lot of companies invested in node official packages.
      • chrisweekly 4y ago
        Remix is not "on node", it can target other runtimes including Deno and Cloudflare Workers.
  • damowangcy 4y ago
    The end result might be same but all of these frameworks/library/tools have some tricks up their sleeves that makes things easier for developers to implement certain functionality. The major difference with Fresh is that it runs everything just-in-time when it is needed, hence doesn't require building no shipping anything by default to the client(but you can still ship some JS for client side interactivity). The key here is no building (packing, bundling, transpiling). This don't just save time but actually removes the complexity as what you see is what you get. The only things that ships to users visiting your site is around 0-3kb (plus client side JS you decided to ship), not prebundled transpiled polyfilled prebuild 10mb JavaScript. Since it is Server Side Rendering, the performance is based on design decision.
• halfmatthalfcat 4y ago
  Why use '$' as the package namespace prefix/identifier instead of the already agreed upon convention of '@'? E.g. '@fresh/{package}' vs '$fresh/{package}'. Seems like a departure from the norm for no reason unless there's some Deno particularity about it.
  • 0x6c6f6c 4y ago
    Because the '@' convention is for organizations, not the actual package, e.g. '@company/pkg'. In this case, '$fresh' is the actual package, and there is no organization name. This just may be the Deno standard for their import mapping functionality since they also do full URLs for imports like Go (sans schema) normally. Deno is also just not exactly like JS ecosystems, and that's exactly the point too. Opinionated defaults, out-of-the-box support for TypeScript, death to NPM.
  • tbeseda 4y ago
    I think the convention of `~somepackage` is more common than using `@` as a shortcut.
• burlesona 4y ago
  • lpghatguy 4y ago
    This is needlessly condescending.
    • smoochy 4y ago
      It is true though. These were exactly my thoughts when I was reading the page. Well, not exactly, because I instead said "Duh".
  • jchw 4y ago
    That’s because it’s literally, not conventional templates. It is, from what I gather, Preact components, which can be rendered on the server and client isomorphically. The same component code runs on both sides. That’s not templates.
    • jhgb 4y ago
      > which can be rendered on the server and client isomorphically. The same component code runs on both sides. You mean portably. If the same code runs in multiple environments, it's running portably.
      • jchw 4y ago
        Isomorphic is the accepted term for this pattern. https://en.wikipedia.org/wiki/Isomorphic_JavaScript https://en.wikipedia.org/wiki/Isomorphic_JavaScript
        • jhgb 4y ago
          That is a weird term for two reasons. First, isomorphism is an invertible structure-preserving mapping between two structures. While the trivial case of that mapping being an identity is technically also isomorphism, it renders the relationship between the two structures (here code bases for different environments) into an identity as well. At that point the multiple code bases you're talking about are identical, not just isomorphic. It's like calling humans "vertebrates". While technically correct, if you're talking for example about the consequences of wars, do you talk about the loss of human lives, or the loss of vertebrate lives? I imagine it's not the latter. And second of course, "portable code" had been the accepted term for this "pattern" (if you can even call it this way) for decades already. I'm not quite sure why one would feel the need to randomly rename things that have already had perfectly functional names.
• solardev 4y ago
  Ooh, some competition for Next.js? Vercel is doing a really good job with Next, but it's good to see some competition. Of course, that means there's now 65,535 + 1 more way of serving a web page using Javascript (sigh). Rehydration is a really big deal. Sounds dorky but it dramatically speeds up load times and such by serving flat HTML and injecting JS afterward, like the old days, except you can write code like it's not the old days.
  • steve_adams_86 4y ago
    Have you seen Remix yet? It’s pretty compelling in terms of competition for Next.JS. It makes different trade offs and isn’t strictly better by every metric, but overall I’m very happy with it for the two use cases I’ve tried it with. It’s a very low overhead framework once the simple conventions click. I’d still like to check this out, then redwood and a couple others too. I’m not huge on these frameworks in general, but they tend to have some excellent ideas and smart people behind them, so plenty to learn by experimenting with them.
    • solardev 4y ago
      I've heard really good things about Remix, especially the nested routes. But I think Next is trying to copy that in Layouts? https://nextjs.org/blog/layouts-rfc https://nextjs.org/blog/layouts-rfc I use Next not just for the routing and composition and hydration, but for all the other quality-of-life improvements (image resizing, buildchain configs, hot reload), especially when it's paired with Vercel (per-push sandbox builds, stale-while-revalidate, seamless CDN, access to serverless, etc.) I'm really excited to see how Remix and other Next competitors evolve, but for now, I think it's still the most "full" stack of the React frameworks? Is that correct?
      • ttty 4y ago
        Image resizing can’t be done statically. That’s a big issue if you want to serve things from cdn property.
      • steve_adams_86 4y ago
• xrd 4y ago
  Very similar to sveltekit as well. I hope in the future you can swap out the preact for svelte. The deno runtime is very interesting. Most intriguing: no build step. That's a big difference from sveltekit which takes very readable input files and produces hardly readable files.
  • oreilles 4y ago
    Other than helping creating websites, this has almost nothing to do with SvelteKit. SvelteKit: - Requires configuration and build - Doesn't support partial hydration - Ship JS to the client by default - Can also be used as static site generator or SPA framework (no server side code)
• datalopers 4y ago
  • quickthrower2 4y ago
    Early PHP and Ruby frameworks don't provide anything to help you write client side interactive code, so you are on your own there, and you have to bring your own tools to do this.
    • swatcoder 4y ago
      Yeah, I remember how I used to have my users manually dll inject a plugin into Internet Explorer so I could make the buttons go brrr. I always wished there was something convenient, like an html tag that made it easier to add interactivity, but I never found it. I can’t believe we got anything done back in those days.
      • 0des 4y ago
        Take me down with the ship too, this cracked me up.
    • deleted 4y ago
      [deleted]
  • wonderbore 4y ago
    Did Ruby run on CDNs? Didn’t think so. That’s what “on the edge” means.
    • swatcoder 4y ago
      Well, we didn’t have CDN’s, but we did have geolocated servers. And yeah, we’d run Ruby on ‘em sometimes.
  • deleted 4y ago
    [deleted]
  • jchw 4y ago
• quickthrower2 4y ago
  Hmm. I don't see enough of an advantage over Next.js to make the leap, but good to see some innovation in this area.
• deleted 4y ago
  [deleted]
• jollybean 4y ago
  "Island based client hydration" Is this ling that I'm missing? Or a lark?
  • wonderbore 4y ago
    Replace island with widget. It means each part can render/rehydrate independently, I suppose
    • steve_taylor 4y ago
      You can do this with multiple React roots on the page. It’s been done by many websites for years.
  • lucacasonato 4y ago
    https://jasonformat.com/islands-architecture/ https://jasonformat.com/islands-architecture/
    • jollybean 4y ago
      Thanks that's it. I'm just balking a bit with the word 'hydration' entering into some kind of normative lexicon. I think there is probably a better word for that.
• jjdeveloper 4y ago
  This feels exactly the same as Astro SSR (which I’ve been using recently and is great by the way). I guess this validates their direction. Happy to see more frameworks like this.
• 0des 4y ago
  • jchw 4y ago
    Even if you wanna be cynical, this is a really boring and overplayed take in my opinion. Most frameworks are indeed kind of bloated for running useless hello world demos. Most C compilers give you some kilobytes of code that isn’t necessary for hello world either, even worse for other respected and modern languages like Rust and Go. It can be forgiven if you consider that most of these things are not tuned for optimal hello world.
    • jonobird1 4y ago
      This comment is the overplayed take that because a lot are heavy frameworks, that this should be acceptable. As soon as something is classified as a framework, it seems ok to be >200kb. If you take Tailwind CSS for example, when correctly using their CLI tool, it only includes the size of the css classes actually used, keeping it to a minimum, when compared to people just doing a standard import of the entire library. I like this mentality because it's offering the ability to be very lightweight, or as large as the 'framework' it offers. NextJS offers this as part of their build process, but not sure how big their assets are with it for a simple usecase.
      • jchw 4y ago
        The word framework doesn't really actually mean anything. People have a feel for it, but there is no concrete "this is a framework, not a library." However, I think that for most people, the criteria isn't actually related to how large the software is, but rather the feeling of using it. When you use a non-framework library, it feels like using a wrench or a drill; it's a tool. When you use a framework, it feels like you're writing code inside it, not using it. Frameworks can be small. The term "microframework" exists for this exact reason. Semantics aside, the existence of things with different philosophies doesn't immediately invalidate everything that doesn't give you the same tradeoffs. For one thing, Tailwind deals with declarative CSS output, not imperative modular code. I'm not saying that makes it stupid or anything, but it's very apples and oranges. There are very few JS libraries or frameworks that can offer starting-from-zero KiB JS; maybe Svelte comes close? Ironically, if we're talking about client side bundles, it seems as though Fresh actually does start with 0 KiB, as it does not default to shipping JS code to the client at all. This doesn't feel like a rational discussion at all. It feels like it's just necessary to come up with a cynical take because there's a new JavaScript thing. In a few weeks there could be some Rust FRP webassembly UI thing that has a 1.2 MiB hello world and hardly anyone will care.
• ejanus 4y ago
  How widely use is deno?
  • dgb23 4y ago
    It’s something to keep an eye on. There’s companies that bet on deno/deno-like runtimes. It’s a move to having more options/control on sandboxing/embedding JS on server runtimes. Think of how Lua is used. Heavy lifting in a compiled language with Lua on top to cover app specific logic. Node is in a sense that, but with a stronger emphasis on being a general purpose runtime for JS. Deno (and similar), gives you more options for embedding and restricting the JS side. I think it’s worth keeping an eye on, because I think the JS world is soon in an refinement/optimization phase. It’s settling and stabilizing towards a set of core ideas and Deno might be part of that.
• nXqd 4y ago
  is react component compatible with fresh which is the most important thing isn't it?
• gavinray 4y ago
  > "The framework uses Preact and JSX for rendering and templating on both the server and the client." Really nice to see Preact used here, it's a much more rational choice than React if you were planning on using React anyways. I set Next.js up to use Preact as the engine but it takes a bit of config work to do this and isn't an officially/OOTB supported feature.
  • ZeWaka 4y ago
    If you're into React but faster, there's InfernoJS, which is basically React/Preact but /even faster/: https://www.infernojs.org/ https://www.infernojs.org/
    • adamredwoods 4y ago
      Then there's solid js: https://www.solidjs.com/ https://www.solidjs.com/
    • no_wizard 4y ago
      no hooks yet though, which limits compatibility and arguably developer experience. Preact has better compatibility - if that's something you're looking for anyway. I suspect that was part of the motivation as well. Also, Preact is 3KB full, inferno is 7.2 KB, if I recall correctly, may have also been a motivation here.
• rubenfiszel 4y ago
  I both love it and hate it. Most of the features are similar to sveltekit/next.js. I get that the biggest benefit is the deno deploy integration for ssr on the edge. But I would have highly preferred a new flavor of sveltekit where deno deploy is a build adapter (like cloudflare workers currently are) and the script part of svelte could be set as "ts-deno". No need to reinvent the wheel yet again and split the ecosystem more.
  • deleted 4y ago
    [deleted]
  • christophilus 4y ago
    It uses Preact, just in time bundling, and a number of other concepts that would probably be a pain to integrate seamlessly into those. Seems like a justifiable from scratch prototype.
• gavinray 4y ago
  On the part about adding interactivity: > "To include this in a page component, one can just use the component normally. Fresh will take care of automatically mounting the island component on the client with the correct props:" How does a developer know what rendering is going to take place client-side vs server-side, and is there any way to control this? Or is it all fully "magical"
  • gigatexal 4y ago
    Yeah this seems like a pain. I don’t like magic. Magic is hard to debug.
    • lucacasonato 4y ago
      It's not magic. There is an `islands/` folder that you must place all of your client components in. 1 component per file. See https://fresh.deno.dev/docs/getting-started/adding-interactivity https://fresh.deno.dev/docs/getting-started/adding-interacti...
  • norman784 4y ago
    If I understood correctly, it all renders server side and then adds the interactivity where it's necessary, and in a react app is kinda easy to spot which components are interactive or not, the biggest difference here, vs a traditional react framework, is that fresh is more similar to astro[0] than next.js/remix, so it ships less js. What I read from other comments is that fresh does code splitting, so for example if the interactivity is out of your viewport and you scroll down to that element, it will then load the js required to make it interactive, while I find that idea cool, what worries my is that it could take a few ms to load the js and then other few ms to boot that component and render it interactive. But I don't have experience with any of the frameworks (besides next.js where I build a small demo project to try it out). [0] https://astro.build https://astro.build
  • justshowpost 4y ago
    Well, you know by seeing that the component is located in the special `islands` folder.
• francis-li 4y ago
  Ryan Dahl talks a bit about it in this talk at Remix Conf 2022: https://www.youtube.com/watch?v=4_nxvVTNY9s&t=10781s https://www.youtube.com/watch?v=4_nxvVTNY9s&t=10781s He describes it as a post-Unix web framework (i.e. built on serverless primitives like cloudflare workers/deno deploy) with the goal of <10s deployment (which he says requires JIT compilation on first-request)
  • 3np 4y ago
    So my reading of that is that Fresh as it stands now is more of a demo and challenge to the Remix community to step up.
    • bartlomieju 4y ago
      Not really, Fresh already powers several websites https://deno.land/ https://deno.land/, so it definitely has production use.
      • throwingrocks 4y ago
        Ryan Dahl described it that way. He said it’s not something they’re really promoting or planning to utilize long term.
        • lewisflude 4y ago
          Is there a chance he pitched it this way to manage expectations / because he was pitching this at Remix Conf and didn’t want to upset the hosts?
  • deleted 4y ago
    [deleted]
  • AtNightWeCode 4y ago
    He really is the JS server-side sect leader. Plain wrong about so many things you lost count while he talks. Glad that the JS community, not that I am fan, left this dude behind.
• PontifexMinimus 4y ago
  From https://fresh.deno.dev/docs/getting-started/create-a-route https://fresh.deno.dev/docs/getting-started/create-a-route : > Routes are defined as files in the routes directory. [...] If the file name is contact.js and is placed inside of the routes/about/ folder, the route will handle requests to /about/contact. I can't say I'm particularly keen on being told what directory to put files in, or or being told that I must only code exactly one endpoint in each file. Why aren't I allowed to code multiple endpoints (e.g. for related functionality) in the same file? Also, in what directory do I put my files if the url is of the form /user/{username}/page/{pagename} ?
  • davidjohnstone 4y ago
    You put square brackets around parameters. e.g., routes/greet/[name].tsx https://fresh.deno.dev/docs/getting-started/dynamic-routes https://fresh.deno.dev/docs/getting-started/dynamic-routes
    • 3np 4y ago
      To add on this: Looks like you can do that for directories as well. Here's how it works: https://github.com/lucacasonato/fresh/blob/4bb07f4bcebfc205692e53bb61a1e2447d589c8e/src/server/context.ts#L640 https://github.com/lucacasonato/fresh/blob/4bb07f4bcebfc2056... So the example above could be: user/[username]/page/[pagename].ts
      • PontifexMinimus 4y ago
        Hmmm. I suspect there is some software out there that doesn't like directory names with square brackets in them.
  • okhobb 4y ago
    This is the same thing I dislike about NextJS. What is the argument for using the filesystem as part of a framework's API?
    • 4y ago
• xavdid 4y ago
  > fresh also does not have a build step. The code you write is also directly the code that is run on the server, and the code that is executed on the client. Any necessary transpilation of TypeScript or JSX to plain JavaScript is done on the fly, just when it is needed I find this very interesting. I get that adding a build step can be a pain during development / deployment, but running your TS build once per deploy seems _much_ more efficient than doing it repeatedly, as needed. Or does it get cached , so it's built at-most-once? I haven't really dug in.
  • colordrops 4y ago
    Even if it isn't caching, it could be added with a service worker.
    • lewisl9029 4y ago
      I explored using client-side service workers for build-less deployment workflows a while back, but the blocker was the initial visit when the service worker hasn't been installed yet. Ended up using es-module-shim's fetch hook (https://github.com/guybedford/es-module-shims#fetch-hook https://github.com/guybedford/es-module-shims#fetch-hook) instead, which worked quite well. I kept the demo repo around here, in case it's helpful to anyone: https://github.com/lewisl9029/buildless-hot-reload-demo https://github.com/lewisl9029/buildless-hot-reload-demo. The repo itself is quite out of date at this point, but my current project, Reflame, is essentially the spiritual successor: https://reflame.app/ https://reflame.app/ Reflame has the same ideals of achieving the developer experience I've always wanted for building client rendered React apps: - instant production deployments (usually <200ms) - instant preview environments that match production in pretty much every imaginable way (including the URL so we don't have to worry about special whitelisting for CORS and whatnot), that can also be flipped into development mode for fast-refresh (for the seamless feedback loop we're used to in local dev) and dev-mode dependencies (for better error messaging, etc) - close-to-instant browser tests (1-3 seconds) that enable image snapshot comparisons that run with maximum parallelism, and only rerun when their dependency graphs change, and auto flake detection/recovery
  • eyelidlessness 4y ago
• MarquesMa 4y ago
  Why this can be great: - The dev experience is closer to the early days of PHP. - TypeScript, Preact out of the box. No need to configure build tools / deploys much faster. It's a pain in the ass to make these working at the same time and targeting both browser and server nowadays. - You can have interactivity without bolt-on client-side scripts that are different from other parts. - The code could be running on the edges. - I'm not sure what does the island based client hydration means, but sounds like Remix Many other frameworks could do some of them but not all (Ruby needs JavaScript/Turbolink, Next.js need to build then refresh, etc)
  • toddmorey 4y ago
    Frameworks like Next or Nuxt often render each page server-side, shipping HTML to the client, but then also send enough javascript and json data to the client to "hydrate" the page back into fully interactive components. The whole site, then, really acts as one large javascript app once fully loaded. The islands approach is different: pages are server rendered, but you can easily define islands of interactivity (like, say, an auto-complete search bar) where just enough javascript is sent to make those components interactive—and only when it's needed. You can control at what point exactly each component is made interactive: as the page loads, when the component becomes visible, when the user first interacts, etc. It's a great way to balance performance and rich interactivity. If the user never scrolls down to your photo carousel at the bottom of the page, the javascript is never requested. If this sounds like what we used to do with say PHP & JQuery, you're not wrong. The difference here is we have the same javascript-based template logic and component model both clientside and serverside. Some other projects adopting the islands pattern: https://iles.pages.dev https://iles.pages.dev - https://astro.build https://astro.build - https://slinkity.dev https://slinkity.dev More reading: https://jasonformat.com/islands-architecture/ https://jasonformat.com/islands-architecture/
    • jjdeveloper 4y ago
      The main dev on Slinkity has moved onto Astro. Just an fyi and yes Astro fan here. Mental model feels very productive.
    • 4y ago
• blunderkid 4y ago
  Fresh looks inspired by Remix. Is that right? Not that there is anything wrong with that. But given that Remix does claim to be production ready, what makes Fresh better? I have been playing with Remix in a side project. I do like their simplicity vis-a-vis Nextjs. And the fact that it is all server rendered by design and not as a special case.
  • norman784 4y ago
    I don't think that fresh is better or worse, besides being pretty early in development, is somehow different and it doesn't run in node.js, but in deno.
• hsn915 4y ago
  I thought by now enough people have framework fatigue that no one bothers with yet another way to develop a website. Is there a reason someone like me should care? Does it improve anything by atleast an order of magnitude?
  • nstart 4y ago
    I think the reason to be interested in this is because it’s deno specific. I’m not up to date with the deno landscape but I believe this is pretty novel for deno.
  • eyelidlessness 4y ago
    > Island based client hydration for maximum interactivity. > Zero runtime overhead: no JS is shipped to the client by default. Translation: the UX most people on HN complaining about JS want. It’s just the interactive parts, none of the treating a web page like it’s an app, but devs familiar with developing sites that way can use it that way without jamming MBs of JS down users’ browsers.
  • darepublic 4y ago
    to me it seems to be promising a more substantial improvement than most frameworks + the deno factor definitely makes it stand out. minimum js needed for interactivity being sent to the client is much better than what we do currently
  • deleted 4y ago
    [deleted]
• qbasic_forever 4y ago
  I love that the pendulum is swinging back to file-based routing. It reminds me a lot of the simplicity of cgi and php scripts. I'm sure there's a point where it explodes into a monster of complexity with enormous sites, but for everything smaller it's so much simpler and easier.
  • zelphirkalt 4y ago
    Next (no pun intended) thing we will rediscover is using templating engines (only in JS or so), because we realize, that mixing state and behavior is a problem. Then we will have gone full circle, but probably with some unreasonable overhead as a result. Maybe the whole thing of rendering templates will somehow become a part of webpack and everyone will have to configure webpack. Good that classic web frameworks are still around and healthy, which have been rendering templates on the server side for a decade or so.
    • DylanSp 4y ago
      Part of why I like React (especially with Typescript) is basically that I like JSX/TSX as a templating language. I much prefer working in a full language (with JSX as relatively light syntactic sugar on top) that can leverage existing tooling and typechecking, instead of a de novo template language with its own syntax for control flow constructs jammed in, that doesn't usually have great editor support or typechecking for integrating with the rest of the server-side code. Of course, using React has all the issues of SPAs, and trying to use something like Next seems somewhat fiddly due to keeping client-side and server-side state in sync and managing hydration. I'm entirely in favor of a framework that allows writing a server-rendered app with a decent templating language (and ideally a good path for writing client-side interactivity if I need it); it looks like Fresh might do that. I'd love to hear about other frameworks (JS/TS or otherwise, though I definitely prefer statically-typed languages) that match up with what I want, though.
      • qudat 4y ago
        > that can leverage existing tooling and typechecking, instead of a de novo template language with its own syntax for control flow constructs jammed in, that doesn't usually have great editor support or typechecking for integrating with the rest of the server-side code. This is exactly what I find frustrating about go templating. I lose autocomplete and type hints.
• davidravid 4y ago
  it looks amazing solution, how much it cost?
  • lucacasonato 4y ago
    It's open source, and runnable on any server that you can run Deno on (so any reasonably modern Linux, macOS, or Windows) system. You can also host it on our managed edge runtime offering, Deno Deploy.
• manigandham 4y ago
  Fresh = Deno version of Astro (static-first with SSR) and Isle (vue-focused) and bigger Next.js/Nuxt SSR (with no client js) modes. Remix also does well here with a focus on only SSR. It's basically what the original "isomorphic" javascript promise was to have the same code seamlessly running on server and client with a flexible split on what part ran where, now possible down to an individual tag/component. Also worth mentioning projects like .NET Blazor, Phoenix Liveview and Rails Hotwire that approach client interactivity through their own backend languages instead of JS, usually with some partial refresh mechanism using AJAX or websockets.
  • btbuildem 4y ago
    Does that mean JS running server-side? That's a full-stop dealbreaker for me.
    • ezrast 4y ago
      Deno is a JS runtime like Node, so if that's not your thing then yeah, this isn't for you.
      • baobabKoodaa 4y ago
        Many Node-based JS frameworks, such as Gatsby or Next, allow SSG that can be distributed by a CDN. Your comment is weird.
        • pier25 4y ago
          Dynamic responses also can be cached in a CDN you know...
          • baobabKoodaa 4y ago
            The whole point of static site generation is that you don't have to manage servers; that you can instead simply generate your assets and distribute them via CDN. Sure you can manage servers and put a CDN in front of your servers, but then you still have to manage those servers... Anyway, you're missing the crux of my point. I was criticizing GP for implying that all NodeJS-based frameworks require a dynamic server to run respond to queries at runtime. They don't.
• zzmp 4y ago
  Have other frameworks had the concept of ["interactive islands"]? I'd love to know more, but the docs aren't fleshed out yet. Does anyone know of other (documented) frameworks that use this concept? ["interactive islands"]: https://fresh.deno.dev/docs/concepts/islands https://fresh.deno.dev/docs/concepts/islands
  • camillovisini 4y ago
    See astro: https://docs.astro.build/en/core-concepts/partial-hydration/#islands-architecture https://docs.astro.build/en/core-concepts/partial-hydration/...
• vsroy 4y ago
  Does Remix also not only ship JS for the interactive bits? I.e, you send over some HTML & then hydrate it with Javascript, right?
  • zelphirkalt 4y ago
    If so, how does it play out in practice? Do people really make most things in a way that does not require hydration, or do they make simple text and forms a hydrated thing, that does not work without JS?
• asadlionpk 4y ago
  Does anyone know what software can be used to design the juicy hero animation seen here?
  • hackererror404 4y ago
    It's an SVG animation. There are a number of programs that can be used to create such an animation. I use Flow, pretty simple to use and it's included with setapp (an app subscription platform on mac). https://createwithflow.com/ https://createwithflow.com/ You can also check out svgator, it's an online based solution. https://www.svgator.com/ https://www.svgator.com/ Cheers!
    • hackerlytest 4y ago
      Thanks
    • asadlionpk 4y ago
      These are great, thanks!
• peter_retief 4y ago
  How does this compare to vuejs? Why is it better than existing platforms (nuxt) Really keen to know, not trying to be negative, not sure this is even the right place to ask.
• seydor 4y ago
  A JS framework, not a web framework
  • christophilus 4y ago
    It’s a JS web framework. It does pretty much what your average web framework does, except adds in first class interactivity, and drops an opinionated ORM layer. I personally really like this balance, and will kick the tires when it’s not experimental.
    • shafyy 4y ago
      Does anybody know if the goal is to become a more opiniated framework with an ORM layer and MVC structure etc.?
• nathias 4y ago
  Finally things are happening again on frontend stack.
• chrischen 4y ago
  React has server components coming out that will also be zero-runtime with only JS hydration for interactive parts. https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html https://reactjs.org/blog/2020/12/21/data-fetching-with-react... This will be great for mostly static pages.
• kuon 4y ago
  I suggest you take a look to Phoenix Live View, it's like that (very little client side JS) with the added benefits of the BEAM. You can serve thousands if not million of simultaneous clients with a small machine.
• oblak 4y ago
  Reading some of the more eager comments, I think it needs to be said I don't always my application indexed, so having an actual SPA makes a ton of sense. What good is any of this when your session is in the browser and all you can manage is serve the login page "very fast".
• amitshekhar 4y ago
• adesanmi 4y ago
  Everything I see around deno makes me really excited. I really have to rewrite one of my pet Typescript apps in it.
• sriku 4y ago
  Slowly getting somewhat cynical. This is the only space where both "prebuilds everything and therefore saves rendering time and improves caching" and "no build step and so speeds up deployment" are both considered valid feature pitches.
  • norman784 4y ago
    To me it reads more focused on developers than users of the site you build. I like that in the last couple of years the developer experience was improved in some ways, this kind of apps that you could develop "easily" as monolithic could be served in a serverless hosting as a microservice (if I understood correctly how serverless works) serving each endpoint as a separate service, everything without you as dev put too much effort into it.
    • deleted 4y ago
      [deleted]
  • madeofpalk 4y ago
    Why does that make you cynical? They're two different spins on how to render content. They both have pros and cons. It's good to know this and make an informed decision about which strategy you take.
  • marcosdumay 4y ago
    On the last decade and half the entire group mind of the computing discipline switched from "no build step will speed-up development and deployment" into "a heavy build step will speed-up development and deployment". So, it's not like the web developers were going at it alone. Anyway, the change happened because of real environmental changes. Developers everywhere didn't just wake-up and decide their old values were the exact opposite of the truth, both opinions stand on valid models of the world and hard-acquired empirical information.
  • qudat 4y ago
    > Slowly getting somewhat cynical Are you equally cynical about the hundreds (thousands?) of different ways to setup and deploy infrastructure (all with different pros/cons)? FE is timid compared to devops churn.
• frou_dh 4y ago
  This obviously has some level of Deno officialness. But from looking at the TODO-ridden state of the docs, it doesn't seem like it's ready for its '#1 on HN' public launch moment.
  • tqkxzugoaupvwqr 4y ago
    It has nothing to do with the official Deno project except for being hosted on Deno Deploy which gives you a <projectname>.deno.dev domain. I find deno.dev misleading in the sense that it gives any random project instant credibility. [1] https://deno.com/deploy/docs/projects https://deno.com/deploy/docs/projects
    • frou_dh 4y ago
      Thank you. I actually realised/remembered about the domain and already edited my comment. But the author of the project is a Deno employee.
    • cal85 4y ago
      I totally assumed it was an official Deno launch until I read your comment. I think it's the combination of the domain and the Deno mascot that makes it misleading. EDIT: oh, if it's made by a Deno employee that changes it.
    • mi_lk 4y ago
      the repo is under a Deno core team member tho. https://github.com/lucacasonato/fresh https://github.com/lucacasonato/fresh
• AtNightWeCode 4y ago
  How do you get the content from the headless CMS into the static sites if there is no build step?
• jokoon 4y ago
  > Island based client hydration Software development already has its own vocabulary, but I feel quite ignorant now.
  • keyle 4y ago
    It only makes sense to the con artist that put it on their resume first. Let me try: Hair dry volcano hydration off the cliff only, no added sugar.
  • chrischen 4y ago
    Knowing what it is now, describing it that way makes total sense... but it only works for people after knowing what it is... kind of like an inside joke. For anyone wondering what it means: it ships only the JS for select components (usually ones that have some sort of client-side interactivity, such as the incrementing counter on their demo page), so it only has to hydrate that part (where hydration is reconciling the client bundle execution result with what is actually on the page). This is opposed to the standard way React works which is the entire JS used to render the page—even the static non-interactive bits like plain HTML—is shipped to the client and all your function component functions are run (just without the actual inserting DOM elements again if SSR is used). React is currently developing server rendered components that works with streaming SSR introduced in React 18 that delivers this same functionality. Basically your app can then be composed of server components and client components (essentially what all current react components are), and only the JS for client components is actually sent to the browser and hydrated.
    • vosper 4y ago
      > React is currently developing server rendered components that works with streaming SSR introduced in React 18 that delivers this same functionality. Basically your app can then be composed of server components and client components (essentially what all current react components are), and only the JS for client components is actually sent to the browser and hydrated. Isn’t the difference here that with React Server Components you’re still fully rendering client-side, but you can ship the data alongside the JS? Whereas with Astro / islands of inactivity / partial hydration you ship actual HTML and then after it renders you make interactive (hydrate) only the relevant parts?
• ultim8k 4y ago
  That animation stole my heart
• divan 4y ago
  That's funny how many smart people understand that web is a giant pile of hacks on top of hacks, and how incredibly important web for modern apps distribution (I bet you buy tickets, pay invoices, do you medical check ins etc on web apps), and yet leaders of this ecosystem do not even ask the question whether foundation of web (html/css/js) is even a good solution. Instead they create new hacks. Island based client hydration, right.
• eternityforest 4y ago
  Seems really fast loading, and easy to use for devs. Pretty nice!
• amadeuspagel 4y ago
  > The framework uses Preact and JSX for rendering and templating on both the server and the client. Why not tagged template literals, like Worker Tools[1] and lit[2]? [1]: https://workers.tools/html/ https://workers.tools/html/ [2]: https://lit.dev/ https://lit.dev/
• bushidowarrior 4y ago
  Here are some of my thoughts: It is using silly naming conventions in filenames as an alternative to specifying routes. eg /users/[name].tsx for /users/:name It uses a manifest file. I remember when entity framework in C# had a separate file that represented the mappings of the database. The problem is the database and the manifest would get out of sync. I imagine the same thing would happen here. There is no documentation about the islands or how they are implemented. It uses JSX, which I don't think is even very nice. It seems a lot of this "going back to server-side" is due to the slow and bulky nature of loading react on page load, but libraries built on top of native web components alleviate this issue to some extent. For many people, farming the rendering off to clients is faster if they don't have enough server capacity. After the first page load, client-side is faster. I am not sure how many people benefit from going back to server-side. I do think initial page load is very important though. It says there is no build step but there has to be one because v8 runs JavaScript not TypeScript. The documentation for "swc" compares it to babel...
  • dbbk 4y ago
    The naming convention is no different to Next.js, arguably the most popular frontend framework currently
  • crowlKats 4y ago
    > It is using silly naming conventions in filenames as an alternative to specifying routes. eg /users/[name].tsx for /users/:name Its a convention also used by Next.js, so it is just sticking to existing conventions. > There is no documentation about the islands or how they are implemented. Documentation is still only partial & incomplete. > It says there is no build step but there has to be one because v8 runs JavaScript not TypeScript This is a module for Deno, which does that under the hood, it isnt something a deno user would have to be concerned with.
• bartq 4y ago
  1. With this approach of sending "only the small JS chunk needed for interactivity" aren't we going to end up with the situation where chunks A and B need common part C? And what if C needs D etc. There should be provided a dynamic modules loader. Is it implemented in all those hydration based frameworks? 2. How is solved the situation when <button> is delivered to the user, but "onClick" action is not because network failed?
  • lucacasonato 4y ago
    > Is it implemented in all those hydration based frameworks? I can't speak for all frameworks, but fresh can dynamically break out shared dependencies so you don't have to download the same code twice. > How is solved the situation when <button> is delivered to the user, but "onClick" action is not because network failed? Developers need to deal with this in their applications. The counter example on the fresh homepage uses <button disabled> for the server side render, and only enables the button in the client side when the counter island hydrates.
    • NetOpWibby 4y ago
      Ooh, I like that.
• shafyy 4y ago
  God, the landig page animation with the lemon is delightful!
• benevol 4y ago
  Where does Fresh perform better than Rails?
• macinjosh 4y ago
  I've been doing all of this with PHP and a little JS for decades. But sure, next gen.. - Just-in-time rendering on the edge. - Island based client hydration for maximum interactivity. - Zero runtime overhead: no JS is shipped to the client by default. - No build step. - No configuration necessary.
• TeeWEE 4y ago
  Server side rendering and pushing HTML to the client?
  • lucacasonato 4y ago
    Yes
• EGreg 4y ago
  The counter below was rendered on the server with a starting value of 3, and was then hydrated on the client to provide interactivity. Try out the buttons! Ooh. We have supported this as a feature in the Qbix Platform since 2014: https://qbix.com/platform/guide/tools https://qbix.com/platform/guide/tools Back then, it was called “progressive enhancement” (anyone remember it?) before they moved to “graceful degradation” where JS was assumed always on (like broadband internet became assumed always on, instead of previous generation stuff like IRC that expected netsplits, now everyone just had SAAS on The Web with online/offline status). What we always advocated for is to build client-first software that works with JS, but then spend time to make versions that render on the server and work without it. In that order. Flips “progressive enhancement” on its head: https://qbix.com/blog/2020/01/02/the-case-for-building-client-first-web-apps/ https://qbix.com/blog/2020/01/02/the-case-for-building-clien... I gave a talk on this when I worked at Lab49, it might be more interesting in video form: https://youtube.com/watch?v=yKPKuH6YCTc https://youtube.com/watch?v=yKPKuH6YCTc
• WuxiFingerHold 4y ago
  The next-gen SPA frameworks/libs like SolidJS or Svelte are already very fast and more importantly very small in bundle size. At least much faster and smaller than React or Angular. Therefore the advantages of SSR frameworks like this new one are much smaller when compared to e.g. SolidJS. The performance claims made for this new framework need to be proven by benchmarks. Check out this SolidJS Hackernews clone (Client Side Rendered) https://hackernews-csr.ryansolid.workers.dev https://hackernews-csr.ryansolid.workers.dev (by the way, there're other implementations like Remix or Svelte as well) IMO very hard to beat. For larger apps we can use component based code splitting. The new SSR frameworks are very complex. So there's a downside to it. Of course there's a big market for the cloud providers as you need to run and pay for a server for your SSR instead of simply serving static JS! That's why there's such a hype lately. I'm not convinced that the performance gains are worth the complexity, costs or vendor lock in. Again, check out the SolidJS example app I've linked above and measure for yourself if you really need the additional cost and complexity of a server pre-rendering, hydrating, etc..
  • totallymike 4y ago
    This feels like a strange argument to make when server-rendered HTML has been the norm for decades, and it's only been recently that SPAs have become popular.
    • WuxiFingerHold 4y ago
      It may feel strange, but as Javascript has become very, very fast in the last decade and the new SPA frameworks are highly optimised, I'm not surprised by the performance of SolidJS. Obviously for dynamic content. That's by the way the reason I was asking for benchmarks. The new kind of SSR frameworks are by the way much more complex than the older template based server-rendered HTML.
  • psadri 4y ago
    The problem is accessing backend data sources. Fetching that data in the first request and responding with server side rendered html > serve js that then initiates network calls to get that data (while showing a spinner in the ui)
• XCSme 4y ago
  This looks good and has potential and all, but do we really need so many new web frameworks? Is all this effort spent on slightly improving the current tooling really worth? I think the web frameworks have had enough incremental changes, we should either stick to improving the current frameworks or creating ones that bring revolutionary, not incremental, changes.
  • jstummbillig 4y ago
    Why not both? Certainly everyone who creates a (somewhat serious) web framework is at least aware that they could also participate in the development of an existing on. If they feel there is something to gain by going from scratch, why not? I don't think the popular existing frameworks exactly suffer from under-contribution.
    • porcc 4y ago
      The incentives here seem strongly skewed towards having your name on a new framework for career purposes rather than improving the ecosystem at large
      • jstummbillig 4y ago
        That seems wrong, intuitively. If anything, having meaningful contributions to a long standing project go through should relatively advance your cause, not hinder it.
        • porcc 4y ago
          Intuitively maybe. In practice definitely not. Creator of xxx with 100 stars has obvious and easily understood impact where "contributor" could mean anything
    • XCSme 4y ago
      > Why not both? My point was that it's fine if someone starts working on a new framework, but personally I would rather have all that effort be used for developing services or tools that are actually needed and do bring value to the community. EDIT: To make it more clear, the issue is when the creators of such frameworks do believe they are going to change the world by recreating in a slightly different way something that already exists. If they are doing this for fun or to get experience, it's all good, but very often those frameworks do seem to have the ambition of becoming the next big thing and revolutionizing the way people are developing web apps.
• rglover 4y ago
  If you need something a bit less esoteric and want a traditional, straightforward approach to building web apps with JavaScript: https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick. Add an Express route -> tell it to render a component/HTML via a res.render() function -> it auto-hydrates everything on the client for you. Components are written in plain HTML, CSS, and JavaScript (no JSX or other funky syntax) with a quick-to-grok API. No new concepts to learn and keeps you as close to the core technology (HTML, CSS, and JavaScript) as possible.
• avinassh 4y ago
  Is it official deno project? The github repo isn't on deno's organisation. or is it like anyone can host anything on deno.dev, similar to js.org?
  • crowlKats 4y ago
    a deno.dev subdomain is provided to all deno deploy projects (https://deno.com/deploy https://deno.com/deploy)
  • lucacasonato 4y ago
    The project will migrate to the denoland org soon.
• digitalsanctum 4y ago
  Am I the only one that sees the "do not use in production" warning as a challenge? ;)
• justcodin 4y ago
  Deno was always cool. It seems like a revolution in webdev is happening above our noses.
• dixego 4y ago
  Sometimes I wonder how much time humanity as a species has collectively spent first inventing and then trying to solve the problem of "making a website".
  • jaapz 4y ago
    The funny thing to me is that "we" went from server-rendering to client-rendering to server-rendering again.
  • ratww 4y ago
    If it weren't websites it would have been native apps. Microsoft alone has made more proprietary native app frameworks for Windows in the last 15 than hipster Javascript developers had to learn new frameworks for work.
  • simultsop 4y ago
    Until technology becomes transparent on our interaction with reality xD
  • sangnoir 4y ago
    Far less than humanity has spent on "convince people to buy product X" when X has many alternatives that are perfectly serviceable...or even superior.
• simultsop 4y ago
  Wish we could have just skip the hard part of transitioning to the future. At least next generations will start write JS/TS on both ends (front/back) and hopefully maintain seamlessly the state, benefit the server side and benefit on the front. Writing in same language and sharing the logic around. Sometimes it is a nightmare switching between languages python/php/go/anything else and then js for full-stacks.
  • paradite 4y ago
    The future is the past - Meteor.js.
  • jokethrowaway 4y ago
    Hopefully we'll be able to use a language that is more advanced than TS on both frontend and backend one day
    • crowdhailer 4y ago
      Probably something like Gleam lang. That full stack has felt like tasting the future
  • sam0x17 4y ago
    In particular, can we skip to the part that involves no js :)
• brundolf 4y ago
  The most exciting thing for me here is that it uses Deno. Deno's ecosystem has been its biggest weakness so far (understandable, compared with the vibrancy of Node's), so it's exciting to see it progress
• niutech 4y ago
  There is a 6-KB 0-build-step web framework Petite Vue by Evan You: https://github.com/vuejs/petite-vue https://github.com/vuejs/petite-vue. How is Fresh better that this?
  • tomovo 4y ago
    Because it is newer. Obviously.
    • niutech 4y ago
      Petite Vue is less than one year old.
• holysantamaria 4y ago
  Why am I not surprised. Yet another javascript framework... I'm tired
  • NeutralForest 4y ago
    The ever crushing wheel of time seems to repeat itself in many cases: wars, text editors and web frameworks.
  • karpovv-boris 4y ago
    Is it your job to testing every new js framework, didn't think so. Then this "new framework" situation is just funny.
• epalm 4y ago
  A bit off topic here, but can anyone identify which documentation tool this is? https://fresh.deno.dev/docs/getting-started/adding-interactivity https://fresh.deno.dev/docs/getting-started/adding-interacti... It's very clean and simple, I like it.
  • kube-system 4y ago
    Looks like they're doing it bespoke: https://github.com/lucacasonato/fresh/pull/108/files#diff-274d31bdd12bc7026d804b5ac3248767a879ee1290ca7bd57dddc502b0ab3e60 https://github.com/lucacasonato/fresh/pull/108/files#diff-27... Although the way it's implemented seems similar to mkdocs.
• pacifika 4y ago
  I tried six pages of getting started and still didn’t see a code snippet so I guess it’s still wip
• DrFell 4y ago
  These JS/TS full-stack frameworks need to be banned right along with fruit-flavored vapes. Think of the children.
• yencabulator 4y ago
  "No build step" is a weird pitch when what actually happens is that, in production, they'll fetch a WASM module on the fly to do bundling at request time. That build step was there to avoid doing this work over and over! https://github.com/lucacasonato/fresh/blob/458fe2ca3c12508a60cb304bd0f17e1087f553f1/src/server/bundle.ts#L33-L99 https://github.com/lucacasonato/fresh/blob/458fe2ca3c12508a6... https://github.com/lucacasonato/fresh/blob/458fe2ca3c12508a60cb304bd0f17e1087f553f1/src/server/bundle.ts#L10 https://github.com/lucacasonato/fresh/blob/458fe2ca3c12508a6...
  • meowtimemania 4y ago
    I thought this too. Isn’t it a better user experience if the bundling happens ahead of time rather than at request time?
    • hunterb123 4y ago
      I'm not familiar with their implementation, but it could be that the bundling is only a temporary solution for browsers that don't support import maps. Or a light layer on top of it. Import maps are pretty cool, you don't need to bundle in modern browsers and it plays to http2's parallel request strengths.
  • pier25 4y ago
    Maybe it has a cache and this only happens the first time? It would be a bit ridiculous to re-compile JSX into JS on every request.
    • yencabulator 4y ago
      I didn't say every request. It'll still happen on every cold serverless request, every first request to every scale-up VM, ...
    • lucacasonato 4y ago
      Yeah, it doesn't do this. The transpiled output is cached indefinitely for a given deployment.
• pier25 4y ago
  Did they copy the React API or the client side stuff is a wrapper on top of React? https://fresh.deno.dev/docs/getting-started/adding-interactivity https://fresh.deno.dev/docs/getting-started/adding-interacti... It looks identical to React.
  • radicalriddler 4y ago
    > The framework uses Preact and JSX for rendering and templating on both the server and the client. On https://fresh.deno.dev/docs/introduction https://fresh.deno.dev/docs/introduction
    • pier25 4y ago
      Thanks I missed that!