Fresh is a new full stack web framework for Deno(deno.com)
deno.com
Fresh is a new full stack web framework for Deno
https://deno.com/blog/fresh-is-stable
248 comments
> For me "full stack" is something like Rails, Laravel, Django, etc.
Aren't those back-end frameworks? I always undestood full-stack to mean "front-end + back-end".
Aren't those back-end frameworks? I always undestood full-stack to mean "front-end + back-end".
At least for Django, it handles creating client side views, client routing, etc. You can of course use a different frontend, but that's included by default. See also its wonderful admin interface.
They're "full stack in the sense that you can render templates and manages static/media files. Back when we only had websites, this was fully full stack for sure.
Rails definitely has a front end, by default anyway.
I don't know about the others, but Rails has Hotwire and Phoenix has LiveView, which are both excellent frontend technologies.
I personally believe full-stack is fuzzy, because what if we also provided a UI layer, or a payment interface framework, or a notification handling system, or similar as part of the "full stack" system? It's hard to draw a line as to where something becomes "full stack."
However... it's definitely closer to what I want "full stack" to mean than... this. Or a pile of bash scripts.
However... it's definitely closer to what I want "full stack" to mean than... this. Or a pile of bash scripts.
well, I agree.... but to me the baseline is, as I said, Rails/Laravel/Django... there's a common subset of things you need in like 99% of web applications that are not just a rest API or a landing page.
> Or is it just being able to run code on the server enough to be "full stack"?
To me, "full stack" would entail having responsibility for logic on both the front-end and back-end, which Fresh does.
Personally, I would not consider Laravel a full stack framework (Although it can work well with front-end frameworks to make a full-stack application). Instead I'd consider it a back-end framework.
To me, "full stack" would entail having responsibility for logic on both the front-end and back-end, which Fresh does.
Personally, I would not consider Laravel a full stack framework (Although it can work well with front-end frameworks to make a full-stack application). Instead I'd consider it a back-end framework.
In the case of laravel, I think that having by default a pretty awesome templating system (which even allows for components), a webpack based build system for frontend assets, easy way to serve, cache and bust assets, and a trivially easy way to submit forms and validate user input makes it pretty full stack. Same for Rails, and not event talking about HotWire/LiveWire with might not be considered parts of the framework per se.
To me Laravels is pretty more close to a "full stack" framework than Fresh to be honest.
To me Laravels is pretty more close to a "full stack" framework than Fresh to be honest.
In today's world that's not frontend enough (as much as it pains me to say).
You need to ship at least a few MBs of JS to prove you are a real frontend engineer.
You need to ship at least a few MBs of JS to prove you are a real frontend engineer.
haha, lol... So I'm a top 1% dev then :). I have all the megabytes in my frontend.
Not here to defend Fresh, it has lot of flaws, but
> I think that having by default a pretty awesome templating system (which even allows for components), a webpack based build system for frontend assets
Fresh literally does that "by default" without having to include any library/dependency.
> easy way to serve, cache and bust assets, and a trivially easy way to submit forms and validate user input.
It's almost the same effort in Fresh.
> makes it pretty full stack
Define fullstack, but even defining it, Fresh totally covers what you said.
To be "fullstack" to me means to be filling in all stacks, being in web? Frontend and Backend. To me, having a templating system and having things rendered in backend can be "frontend", but you saying "Laravels is pretty more close to a fullstack framework than Fresh" is not something very logic here.
> I think that having by default a pretty awesome templating system (which even allows for components), a webpack based build system for frontend assets
Fresh literally does that "by default" without having to include any library/dependency.
> easy way to serve, cache and bust assets, and a trivially easy way to submit forms and validate user input.
It's almost the same effort in Fresh.
> makes it pretty full stack
Define fullstack, but even defining it, Fresh totally covers what you said.
To be "fullstack" to me means to be filling in all stacks, being in web? Frontend and Backend. To me, having a templating system and having things rendered in backend can be "frontend", but you saying "Laravels is pretty more close to a fullstack framework than Fresh" is not something very logic here.
Node/JS solutions typically don't come "batteries included." "Fullstack" means different things depending on the ecosystem and for Node devs it means "hey there's a solution for the front-end and back-end."
Totally understand about Django, Laravel etc. but typically if I'm building in Node/JS I'm pulling all of that extra stuff in from npm piecing it together myself.
Totally understand about Django, Laravel etc. but typically if I'm building in Node/JS I'm pulling all of that extra stuff in from npm piecing it together myself.
Yeah, I do the same. Most of what I do is Next.js + a good bunch of npm packages to get the "full stack". But I wouldn't call Next.js full stack because it can do SSR, or even API routes. But again, that's just me confused about what is "full stack".
Yeah - I really hate the term "full stack" as it can really mean vastly stuff in different contexts, between different companies, hell - even in leading teams I feel like I have to nail down what "full stack" means between the members.
> But again, that's just me confused about what is "full stack"
Me too because it's grown into an amorphous definition =/
> But again, that's just me confused about what is "full stack"
Me too because it's grown into an amorphous definition =/
> But again, that's just me confused about what is "full stack".
There term has definitely become more amorphous and ambiguous. I spent a few years mostly working with physical hardware, networking, virtualization, scripting deploys for DBs and OSs, and handling the DNS alongside some business oriented C#. Then I moved over to working with AWS and Azure.
Now I primarily work with Node, Golang and Python.
With modern tooling and a team that supports it, I've found myself mostly working on services, APIs and React front-ends. Even with Next.js, it's hard to know where the line on what "full stack" is.
It's sort of come to encompass the frontend and backend of an application, less so the architecture of it. Mentally, however, I still lump it all together when I think of what qualifies for "full stack", as I personally think the term represents an understanding of how everything works together, which definitely helps when troubleshooting the source of a problem.
There term has definitely become more amorphous and ambiguous. I spent a few years mostly working with physical hardware, networking, virtualization, scripting deploys for DBs and OSs, and handling the DNS alongside some business oriented C#. Then I moved over to working with AWS and Azure.
Now I primarily work with Node, Golang and Python.
With modern tooling and a team that supports it, I've found myself mostly working on services, APIs and React front-ends. Even with Next.js, it's hard to know where the line on what "full stack" is.
It's sort of come to encompass the frontend and backend of an application, less so the architecture of it. Mentally, however, I still lump it all together when I think of what qualifies for "full stack", as I personally think the term represents an understanding of how everything works together, which definitely helps when troubleshooting the source of a problem.
By this definition then Next.js is full-stack, but I don't think even they claim that.
This is actually part of why I created Nodewood [1], because every new Node project required pulling all that together, and every new SaaS idea I had had the same basic requirements (user management, subscription management, teams support, etc). Then I figured, if I found this useful, surely others would too, so I packaged it up and have had a few happy customers since then, who have helped me refine it, which feeds back into making my projects better, too.
[1] - https://nodewood.com
[1] - https://nodewood.com
To each his own, personally I stay away from Django and full fledged frameworks (context: I run a few small saas and launch new products frequently).
I find that having to dig to find out how things are done and trying to hack around the framework is the cause of bugs and frustrations.
I still manage two services based on Django and they're a continue cause of pain.
I'd rather spend a week at the beginning of the project and set things up the way I want them with minimal dependencies. Then evolving things is fairly easy, just a matter of skimming through the code.
I find that having to dig to find out how things are done and trying to hack around the framework is the cause of bugs and frustrations.
I still manage two services based on Django and they're a continue cause of pain.
I'd rather spend a week at the beginning of the project and set things up the way I want them with minimal dependencies. Then evolving things is fairly easy, just a matter of skimming through the code.
> I'd rather spend a week at the beginning of the project and set things up the way I want them with minimal dependencies.
Same.
The only time that I've gone away from this strategy is when I need to get other developers to buy-in to a framework (or hell just a "system of work"). In leadership roles, I've found that a highly-opinionated framework with lots of batteries included really helps keep people coloring inside the lines. For me anecdotally that's more important than having a low-dependency codebase that's very appropriately sized to the problem it's solving.
I've found it's way easier to dodge the inevitable "X way sucks" from my colleagues/subordinates by using "full framework" tools that I can pitch to non-technical management vs. a bespoke solution.
Batteries included frameworks solve people problems more than they do software problems.
---
Just want to reiterate that I absolutely agree with you and the only time I find tools like Django appropriate is when other developers need tooling that keeps them "in the lines," and/or when I'm expecting to have to pitch my solution to non-technical peers/leadership.
Same.
The only time that I've gone away from this strategy is when I need to get other developers to buy-in to a framework (or hell just a "system of work"). In leadership roles, I've found that a highly-opinionated framework with lots of batteries included really helps keep people coloring inside the lines. For me anecdotally that's more important than having a low-dependency codebase that's very appropriately sized to the problem it's solving.
I've found it's way easier to dodge the inevitable "X way sucks" from my colleagues/subordinates by using "full framework" tools that I can pitch to non-technical management vs. a bespoke solution.
Batteries included frameworks solve people problems more than they do software problems.
---
Just want to reiterate that I absolutely agree with you and the only time I find tools like Django appropriate is when other developers need tooling that keeps them "in the lines," and/or when I'm expecting to have to pitch my solution to non-technical peers/leadership.
> I'd rather spend a week at the beginning of the project and set things up the way I want them with minimal dependencies.
Me too. I don't use create-react-app or anything else to set up my Node.js/React/TypeScript/SWC projects. I install each package I need manually, and configure each item precisely how I want it (tsconfig.json, webpack.config.ts, .swcrc, even .eslintrc.json). Makes for a nice, lean project every time.
Me too. I don't use create-react-app or anything else to set up my Node.js/React/TypeScript/SWC projects. I install each package I need manually, and configure each item precisely how I want it (tsconfig.json, webpack.config.ts, .swcrc, even .eslintrc.json). Makes for a nice, lean project every time.
And almost impossible to understand or maintain to anyone coming after you to the project.
The benefits of frameworks is that there's shared knowledge on how to use it, lots of documentation and they are more battle proven.
There's a reason people are not writing assembler. Reinventing the wheel every single time has its trade offs too.
The benefits of frameworks is that there's shared knowledge on how to use it, lots of documentation and they are more battle proven.
There's a reason people are not writing assembler. Reinventing the wheel every single time has its trade offs too.
> I'm pulling all of that extra stuff in from npm piecing it together myself
You should check out Fastify.
It does solve a lot of stuff for you. Either included in the core or with official plugins.
You should check out Fastify.
It does solve a lot of stuff for you. Either included in the core or with official plugins.
I agree. I see technologies like Next, Remix, etc claiming to be full stack, but it doesn't "feel" full stack to me. They have offerings like backend functions, which is really just an HTTP response.
But, when I think of a "all in one" / "full stack" langauge, there needs to be an existing ORM inside the framework. That works across the View/Communication/Model.
These frameworks have you needing other tools to do this.
But, when I think of a "all in one" / "full stack" langauge, there needs to be an existing ORM inside the framework. That works across the View/Communication/Model.
These frameworks have you needing other tools to do this.
I thought full stack means going all the way down to tuning the database, the kernel, building your own CI/CD, and performing your own deployment and scaling.
In practice, I've seen it used to describe someone who is fluent on the backend (DBs, APIs, DevOps, etc.) and competent on the frontend (React). But that could be more of a product of the talent pool, I think there are more backend engineers who dabble in the frontend (maybe because that's where the perceived party is?) than the other way around.
It used to be like this before react.
Today, I have the opposite impression. Nowadays everyone is a react tool who want to learn backend so they can call themselves full stack.
People see react, Facebook and their eyes turn into dollar signs.
Today, I have the opposite impression. Nowadays everyone is a react tool who want to learn backend so they can call themselves full stack.
People see react, Facebook and their eyes turn into dollar signs.
If it doesn't make you coffee, walk your dog, and iron your shirts, it's not full stack!
I've always heard it in the context of "front-end" vs "back-end" vs "full-stack (both)"
Normally it's used this way to describe a job, but that meaning has circled around and is now used to describe libraries/frameworks too
Normally it's used this way to describe a job, but that meaning has circled around and is now used to describe libraries/frameworks too
I agree, this is becoming really confusing! And then also "center-stack" which I heard somewhere recently re one of the frontend frameworks.
When I hear of a full-stack framework (in a modern setting), I think of stuff like Meteor, Redwood, and Wasp-lang (disclaimer: I am one of the authors of that one). RoR also always comes to mind, although it's more commonly used as an API server nowadays.
When I hear of a full-stack framework (in a modern setting), I think of stuff like Meteor, Redwood, and Wasp-lang (disclaimer: I am one of the authors of that one). RoR also always comes to mind, although it's more commonly used as an API server nowadays.
> For me "full stack" is something like Rails, Laravel, Django, etc.
Rails, Laravel, or Django are completely agnostic about the frontend side of the full stack though :-) Well, maybe Rails will have an opinion about Stimulus; but this fresh thing continues the journey after the response has reached the client.
Rails, Laravel, or Django are completely agnostic about the frontend side of the full stack though :-) Well, maybe Rails will have an opinion about Stimulus; but this fresh thing continues the journey after the response has reached the client.
Now with Turbo, Rails is very opinionated about the frontend side. Which is a great thing.
My productivity with Rails 7 and Turbo has never been higher.
My productivity with Rails 7 and Turbo has never been higher.
I've always taken full-stack to refer to integration across all layers, versus saying anything about how featureful those layers are.
Please make the bash thing, I want to see it with a fancy marketing page to mock the JS ecosystem!
I'm just picking out one from the list, but on background jobs, a nice thing about async runtimes like node/deno is that you really don't need background jobs for most apps. You can just use web workers and async/await to do stuff in the background. You might want a more robust system down the line, but it's not needed in the beginning imo.
To me, a PHP file in an Apache server which includes some JS counts as full stack. To me, fullstack = frontend + backend.
I don't think Django counts as full-stack, as you don't have a default front-end framework, like Rail's Stimulus.
I don't think Django counts as full-stack, as you don't have a default front-end framework, like Rail's Stimulus.
Historically, I don't think you could call something that sits on top of Apache full stack if you didn't also control Apache, so maybe, depending on whether you're just dropping on some webhost?
If you get to ignore threads/forks and number of workers as well as memory management of them because it's someone (or something) else's responsibility, then that's not full stack. The stack is OS (slightly, and can often be ignored), webserver, application, and client (HTML/JS). If you hand off responsibility of any of that then it isn't "full".
The term originally came from referring to people that handled all these things. You could be a back-end developer, dealing with the OS and webserver and maybe application, front-end developer where you dealt with HTML, JS and maybe some application code, or you could do both and be a "full stack" developer.
If you get to ignore threads/forks and number of workers as well as memory management of them because it's someone (or something) else's responsibility, then that's not full stack. The stack is OS (slightly, and can often be ignored), webserver, application, and client (HTML/JS). If you hand off responsibility of any of that then it isn't "full".
The term originally came from referring to people that handled all these things. You could be a back-end developer, dealing with the OS and webserver and maybe application, front-end developer where you dealt with HTML, JS and maybe some application code, or you could do both and be a "full stack" developer.
Yeah I agree about setting up Apache and managing it. OS + Webserver + (Server language + JS) + DB is the full stack
Some of these newer frameworks are certainly using the term "full stack" in a very different sense than how it's been used historically. Could you fault someone for a cursory reading of the homepage and coming away thinking that Fresh/Remix do all the features you listed out of the box?
There's enough confusion here I suppose I'll start using the term "batteries included framework" for the technologies you listed.
There's enough confusion here I suppose I'll start using the term "batteries included framework" for the technologies you listed.
https://github.com/Qbix/Platform is as full-stack as it gets
Most other frameworks don’t include things like websockets and Web Push notifications, as well as support for WebRTC, payments etc. So where do you draw the line?
Most other frameworks don’t include things like websockets and Web Push notifications, as well as support for WebRTC, payments etc. So where do you draw the line?
Full stack * is * just running code on the backend and frontend. There is no complexity requirement for something to be considered a full stack. You could have a super simple todo list with native javascript that persists by writing to a single sqlite table and that is a complete "full stack" web application.
You could have something incredibly intensive on the front end using a bunch of modern frameworks and visualization tools. Or something incredibly intensive on the back end with some of the features you mentioned in your post. But neither is strictly required and many apps will function with just the basics on either or both ends.
You could have something incredibly intensive on the front end using a bunch of modern frameworks and visualization tools. Or something incredibly intensive on the back end with some of the features you mentioned in your post. But neither is strictly required and many apps will function with just the basics on either or both ends.
Correct me if I am wrong, but this is basically server-side rendering with a smart system to re-render some component ("island") on the client ?
Yes, that is the idea. Fresh is primarily a routing and templating system with built in client hydration.
I really like the idea of Deno and Fresh's philosophy also resonates with me (I'm a Rails guy). I would like to see an integrated ORM (can be an existing one) and testing framework though, before I would consider it a "full-stack" web framework.
Not sure about ORM, but Postgres.js[0] works on Deno. For testing, Deno includes a built-in test runner and assertions via the std[1].
[0] https://github.com/porsager/postgres
[1] https://deno.land/manual/testing
[0] https://github.com/porsager/postgres
[1] https://deno.land/manual/testing
Yes, this is something I want to add in the future. We're just not quite there yet. My current plan is:
1. first class styling plugins
2. synchronized island state
3. built in data persistence
1. first class styling plugins
2. synchronized island state
3. built in data persistence
Amazing. If I can make a wish for 1: Tailwind =)
It is not documented, but run `deno run -A -r https://fresh.deno.dev my-app --twind` :)
Awesome, I will give this a spin soon =)
Since people are voting for Tailwind support, I have to throw in my vote for CSS modules! Even though Tailwind has a lot of momentum now, there are still a lot of people quietly getting things done with CSS Modules, CSS-in-JS, etc. :)
The JS ecosystem seems a lot more hesitant to bundle features into frameworks à la Rails/Laravel & friends, but Redwood.js sounds like what you're looking for. The ORM it uses is Prisma, which works really well on its own too.
https://redwoodjs.com https://www.prisma.io
https://redwoodjs.com https://www.prisma.io
If you want to learn about Redwood, I'd also recommend Amy's talk about it from Prisma Day two weeks ago: https://www.youtube.com/watch?v=_zJ44wmo1Ro&ab_channel=Prism... :)
Redwood and Prisma look nice! But what I like more is a focus on serverside rendering and as few build steps as possible, like Fresh. I also find Deno more appealing than Node (simplicity).
But yes, I guess if I would need to pick a more mature framework with JS, Redwood would be the way to go.
But yes, I guess if I would need to pick a more mature framework with JS, Redwood would be the way to go.
Prisma is a nice product but I wouldn’t use it in production yet. It is prone to race conditions as it does not use native upserts, opting instead for Rails-style check-if-exists-insert-if-doesnt.
upupandup(5)
> But client-side rendering is expensive; the framework often will ship hundreds of kilobytes of client-side JavaScript to users on each request. These JS bundles often do little more than rendering static content that could just as well have been served as plain HTML.
server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8?
for a properly-chunked app, hopefully most requests for the larger vendor bundles are cached/JITed, and each request doesnt actually download much extra JS.
there are also many frameworks faster than React (Solid, Marko, etc)
server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8?
for a properly-chunked app, hopefully most requests for the larger vendor bundles are cached/JITed, and each request doesnt actually download much extra JS.
there are also many frameworks faster than React (Solid, Marko, etc)
> server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8?
Expensive not in money terms, but in user experience.
Also: if you are doing e-commerce, 100ms added latency can cost you 7-8% in conversions. Spending 5% more on hosting to do SSR just makes economic sense.
Expensive not in money terms, but in user experience.
Also: if you are doing e-commerce, 100ms added latency can cost you 7-8% in conversions. Spending 5% more on hosting to do SSR just makes economic sense.
> 100ms added latency can cost you 7-8% in conversions
i hear this metric (or something equally absurd) cited frequently and have never seen it to be true in my own experience.
i guess if you have to load a product page with 100 images (or assets) and each has 100ms network latency, then it will add up to much more than that. but 100ms for a single interaction or network request (e.g. process payment POST) is not going to move the needle on conversions. 100ms will feel instantaneous to 97% of users, and more than satisfactory for the remaining 3%.
(i say this as someone who profiles aggressively and strives to optimize every stray 5ms in JS and every 1kb over the wire)
i hear this metric (or something equally absurd) cited frequently and have never seen it to be true in my own experience.
i guess if you have to load a product page with 100 images (or assets) and each has 100ms network latency, then it will add up to much more than that. but 100ms for a single interaction or network request (e.g. process payment POST) is not going to move the needle on conversions. 100ms will feel instantaneous to 97% of users, and more than satisfactory for the remaining 3%.
(i say this as someone who profiles aggressively and strives to optimize every stray 5ms in JS and every 1kb over the wire)
I think that particular metric (or one very like it) was originally about… Amazon.com.
So, y’know, maybe a slightly different ballgame.
So, y’know, maybe a slightly different ballgame.
maybe there was more nuance to that statement, but i never bought it at face value, even then.
Google did a large study. If your page load is 5s then adding 100ms does not matter. I got the raw data from them and it mattered in the curve closing in on the whole page taking 200ms or so. It’s level, and then around 2.5s, each 100ms made more and more of a difference.
Yeah I think the main thing for a website to hold on to users it should at least be interactive and responsive quickly (with clear loading indicators) even if it is taking a while to load everything on the page. If a page looks like it is stuck or feels like it is stuck then I am likely to abandon it. But if it has clear indicators and animations to indicate something is happening, I will be more patient with it.
I think if frame it as, “each 100ms you shave off a critical consumer shopping checkout flow page increases conversions by X%” it starts to seem more defensible.
Agreed that in the general case 100ms to full paint (with interactivity not far behind) is really good.
Agreed that in the general case 100ms to full paint (with interactivity not far behind) is really good.
Doesn't really matter if the relationship isn't linear like that. I suspect it's more likely conversions start to drop off after certain thresholds are met e.g. 3 seconds causes conversions to drop by 5%, 20 seconds causes them to drop by 30%.
Just averaging out those numbers could result in engineering time being wasted chasing rapidly diminishing returns, if the site is already below one of those thresholds.
Just averaging out those numbers could result in engineering time being wasted chasing rapidly diminishing returns, if the site is already below one of those thresholds.
I've worked in e-commerce for a while and have heard similar stated from time to time and seemed like someone was trying to fit a linear line over what's almost certainly an s-curve distribution.
At lower latencies no one is going to leave your site because it takes 1200ms instead of 1000ms to fully load a page. But at some point almost everyone is going to leave your site rather than wait.
I also find these stats really confusing because whenever someone talks to me about site performance they're always talking about a different metric (server response time, first paint, time to interactive, etc). If you're first paint is quick then users aren't going to care if content half way off the page doesn't load instantly.
I've always tried to focus on how fast things feel rather than worrying too much about specific metrics. If you can just get something (ideally the important bit(s)) to load really fast a site can feel extremely fast even if it's mostly just an illusion. Users like to click things and see stuff happening. It's things like reloading the page when adding items to cart then making them wait on a white screen for multiple that increases bounce times as abandoned carts in my experience. Making add to cart buttons an ajax request probably helps far more than making the page load 200ms faster.
At lower latencies no one is going to leave your site because it takes 1200ms instead of 1000ms to fully load a page. But at some point almost everyone is going to leave your site rather than wait.
I also find these stats really confusing because whenever someone talks to me about site performance they're always talking about a different metric (server response time, first paint, time to interactive, etc). If you're first paint is quick then users aren't going to care if content half way off the page doesn't load instantly.
I've always tried to focus on how fast things feel rather than worrying too much about specific metrics. If you can just get something (ideally the important bit(s)) to load really fast a site can feel extremely fast even if it's mostly just an illusion. Users like to click things and see stuff happening. It's things like reloading the page when adding items to cart then making them wait on a white screen for multiple that increases bounce times as abandoned carts in my experience. Making add to cart buttons an ajax request probably helps far more than making the page load 200ms faster.
Also, this can make me bounce: ,,payment failed, please start again with an empty shopping cart''. It happens on quite many webshops.
I guess that's not really performance, but I agree that UX is one of those things that can subtlety annoy someone enough that they'll just give up and go elsewhere. That's a pretty extreme example, but even simple things like asking the user for too much information over too many pages at checkout can dramatically increase bounce rate. If a user can't land on your site, find what they're looking for then checkout within a few minutes, something is wrong.
On payment failures, an interesting solution an ecommerce I used to work for came up with was just to place the order on payment failure. They figured it was better just to send out an email after the fact asking them to try again and if that failed they could call and take the payment over the phone if need be. We targeted an older demographic and sold fairly pricey products though. I guess that model wouldn't work so well if you're selling $10 tshirts. I believe Amazon does something similar. I know they've sent me emails in the past letting me know my payment failed after placing an order.
On payment failures, an interesting solution an ecommerce I used to work for came up with was just to place the order on payment failure. They figured it was better just to send out an email after the fact asking them to try again and if that failed they could call and take the payment over the phone if need be. We targeted an older demographic and sold fairly pricey products though. I guess that model wouldn't work so well if you're selling $10 tshirts. I believe Amazon does something similar. I know they've sent me emails in the past letting me know my payment failed after placing an order.
I could see the 100ms/7% impact coming into play for a super impulsive shopper going from page to page compulsively until they pull the trigger on a product. I wouldn't be surprised if that was a lot of Amazon's business—people buying things they had not set out to buy.
Makes less sense the smaller an e-shop gets since the consumer already needed intent to shop there. If I know I already want product X on Shop Y today, 10 second load times are rather inconsequential.
Makes less sense the smaller an e-shop gets since the consumer already needed intent to shop there. If I know I already want product X on Shop Y today, 10 second load times are rather inconsequential.
I've been thinking about that a lot lately. I have a medium-sized e-commerce. We sell hyper-customized products and, to be honest, the site's overall performance is not good. But when I looked into other stores in the same niche as ours, who are making a lot more money than us, I saw that their performance wasn't better than ours. I don't think people shop impulsively in our store because they have to customize the product and then make sure the customization is correct (it's a pretty complex customization). I believe that because the journey to checkout is so long and requires so much attention, the customers just don't give up due to high latency or slow responsiveness overall.
I did a study on this (N>100m) at a previous employer who had quite a lot of e-commerce traffic.
It's sort of true but also a massive over simplification. The relationship between conversion and speed is not linear. Some people are beyond help, and others already have it so good they only notice the most extreme degradation in performance.
It's also hard to isolate confounding factors like users who have fast infrastructure tend to be rich and rich people buy more stuff. Making pages load faster doesn't give them more money to buy stuff.
Overall faster is definitely better but the specific magnitude will depend on your customer demographics. In our case the Amazon 100ms saved = 1% more sales was close enough for a rule of thumb.
It's sort of true but also a massive over simplification. The relationship between conversion and speed is not linear. Some people are beyond help, and others already have it so good they only notice the most extreme degradation in performance.
It's also hard to isolate confounding factors like users who have fast infrastructure tend to be rich and rich people buy more stuff. Making pages load faster doesn't give them more money to buy stuff.
Overall faster is definitely better but the specific magnitude will depend on your customer demographics. In our case the Amazon 100ms saved = 1% more sales was close enough for a rule of thumb.
It seems like an inference from correlation that someone extrapolated out in a linear fashion.
In isolation, I don't think that 100ms in delay before paint really causes enough impatience in people that you'd lose 7-8% as a direct result. Humans don't really make that kind of decision within such a minuscule window of time; to a degree, we expect our devices to have delays.
More likely, that loss of conversion is correlated because sites that have longer than 100ms latency have latency that's extreme enough to reach the "I give up" threshold. A site where its pages take 3 or more seconds to load would see a big difference, but that doesn't mean that a site with exactly 100ms latency will see any meaningful loss of conversions outside a margin of error.
People will also be much more patient with a high-value site. For instance, I'm willing to wait a few seconds for each page to load on the McMaster-Carr website because it's an otherwise good experience and a high-value store. But I'm far less willing to tolerate delays on some horseshit Shopify page plastered with ads and reselling crap from Alibaba. And if you've got a blog that's poorly formatted and overall signals low value content, I'll dip out the moment I detect the slightest monkey business slowing things down.
In isolation, I don't think that 100ms in delay before paint really causes enough impatience in people that you'd lose 7-8% as a direct result. Humans don't really make that kind of decision within such a minuscule window of time; to a degree, we expect our devices to have delays.
More likely, that loss of conversion is correlated because sites that have longer than 100ms latency have latency that's extreme enough to reach the "I give up" threshold. A site where its pages take 3 or more seconds to load would see a big difference, but that doesn't mean that a site with exactly 100ms latency will see any meaningful loss of conversions outside a margin of error.
People will also be much more patient with a high-value site. For instance, I'm willing to wait a few seconds for each page to load on the McMaster-Carr website because it's an otherwise good experience and a high-value store. But I'm far less willing to tolerate delays on some horseshit Shopify page plastered with ads and reselling crap from Alibaba. And if you've got a blog that's poorly formatted and overall signals low value content, I'll dip out the moment I detect the slightest monkey business slowing things down.
To add to the list: Svelte is also faster and lighter for most cases. And with SvelteKit the server sends only the bare minimum JS to make the page dynamic while being SEO friendly depending on the adapter of choice.
It can even output static, precompiled, pages with the adapter-static so no heavy backend processing involved and response times are best-in-class: https://github.com/sveltejs/kit/tree/master/packages/adapter...
It can even output static, precompiled, pages with the adapter-static so no heavy backend processing involved and response times are best-in-class: https://github.com/sveltejs/kit/tree/master/packages/adapter...
The cost of server-side rendering feels pretty trivial to me these days.
Fly.io will sell you a 256MB of RAM container for $1.94/month, which is perfectly capable of server-side rendering dozens (maybe even hundreds if you write efficient code) of requests per second.
I'm sure you can get even better deals if you shop around.
Fly.io will sell you a 256MB of RAM container for $1.94/month, which is perfectly capable of server-side rendering dozens (maybe even hundreds if you write efficient code) of requests per second.
I'm sure you can get even better deals if you shop around.
Is that kind of a container less capable than just about any client (except embedded of course)? Sorry if it's a stupid question. I'm not familiar with web SSR.
Yes, and if you've got a fairly complex website it's unlikely it could render more than a couple dozen rendered requests per second. If you're not rendering and instead getting them from a cache, that would be different of course.
The question makes no sense and your answer is wildly misleading and inaccurate.
A server is not 'rendering' a website the same way a client does.
A couple of dozen requests a second? In drupal in dev mode maybe but even then... I feel like we need to have a bit of a knowledge reset before spouting supposed info about csr v ssr
A server is not 'rendering' a website the same way a client does.
A couple of dozen requests a second? In drupal in dev mode maybe but even then... I feel like we need to have a bit of a knowledge reset before spouting supposed info about csr v ssr
> A server is not 'rendering' a website the same way a client does.
While this is technically true, there is still "rendering" happening on the server when you JIT-compile JSX/TSX templates and transpile everything from your ES6 modules and includes to HTML/CSS/JS that a browser can parse.
In a sense you're splitting the load between client and server because you're right some stuff always has to run client side (like the actual layout engine work).
While this is technically true, there is still "rendering" happening on the server when you JIT-compile JSX/TSX templates and transpile everything from your ES6 modules and includes to HTML/CSS/JS that a browser can parse.
In a sense you're splitting the load between client and server because you're right some stuff always has to run client side (like the actual layout engine work).
[deleted]
Very much depends on the code you are running. If you're running something like React server-side rendering it may not be enough resources - in which case you'll probably want an instance that costs $10-$50/month instead.
Most server-side frameworks I've worked with will perform just fine in 256MB of RAM though. These days I'd expect people to get the best results from Go or Rust, if they want to be able to run on as little RAM or CPU as possible.
I'll keep on sticking with Python!
Most server-side frameworks I've worked with will perform just fine in 256MB of RAM though. These days I'd expect people to get the best results from Go or Rust, if they want to be able to run on as little RAM or CPU as possible.
I'll keep on sticking with Python!
I know not the same use case, but nginx will serve near 100K requests per second of a static site on a moderately powerful server. Server side generated SPA empowered by K8 solution drops that to a dozen. Those number discrepancies are comical.
I must be too old to enjoy recent resume building architectures....
I must be too old to enjoy recent resume building architectures....
What does that have to do with kubernetes? Nginx runs fast on kubernetes also.
I'm assuming Fly.io offering is powered by K8.
fly is not based on k8s or docker
https://fly.io/blog/docker-without-docker/
they just use docker api, hence why I don't think there is the resource waste typical of k8s
I haven't run benchmarks but speed wise containers shouldn't slow down app requests (except in a few cases with very specific kernels, which I unfortunately experienced in production - but I was told it was just bugs)
they just use docker api, hence why I don't think there is the resource waste typical of k8s
I haven't run benchmarks but speed wise containers shouldn't slow down app requests (except in a few cases with very specific kernels, which I unfortunately experienced in production - but I was told it was just bugs)
fly.io is simply a VM provider. You can achieve the same requests per second there as any VM host. The person you're replying to just has a comically low expectation of performance.
This was my thought, too. In reality, client side rendering today is “cheap” because you typically put a CDN in front of your application to serve static resources and scripts, and your backend only serves the API requests (if needed). Rendering everything on the backend means by contrast that you’re limited to the capacity of your server and the latency based on where it’s located.
Counter-point to this is that edge computing addresses the latency for compute in the same way that a CDN does for static assets.
SSR definitely has drawbacks in the old "run your app from a single VPS somewhere" model, but in a globally distributed edge computing model, you remove a lot (but not all) of those drawbacks.
SSR definitely has drawbacks in the old "run your app from a single VPS somewhere" model, but in a globally distributed edge computing model, you remove a lot (but not all) of those drawbacks.
CSR is expensive, because you lose customers over bad performance (measurably), and you can not scale the client. You can however scale the server.
modern JS runtimes are extremely fast on all hardware that's not a 2000-era phone or an embedded micro-controller with 4MB ram. if your CSR is slow on a modern client, then that same JS code will bring your server to its knees when you simply migrate it to an equivalent V8-powered JS backend. scaling the server will not solve this; you just have to write fast JS code and pay attention when you write it, not merely optimize as an afterthought. test on crappy hardware, test with huge datasets, test on slow connections, test with asset caching disabled, target 60fps+.
https://betterprogramming.pub/creating-a-web-performance-cul...
https://betterprogramming.pub/creating-a-web-performance-cul...
In theory yes, but in practice the majority of modern SPAs are slow and bloated.
Most of the slow SPAs I use are slow because they are waiting for api requests from the server.
That's one reason.
The other is that those API requests need to be rendered with JS which means downloading the JS upfront + rendering time. JS rendering will always be slower than pure HTML rendering.
I will agree for small apps this is negligible, but for bigger apps this means downloading, parsing, and executing MBs of JS. See the Google Cloud console for example or the Spotify web app.
And yet there is another point which is that with SPAs, ignorant developers can cause more "damage". The other day I opened a simple password recovery form, and it rendered dozens and dozens of divs and downloaded (I shit you not) 2MBs of JS.
The other is that those API requests need to be rendered with JS which means downloading the JS upfront + rendering time. JS rendering will always be slower than pure HTML rendering.
I will agree for small apps this is negligible, but for bigger apps this means downloading, parsing, and executing MBs of JS. See the Google Cloud console for example or the Spotify web app.
And yet there is another point which is that with SPAs, ignorant developers can cause more "damage". The other day I opened a simple password recovery form, and it rendered dozens and dozens of divs and downloaded (I shit you not) 2MBs of JS.
No, usually its some api that's taking 1, 2, 5 or more seconds to respond. Some api written in something that's not javascript.
> that same JS code will bring your server to its knees when you simply migrate it to an equivalent V8-powered JS backend.
It's not the same because on the server you usually have some form of caching, and the V8 engine will have already JIT'd that code as well.
It's not the same because on the server you usually have some form of caching, and the V8 engine will have already JIT'd that code as well.
Also it's not like CSR is mostly used just to render out a flat document. It's used mainly for interactive stuff, often just banging internal client side state and not even talking to an API. And even when the client is talking to an API to update a small part of the document, this is more straight forward, than having a full client-server round trip, just for updating that small part.
Nowadays i prefer static site generation and if interactivity is needed, additional client hydration. The only scenario, which i can think of, which does not match this model are highly frequently updated dynamic content sites. Am i wrong?
Even for moderately frequently updated dynamic content sites, statically rendering say 10 times a day might suffice. When the hydration kicks in, you can always fetch the info, which changed between the 10x/day updates and still have a low time to interactive.
SSR with caching maybe comparable in terms of time to interactive, but does feel less elegant imo.
Nowadays i prefer static site generation and if interactivity is needed, additional client hydration. The only scenario, which i can think of, which does not match this model are highly frequently updated dynamic content sites. Am i wrong?
Even for moderately frequently updated dynamic content sites, statically rendering say 10 times a day might suffice. When the hydration kicks in, you can always fetch the info, which changed between the 10x/day updates and still have a low time to interactive.
SSR with caching maybe comparable in terms of time to interactive, but does feel less elegant imo.
> server-side rendering for each request in V8 might be more expensive to host than client side rendering in V8?
Considering mobile, embedded or even considering that my grandmother still owns a i3 4th gen, maybe would be better SSR, but for modern machines i'm not in for SSR, still feels a little bit clunky to me.
> for a properly-chunked app, hopefully most requests for the larger vendor bundles are cached/JITed, and each request doesnt actually download much extra JS. Yes, cache here helps alot, but saving mobile data still be pretty good, considering some SPAs doesn't chunk it's script files very well.
Considering mobile, embedded or even considering that my grandmother still owns a i3 4th gen, maybe would be better SSR, but for modern machines i'm not in for SSR, still feels a little bit clunky to me.
> for a properly-chunked app, hopefully most requests for the larger vendor bundles are cached/JITed, and each request doesnt actually download much extra JS. Yes, cache here helps alot, but saving mobile data still be pretty good, considering some SPAs doesn't chunk it's script files very well.
Are deno packages usable from the node side of the ecosystem ? and vice versa ?
You can use Node modules in Deno using https://esm.sh/
You can use Deno modules in Node using https://github.com/denoland/dnt
You can use Deno modules in Node using https://github.com/denoland/dnt
Depends if your package uses any specific Deno/Node APIs. Deno also only supports ESM (which you should be using anyway).
There is, however, a Node compatibility layer for Deno: https://deno.land/[email protected]/npm_nodejs/std_node
There is, however, a Node compatibility layer for Deno: https://deno.land/[email protected]/npm_nodejs/std_node
[deleted]
I am very interested in seeing where this goes. I would love to see things get fleshed out a little more ala BlitzJS (auth, simple client/server session management, integrated database tooling), but I don't know if that goes along with Fresh's principles. But this is a very exciting start for this framework and looks like a great addition to the Deno ecosystem.
Previous discussion on Fresh: https://news.ycombinator.com/item?id=31720110
Is there any company that is hiring that uses fresh or deno in production?
deno!
edit: i just realized you probably meant another company... i believe Slack uses deno in prod, not sure if they're currently hiring. netlify, github, and supabase all use deno as well.
edit: i just realized you probably meant another company... i believe Slack uses deno in prod, not sure if they're currently hiring. netlify, github, and supabase all use deno as well.
upupandup(1)
IIRC Vercel and Netlify edge functions are actually using Deno Deploy.
Edit:
No, it's only Netlify.
Edit:
No, it's only Netlify.
No, Vercel Edge Functions use Cloudflare Workers.
https://news.ycombinator.com/item?id=29003514
https://news.ycombinator.com/item?id=29003514
Thanks for the correction!
This sounds very similar to Hotwire https://hotwired.dev/ Can someone who has used at least one of those chime in?
Hotwire and LiveWire make a network request to allow the server to re-render the component on user interaction.
Fresh, in contrast, does SSR and then hydrates the components on page load, making it much more similar to React with SSR or Next.JS.
Fresh, in contrast, does SSR and then hydrates the components on page load, making it much more similar to React with SSR or Next.JS.
Does this work like how remixjs and nextjs(with the next RFC[0]) with react server components[1]?
[0] https://nextjs.org/blog/layouts-rfc [1] https://reactjs.org/blog/2020/12/21/data-fetching-with-react...
[0] https://nextjs.org/blog/layouts-rfc [1] https://reactjs.org/blog/2020/12/21/data-fetching-with-react...
Not exactly, because this example from Deno is using Preact, a stripped down React-like framework. Server Components relies on React fiber and the latest async features in newest version of React. They do both aim to limit the JS sent down the wire though.
[deleted]
How does this compare against Astro: https://astro.build/ ?
For those websites that can use it (like a blog), it seems like static site generation would be better, to cache the database requests? Then you can run in the free tier of Netlify or using GitHub pages, for example.
Or to do the opposite, for a single-player website where there aren't any server requests to cache, a client-only website can run offline.
Fresh looks good for multi-player websites that are unavoidably making database requests interactively, though.
Or to do the opposite, for a single-player website where there aren't any server requests to cache, a client-only website can run offline.
Fresh looks good for multi-player websites that are unavoidably making database requests interactively, though.
I similarly wish Fresh did full server side generation. Even Next.JS has a tool to export as a static site. Maybe it will come to Fresh at some point, or maybe it’s there and just not well documented.
I’m using NanoJSX with Deno to render JSX on the server and spit the result into a file, but I’m having to write a lot of SSG stuff myself, (like logic to loop over files).
I’m using NanoJSX with Deno to render JSX on the server and spit the result into a file, but I’m having to write a lot of SSG stuff myself, (like logic to loop over files).
Yeah, for their examples there isn’t even a reason to use dynamic rendering instead of static rendering (pre-build a static site), as the response doesn’t change for different requests. Dynamic rendering only pays of if you do something more complex, like authentication, etc.
But I guess static rendering would go against their mantra of “no build step”, which even currently is actually false, as they need to generate the manifest file.
See also https://news.ycombinator.com/item?id=31723205
But I guess static rendering would go against their mantra of “no build step”, which even currently is actually false, as they need to generate the manifest file.
See also https://news.ycombinator.com/item?id=31723205
They're probably planning on making another vercel way and tie in future customers to their platform running v8 isolates.
I understand it from a business point of view but it's bad for users and for performance. Same thing happened to images in next. The plugins to have optimized images in next are all broken and the official one use a "free" dynamic route offered by vercel.
I understand it from a business point of view but it's bad for users and for performance. Same thing happened to images in next. The plugins to have optimized images in next are all broken and the official one use a "free" dynamic route offered by vercel.
Maybe I am getting all wrong, but this sounds like PHP.
I'm excited for server-side rendering to return to the mainstream so that in a few years I can revolutionize the industry with my ingenious new idea to render things on the client with Javascript!
You might even land the ultimate innovation of doing both by "inventing" AJAX! (Just call it something new, like piped hydration)
[deleted]
Yes, but the templates are written in JSX. No quoting nightmares, nesting is a breeze, the server side APIs speak like the browser ones, and it's really fast. With deno.dev hosting on the edge, it's server side like php, but way better. I used to like WordPress, now I love Deno.
thx for your comment, as i said i might get all wrong. Still think PHP template engines like Twig are well designed and make you highly productive. Personally, I feel JSX is a code smell, as it mixes UI snippets with code. But this is maybe my old school software engineering attitude. I am just waiting for the next OSCommerce package written in JSX...
> mixes UI snippets with code
You can never really avoid it unless you only use HTML. Templates are code. I think JSX is nicer because it's fully featured and the same syntax as regular JS, not a subset limited template language
You can never really avoid it unless you only use HTML. Templates are code. I think JSX is nicer because it's fully featured and the same syntax as regular JS, not a subset limited template language
I haven't used Twig, but have used other PHP templating engines. Scope is the big deal for me. JSX has actual scoping (it's just JavaScript), function calls, etc. PHP templates have one scope, even when you enter an included sub template.
Laravel released template components in version 7, but I haven't been able to try them yet and I'm hoping they'll improve things.
Laravel released template components in version 7, but I haven't been able to try them yet and I'm hoping they'll improve things.
Exactly. I'm not a great fan of PHP but nothing has produced more killer apps in the last 25 years.
And not everything, just many things, was wrong with PHP. No build step was the norm for PHP the last time I wrote much of it. I love things like this, ES modules, etc, that make it easier to have build-step-free apps.
Things have changed quite a bit in PHP land, mind you.
Not a bad thing IMHO. Take the best parts of PHP but use the language you already know and like (modern JS or typescript).
[deleted]
Yes, because true innovation rarely happens quickly and most things are just cyclical and hype driven in software.
I'm patiently waiting until we either discover Java or reinvent it all over again.. but this time it will be cool because it won't be called Java, it will be rather "JMocha" and really drive that productivity you're looking for when mixed with your Latte's 3.0 strong typing.
I suppose I'll be in my not-so cool corner working in my monorepo, single server and outdated Rails app on Postgresql; If only I could achieve Github scale with that..
I'm patiently waiting until we either discover Java or reinvent it all over again.. but this time it will be cool because it won't be called Java, it will be rather "JMocha" and really drive that productivity you're looking for when mixed with your Latte's 3.0 strong typing.
I suppose I'll be in my not-so cool corner working in my monorepo, single server and outdated Rails app on Postgresql; If only I could achieve Github scale with that..
To me the part about:
"... and the client is only responsible for re-rendering small islands of interactivity. A model where the developer explicitly opts in to client side rendering for specific components. ..."
actually sounds more like ASP.NET (the original Web Forms, not Core) support for AJAX:
https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.up...
"... and the client is only responsible for re-rendering small islands of interactivity. A model where the developer explicitly opts in to client side rendering for specific components. ..."
actually sounds more like ASP.NET (the original Web Forms, not Core) support for AJAX:
https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.up...
I had the same thought. I read the islands overview and was had a little "what's old is new again" chuckle.
https://jasonformat.com/islands-architecture/
https://jasonformat.com/islands-architecture/
PHP doesn't let you "opt in to client side rendering of specific components" though, without rewriting those components in JS.
React is here to stay and will have jquery like longevity.
Sure, performance wise, it isn't the best, but performance isn't an end all be all.
What separates react from the rest of the group is the maturity of React Native.
If Discord is betting on React Native, so too can it be used for a lion's share of applications out there.
When you're a startup deciding between technologies, usually you're a 1-5 man shop.
If you have the capital to blow, you can build separate teams for native + web, and separating native even further with Kotlin/Java and Swift with your choice for the web platform.
(I'm not trying to the Dart ecosystem just to only use Flutter, in which, Flutter-Web isn't SEO friendly)
Or you can just use React + RN and essentially have one team and save you anywhere from 500k-2m in hiring.
This is why React is so strong.
It's not because it's "performant", it's because it's practical, and even for performance it's good enough.
Sure, performance wise, it isn't the best, but performance isn't an end all be all.
What separates react from the rest of the group is the maturity of React Native.
If Discord is betting on React Native, so too can it be used for a lion's share of applications out there.
When you're a startup deciding between technologies, usually you're a 1-5 man shop.
If you have the capital to blow, you can build separate teams for native + web, and separating native even further with Kotlin/Java and Swift with your choice for the web platform.
(I'm not trying to the Dart ecosystem just to only use Flutter, in which, Flutter-Web isn't SEO friendly)
Or you can just use React + RN and essentially have one team and save you anywhere from 500k-2m in hiring.
This is why React is so strong.
It's not because it's "performant", it's because it's practical, and even for performance it's good enough.
Interesting. My company (small startup) went with flutter and vuejs and now we're switching to nextjs for all of our web apps and we're loving using it.
Flutter is awesome for mobile dev. For web? Not so much.
Flutter is awesome for mobile dev. For web? Not so much.
> React is here to stay and will have jquery like longevity.
I don't think React will ever disappear... but I seriously doubt it will ever become as popular and ubiquitous as jQuery.
Even today, React's market share is nowhere near close jQuery.
https://w3techs.com/technologies/comparison/js-jquery,js-rea...
I don't think React will ever disappear... but I seriously doubt it will ever become as popular and ubiquitous as jQuery.
Even today, React's market share is nowhere near close jQuery.
https://w3techs.com/technologies/comparison/js-jquery,js-rea...
The post seems to claim that there is no drawbacks others approach with the 0 bytes of js, and link to a blog post [1] that absolutely tells nothing how to properly manage back/front state and rendering consistency between the rendering and the «islands» on the client.
[1] https://jasonformat.com/islands-architecture
[1] https://jasonformat.com/islands-architecture
Without having built in the "Island Architecture", it looks exactly like a page of old where you serve an entire page, accept form submissions, return the updated page, and make small elements interactive (islands). These islands contain only minimal local state and global updates happen through the aforementioned form submissions.
The difference being it's all one isomorphic (?) React-y Deno codebase instead of the tangled PHP+jQuery mess.
Promising enough, if you ask me.
The difference being it's all one isomorphic (?) React-y Deno codebase instead of the tangled PHP+jQuery mess.
Promising enough, if you ask me.
This can be the killer app that Deno needs. As of now there is no specific reason for most of the people to try Deno as Node with its plethora of frameworks works and every one can choose their stack as per their taste. But if they can make Fresh sufficiently better (more cohesive and/or performant on both client and server side) and more feature rich on the backend (ORM + Workers/Queuing) with instant deploy then more people might consider switching.
I didn’t find a mention id this Fresh framework could also run on Node. In other words: is it relying on anything deno-specific?
Deno and Node are not generally compatible:
- their module/packaging systems are totally different
- their APIs for interacting with the system are different
- their module/packaging systems are totally different
- their APIs for interacting with the system are different
How far along is the story of cross compilation for the two ecosystems?
Node -> Deno: https://esm.sh
Deno -> Node: https://github.com/denoland/dnt
Deno -> Node: https://github.com/denoland/dnt
I had no joy trying to get a node JIRA library to run under deno with the various platforms. So still some way to go. Didn't seem far off. IIRC axios was the problem.
It took a friend and I 2 days last year to build a compatibility layer that allowed to run all the tests of Deno on Node.
Nothing new under the sun. This is just the latest in the pendulum swinging back to the same server-side strategy that Php/Django do. There's a reason we moved away that! Client-side apps are an elegant architecture that takes advantage of computing power on edge devices.
There's always room to learn more and make it better. They didn't make Fresh just from a whim
Congrats to the Deno team on v1.0!
If you’re interested in something similar for the Node.JS ecosystem, check out Astro (https://astro.build).
Fresh’s Zero-JS island architecture approach was largely inspired by it.
If you’re interested in something similar for the Node.JS ecosystem, check out Astro (https://astro.build).
Fresh’s Zero-JS island architecture approach was largely inspired by it.
A couple more for folks interested in prior/similar art:
- Marko, made and used by eBay, which had been doing islands/partial hydration for years
- Qwik, made (and I’m pretty sure used) by Builder.io (and one of the original Angular creators), which only loads/executes JS as needed for interaction. Not quite partial hydration, it resumes state serialized into the HTML (sort of conceptually similar client side to Alpine etc)
- Marko, made and used by eBay, which had been doing islands/partial hydration for years
- Qwik, made (and I’m pretty sure used) by Builder.io (and one of the original Angular creators), which only loads/executes JS as needed for interaction. Not quite partial hydration, it resumes state serialized into the HTML (sort of conceptually similar client side to Alpine etc)
I listened to a conference talk[0] where Dylan talks about fresh framework and he says quoting: "We have this little project at Deno ... it's not a web framework that we're really promoting or you know intending to utilise long term. More of kind of a demo of what this post unix web frameworks might look like"
Is it worth investing in this now? It really put me off.
[0]: https://www.youtube.com/watch?v=pBcFJmQ6UVM at 15:50
Is it worth investing in this now? It really put me off.
[0]: https://www.youtube.com/watch?v=pBcFJmQ6UVM at 15:50
Fresh has had a lot of development since then. See the "Production Ready" section in blog post for the latest thoughts:
> Fresh 1.0 is a stable release and can be relied upon for production use. Much of Deno's public web services use Fresh (for example the site you are reading this blog post on now!). This does not mean we are done with Fresh. We have many more ideas to improve user and developer experience.
> Fresh 1.0 is a stable release and can be relied upon for production use. Much of Deno's public web services use Fresh (for example the site you are reading this blog post on now!). This does not mean we are done with Fresh. We have many more ideas to improve user and developer experience.
“Post Unix”?
well many of us think that the excellent ideas of computing in the 1970s (those that produced Unix) are no longer the best ways to do things, and believe that the community should be innovating much more.
a lot of those innovations are over 50 years old, now. do we REALLY believe that the Unix Philosophy is the best thing in the history of computing? past and future? really? I don't. and what about in another 50 years? how about 1000 years? at some point, many much better ideas will emerge.
that's what "post-Unix" means. the things that come after this Unix thing we're hung up on.
a lot of those innovations are over 50 years old, now. do we REALLY believe that the Unix Philosophy is the best thing in the history of computing? past and future? really? I don't. and what about in another 50 years? how about 1000 years? at some point, many much better ideas will emerge.
that's what "post-Unix" means. the things that come after this Unix thing we're hung up on.
This argument is fuzzy. Your goal shouldn't be replacement just because it's old, but rather, because you actually have a more efficient or easy to understand approach.
As far as I can tell, there's a marketing term ("post-unix") but not any concrete ideas backing it. The Ryan Dahl post linked above is equally fuzzy as it seems to just be saying "use an encapsulated runtime for scripting that replaces existing Unix-level dependencies with Web Assembly code that runs on top of Unix."
Not to be rude but it really just doesn't make a lot of sense. Is there a blog post or video explaining the general thesis here?
As far as I can tell, there's a marketing term ("post-unix") but not any concrete ideas backing it. The Ryan Dahl post linked above is equally fuzzy as it seems to just be saying "use an encapsulated runtime for scripting that replaces existing Unix-level dependencies with Web Assembly code that runs on top of Unix."
Not to be rude but it really just doesn't make a lot of sense. Is there a blog post or video explaining the general thesis here?
it means simply that there is always something better, waiting to be discovered, and that we should not let ourselves become acclimated to inferior things simply because we've used those things a lot, and know them.
there is always something to improve. find it. improve it.
still fuzzy?
it is our moral obligation to improve ourselves and the world around us.
I don't know how much clearer I can be.
there is always something to improve. find it. improve it.
still fuzzy?
it is our moral obligation to improve ourselves and the world around us.
I don't know how much clearer I can be.
I agree in general that yes, you should be seeking improvements but is there a specific improvement tied to this term (post-unix)? The term itself implies that there is a concrete idea or set of ideas it involves.
You're over-thinking things. Post-unix clearly just means "something more modern than 70s Unix design". I don't think anyone ever tries to make something newer but not better so that's never a goal.
I'm not over-thinking, I'm asking for a clear definition of what that means. The original comment that kicked off this thread said "what is post unix."
There is a clear-ish definition (not running JavaScript in a Linux container like Docker but running it directly on top of the OS in its own containerized runtime) explained in the linked video that comment was replying to, but no, it's not just "something more modern than 70s Unix design."
There is a clear-ish definition (not running JavaScript in a Linux container like Docker but running it directly on top of the OS in its own containerized runtime) explained in the linked video that comment was replying to, but no, it's not just "something more modern than 70s Unix design."
The way people use modern Linux systems is moving past how most people used Unix systems back in the day. Instead of piles of shell scripts glued together we now use a monolith (systemd) to manage most of the low level services and initialization. No one really cares or tries to setup proper multi-user systems and instead we focus on multiple roots with each application given an exclusive root filesystem, view of the system, etc. (i.e. containerized). Computing is a lot different than it was 50 years ago, and that's not a bad thing.
I interpreted this as politeness given that it’s the inaugural conference of Remix, a direct competitor in the space.
This looks like something I'd like to try but I don't like JSX (TSX). Is it possible to use Fresh with Vue in place of Preact, and write Vue components that split HTML templates from script and style tags?
Yes, same here. Hate JSX/TSX. Would love to have choice of templating engine so can stick to pure HTML/CSS as much as possible. I still prefer simple template engines like Mustache which respect HTML.
You might dig Joystick https://github.com/cheatcode/joystick. Takes the compositional aspects of JSX/React but uses a very thin abstraction over vanilla HTML/CSS/JS to do it.
Joystick is full-stack (UI framework directly integrated with a Node.js back-end framework) but the UI part can be used on its own.
Joystick is full-stack (UI framework directly integrated with a Node.js back-end framework) but the UI part can be used on its own.
You could use Oak with Eta
https://oakserver.github.io/oak/ https://eta.js.org/
https://oakserver.github.io/oak/ https://eta.js.org/
Look at Astro, it's very similar to Fresh but lets you plugin the client side framework of your choice like Vue: https://astro.build/
Sveltekit is kind of similar in style too with single file components containing a script block, HTML, styles, etc. vs. JSX style components.
Sveltekit is kind of similar in style too with single file components containing a script block, HTML, styles, etc. vs. JSX style components.
I tried to like SvelteKit but there was a ton of magic and very, very poor documentation about that magic. Perhaps it's better documented now?
Just curious, why don't you like TSX? I find it much much better than HTML templates because you get actual IDE support with proper code completion and compile time type checking.
How I the experience with this framework in terms of latency? It’s good to reduce front end size but the wire ought to get hot if the browser has to constantly refresh from the server with simple view changes.
From what I gather, it seems like this would be a good choice if a portion of clients are on low end devices and it is more of a MPA/SPA hybrid - not a full blown web app. A lot of E-commerce and informational sites do fall into the MPA/SPA hybrid bucket.
If you really are making a web app (think dropbox, cloud based enterprise software) I think you'd reach a point where there is so much interactivity that you are essentially shipping Preact, custom component JS, and just a little bit of static HTML. The latter bucket is the only one which saves the user network and parsing time (and I doubt much of it.) I'd still go with a properly chunked SPA for true web apps.
If you really are making a web app (think dropbox, cloud based enterprise software) I think you'd reach a point where there is so much interactivity that you are essentially shipping Preact, custom component JS, and just a little bit of static HTML. The latter bucket is the only one which saves the user network and parsing time (and I doubt much of it.) I'd still go with a properly chunked SPA for true web apps.
I hate web development. I swear it's worse than the literal fashion world
All the activity around V8 Isolates + "workers" is so cool-- exceptional performance, don't need to think about regions, and CDN-like benefits
Shopify's new store-builder thinks this way too: https://github.com/Shopify/hydrogen
Shopify's new store-builder thinks this way too: https://github.com/Shopify/hydrogen
The only issue I have with it is that it's a pretty niche application. I think most sites will have a single database probably in a single location, in which case you don't gain anything from edge compute as far as I can tell.
Maybe if these things came with some kind of fancy "edge database" it would cover normal use cases, but they never seem to mention that so I assume it doesn't exist.
Maybe if these things came with some kind of fancy "edge database" it would cover normal use cases, but they never seem to mention that so I assume it doesn't exist.
Single-instance private FaaS (as opposed to multi-instance public FaaS) allow to implement edge databases, assuming there is persistence. Currently only Cloudflare offers this with Durable Objects and the industry seems to not have caught on, maybe not even understood, yet.
We are using the pre release version of Nuxt v3 in production. I really like Nuxt’s developer experience and it is my go-to for front end development. As a backend, I truly don’t pay much attention to whether it’s Firebase + Workers, Vercel, Cloudflare, etc. The framework basically does it all under the hood for us.
I disagree but glad I saw this.
I think as these edge runtime things get more feature rich, it's going to pay off to be all-in on one that does it perfectly exactly optimized with an easy pathway vs expecting third party packages to figure out an implementation and stay up to date.
I think as these edge runtime things get more feature rich, it's going to pay off to be all-in on one that does it perfectly exactly optimized with an easy pathway vs expecting third party packages to figure out an implementation and stay up to date.
What kinds of feature richness are we to expect from edge runtimes? It seems like it’s just like a CDN that can execute code.
> Try Deno Deploy - you will be surprised at the speed and simplicity.
And egress fees ;)
I must say though, hashrock's illustrations for Deno are simply stupendous.
And egress fees ;)
I must say though, hashrock's illustrations for Deno are simply stupendous.
Full stack for Edge just makes sense to be both server, client, and the software that connects it.
Deno will have this with some amazing edge render perfection figured out if you go all-in.
Vercel has Next + Svelte.
Then Cloudflare has "Adaptor" packages and then a simple functions routing folder in Pages (which is def not this...).
I wonder if Cloudflare will regret still not really providing a "Cloudflare Way" of doing things.
Deno will have this with some amazing edge render perfection figured out if you go all-in.
Vercel has Next + Svelte.
Then Cloudflare has "Adaptor" packages and then a simple functions routing folder in Pages (which is def not this...).
I wonder if Cloudflare will regret still not really providing a "Cloudflare Way" of doing things.
I don't know what deno is and it appears that I'm the only one. Does this mean it's not for me? Would I want deno on my tiny 1 visit per hour website?
Maybe/maybe not? Deno is a new-er runtime for JavaScript and TypeScript by the creator of Node.js. It's essentially an effort to correct the perceived shortcomings of Node.js with a new runtime that is: 1. compatible with TypeScript, 2. aligns closer with browser APIs, and 3. comes with a standard library modeled after Go's.
It would be great for a 1 visit per hour site, but so would PHP, or just an index.html file. Hard to really answer that question without knowing what your site is.
It would be great for a 1 visit per hour site, but so would PHP, or just an index.html file. Hard to really answer that question without knowing what your site is.
I keep hearing and reading about Deno too but I don't understand why I or my project would need or want it or consider switching to it. What does it give me, how is it better, why is it better. I'm confused on why I would pay for hosting? You're not alone.
If you keep reading about it and still haven't been able to answer those questions, chances are you probably don't need it.
The strengths of Deno over Node are bulleted all over its homepage, but you likely already knew that.
The strengths of Deno over Node are bulleted all over its homepage, but you likely already knew that.
Client side rendering many cases, could be not only cheaper for the host, but for the client also, when the JS was loaded, the new content for the pages could be fetched faster than the new static html, not to mention the ugly experience of page loading.
Now only get Deno Deploy to implement dynamic imports, so fresh can remove its build step.
Yes, they also firmly keep the claim that fresh doesn’t have a build step. Hint: It does [^1]. They’ve just hidden it for most people by making it part of the local testing.
[^1]: https://news.ycombinator.com/item?id=31723205
Yes, they also firmly keep the claim that fresh doesn’t have a build step. Hint: It does [^1]. They’ve just hidden it for most people by making it part of the local testing.
[^1]: https://news.ycombinator.com/item?id=31723205
Have recently been getting pretty deep into Hugo for a 3rd project and while I love how fast the static sites Hugo builds are. I absolutely hate how every tool I love using takes hours to setup and how it take hours to debug random tooling integration issues between Hugo and node like postcss etc. so much so that despite how much I know Hugo and static sites in general are more often than not the way to go for a lot of things I have been recently reconsidering how much perfect optimization is worth if it takes so much effort to get when something like fresh can deliver what looks like a much better developer experience though perhaps without the perfect optimization
Are there any examples of things made with Fresh available?
I was pleasantly surprised to find that they finally dogfood Fresh for https://deno.land/
Source can be found here https://github.com/denoland/dotland
Source can be found here https://github.com/denoland/dotland
In 2007 I was writing websites that were mostly rendered on a server, with JavaScript used selectively in some places for interactivity
I remember writing at the time that moving everything to the client was solving one problem (poor encapsulation of JavaScript-powered front-end components) with another (needlessly rendering everything on the client)
The industry moved toward CSR anyway, and I had to learn it to continue having a job. And now, here we are.
Why do we do this to ourselves as an industry?
I remember writing at the time that moving everything to the client was solving one problem (poor encapsulation of JavaScript-powered front-end components) with another (needlessly rendering everything on the client)
The industry moved toward CSR anyway, and I had to learn it to continue having a job. And now, here we are.
Why do we do this to ourselves as an industry?
While I know it's not trendy, I'm still building plenty of both informational websites using Umbraco/.NET as well as web applications, using progressive enhancement. On occasion a client will have a concern that requires doing CSR (such as adding an unlimited number of "rows" in a virtual table or similar where a round-trip would prevent them from getting work done in a timely fashion), but for the most part the websites and applications I build server-rendered are very fast and performant. I still use front-end tools for minification/bundling/transpilation, along with caching, to get fast load and execution times.
Because OOH LOOK A SHINY NEW FRAMEWORK!
Because this isn't the same as what you were writing in 2007. This is an improvement on that. There is some degree of chasing what is new, but I think it is more so that all of this is a process of learning which causes the focus to oscillate between different extremes.
I'm guessing it's a bit of a pendulum, this is seen in so many areas of human society. We move in a direction and someone says "we ought to move in the complete opposite way" and so we do, then after some time it is clear this new approach isn't working out and we come back to the other side of the pendulum.
With time, of course, it is likely that we end up in an equilibrium at the middle. In reality, we don't know what we like and what we don't like until we experience it.
With time, of course, it is likely that we end up in an equilibrium at the middle. In reality, we don't know what we like and what we don't like until we experience it.
I just thought of a possible reason. Maybe because the internet is generally much faster and lower latency these days? So rendering on a server can provide a good UX today, but it couldn't in 2007? Was "the edge" such a prominent concept back then? I honestly don't know if this is a good explanation or not, I have no data at hand to prove it, but I think it makes sense.
The "edge" didn't really exist at the time, along with concepts like cloud, serverless. I seem to remember that even CDN was an evolving architecture idea at the time.
AWS et al had not yet turned web servers into a commodity, so it wasn't feasible to "just deploy the software to multiple regions" to improve latency.
AWS et al had not yet turned web servers into a commodity, so it wasn't feasible to "just deploy the software to multiple regions" to improve latency.
Indeed, I love how the front-end world is following the wheel back to server-side. It's like how all the cool kids are dressing like it's the 1980s/90s.
As posted in a similar HN thread: thesis, antithesis, synthesis.
An idea comes up. It solves problems, but it also has shortcomings. An antithesis that deals fixed the shortcomings comes up and is adopted. Turns out it also has shortcomings of its own. The synthesis merged them together.
And repeat.
(these are the ideas from some thinker whose name I forget)
An idea comes up. It solves problems, but it also has shortcomings. An antithesis that deals fixed the shortcomings comes up and is adopted. Turns out it also has shortcomings of its own. The synthesis merged them together.
And repeat.
(these are the ideas from some thinker whose name I forget)
Hegel
If you want speed/performance. Make your website/app cache friendly!
I'm typically pretty hard on Deno (mostly surrounding dependencies), but this is probably an extremely good use-case for it. I might have to pick this up for side projects that need fast iteration.
`deno run -A`
So we're giving up on "it's more secure"?
EDIT: I'm actually a real fan of Deno, but that was never because of its security promises. Security is both technical and cultural, and I think cases like this suggest that while the technical side was always shaky, the cultural side is just as weak. If first-party material promotes the idea of running scripts with `-A`, then that's the direction the community will be led.
So we're giving up on "it's more secure"?
EDIT: I'm actually a real fan of Deno, but that was never because of its security promises. Security is both technical and cultural, and I think cases like this suggest that while the technical side was always shaky, the cultural side is just as weak. If first-party material promotes the idea of running scripts with `-A`, then that's the direction the community will be led.
Security makes more sense for deno when your host your app in serverless v8 hosting environments like deno. They don't even have a way to specify all permissions. v8 isolates are the new cool thing in serverless hosting especially with wasm providing way to run c/rust code on v8. We have to see how this will pan out compared to containers.
Isn't the hosting environment providing the security in that case? I can run Nodejs code on AWS Lambda, and CloudFlare also has their own edge runtime environment which is based on v8 isolates but isn't Deno.
What I meant was that you could emulate locked down version that deno or cloudflare provide in your local during development with the granularity of permissions. I though lambda was a full container running app, did they add isolate environment to it?
Oh I see what you're saying. Yes, while I'm not an expert I suppose Lambdas are less isolated than CF workers or Deno Deploy, while being pragmatically more isolated than e.g. a regular VM.
The issue I have is, if I understand correctly, you need to go to the server for everything. Their sauce is of course that server is close, maybe 10ms away. But it needs to be online, and so do you.
If most things interactive on your site need a round trip BEFORE the interactivity (e.g. a Like button) then this is OK.
However if you are writing a web app which does a lot of stuff offline and there is no reason for it to not work offline then this is an issue.
Where it is a bit sucky is something like clicking an expand button, and needing a network request for basically setting a {display:'block'} style on an element.
I might be strawman-ing a bit there because you would probably chuck in a tiny JS script to do that one job and not religiously follow "no JS".
But I am sure there are good examples of wanting offline capability.
However this is not a showstopper: This model is great for some things, bad for others. It is a welcome new choice in the palette of web dev options.
I imagine it might be premature optimization for many sites though, given that it is a trade off.
If you care about minimal JS to the client, another approach might be to use https://svelte.dev/. I have not tried it, but I am curious.
If most things interactive on your site need a round trip BEFORE the interactivity (e.g. a Like button) then this is OK.
However if you are writing a web app which does a lot of stuff offline and there is no reason for it to not work offline then this is an issue.
Where it is a bit sucky is something like clicking an expand button, and needing a network request for basically setting a {display:'block'} style on an element.
I might be strawman-ing a bit there because you would probably chuck in a tiny JS script to do that one job and not religiously follow "no JS".
But I am sure there are good examples of wanting offline capability.
However this is not a showstopper: This model is great for some things, bad for others. It is a welcome new choice in the palette of web dev options.
I imagine it might be premature optimization for many sites though, given that it is a trade off.
If you care about minimal JS to the client, another approach might be to use https://svelte.dev/. I have not tried it, but I am curious.
Next.js also has no js only server side rendered support in alpha
https://nextjs.org/docs/advanced-features/react-18/server-co...
https://nextjs.org/docs/advanced-features/react-18/server-co...
anyone could convince me why we should use this instead using battle tested framework like ruby on rails or phoenix?
Ryan: let's use web standards
Also Ryan: let's use TSX lol
For me "full stack" is something like Rails, Laravel, Django, etc.
Or is it just being able to run code on the server enough to be "full stack"?
I'm missing the translations system, the validations, the background jobs, the authentication system, authorization helpers, email sending, ORM or data access layer, testing framework, CSRF and related security protections, logging, error handling framework, etc, etc, etc.
To me that's a "full stack" framework. If just running code on the backend and on the frontend is enough, then I can make a bash script a full stack framework, right?