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.
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.
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.
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.
Isn't DENO just AWS Lambda@Edge but you can't use anything other than JS/TS?
edit: whoa whats with these downvotes? and im being accused of being a troll for asking a legitimate question? I am trying to evaluate this and my comments are being flagged for no reason Dang
This is the second or third time just asking innocent questions on a YC linked company resulted in mass downvotes and flagging.
You're guilty of the sins of conflating orthogonal resources, aggravated by the fact one is a hugely overused proprietary, expensive and absolutely unrelated service, so the downvotes were definitely expected. Then even worse, you're editing posts to complain. Whoever may be contacting you though, here's my fuck you to them.
I don't see choward's comment as offensive/threatened.
They are legitimately asking how the comparison works. You are comparing a web framework and a Cloud Serverless runtime, which is a bit odd. Maybe you didn't have context on Fresh/Deno, but that doesn't mean they are "threatened by the mere question."
I don't agree with the downvote brigading you're receiving but when someone poses a question like this in neutral language, reacting in this way certainly isn't going to help the situation.
Deno is a TS runtime. Deno Deploy is a place on which to deploy a Deno project. Fresh is a framework with which to write web apps on Deno, which then can be deployed to Deno Deploy.
Your question seemingly conflates these three things and adds unrelated elements.
To answer what you might be asking: TS is a nice language and Deno offers excellent tooling, Deno Deploy is easier to use than AWS and Fresh makes it easy to write web apps in a React-ish manner.
My advice is to just ask your question and don't overanalyze the tone of the responses as their tone is related to their interpretation of your own tone/honesty. But if the responses seem weird or unfair to you, it's useful to ask yourself how you might have come off the wrong way.
gherkinnn's response sheds light on why your question could have been misinterpreted as, for example, low effort.
> 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?
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)
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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).
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 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....
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.
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+.
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.
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.
> 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.
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.
Am I the only one that think nowadays anything can be called "full stack"?
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?
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.
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.
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.
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.
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.
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".
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.
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.
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'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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
deno has been around for a little while, i think some commentators may have taken your responses as satirical because of how often deno shows up in conversations surrounding the web platform. think of deno as a node.js successor, it's a separate javascript runtime; with that, it'll need to compete with node's ecosystem (vast and diverse tooling). the deno company is spearheading that movement by creating things like Deno Deploy and now Fresh. i believe the gist of it is that people were excited about the concepts Deno had been brewing up, and now they're building things that will allow people to actually make use of deno.
so, many people will look at this and say 'how is this different from ___?' and the reality is that for the most part, it's not. that's the point. you're making use of deno to do the same thing you did with node, and hopefully it's a little bit easier and/or more developer friendly.
also fwiw, deno is not really yc-affiliated; the company is backed by Sequoia, Four Rivers Ventures, Rauch Capital, Long Journey Ventures, the Mozilla Corporation, Shasta Ventures, and i think some other angel investors like Nat Friedman (former GitHub CEO).
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.
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.
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).
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.
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'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!
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...
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.
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.
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..
"... 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:
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.
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.
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.
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.
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 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.
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.
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)
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.
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.
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.
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?
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 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."
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.
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.
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.
248 comments
[ 2.8 ms ] story [ 243 ms ] thread[0] https://github.com/porsager/postgres
[1] https://deno.land/manual/testing
1. first class styling plugins
2. synchronized island state
3. built in data persistence
https://redwoodjs.com https://www.prisma.io
But yes, I guess if I would need to pick a more mature framework with JS, Redwood would be the way to go.
edit: whoa whats with these downvotes? and im being accused of being a troll for asking a legitimate question? I am trying to evaluate this and my comments are being flagged for no reason Dang
This is the second or third time just asking innocent questions on a YC linked company resulted in mass downvotes and flagging.
You're talking about "Deno Deploy", which is a commercial service based on Deno and by the same company that maintains Deno.
Your comment will look rather nonsensical to somebody who is only familiar with the runtime.
They are legitimately asking how the comparison works. You are comparing a web framework and a Cloud Serverless runtime, which is a bit odd. Maybe you didn't have context on Fresh/Deno, but that doesn't mean they are "threatened by the mere question."
I don't agree with the downvote brigading you're receiving but when someone poses a question like this in neutral language, reacting in this way certainly isn't going to help the situation.
Your question seemingly conflates these three things and adds unrelated elements.
To answer what you might be asking: TS is a nice language and Deno offers excellent tooling, Deno Deploy is easier to use than AWS and Fresh makes it easy to write web apps in a React-ish manner.
My advice is to just ask your question and don't overanalyze the tone of the responses as their tone is related to their interpretation of your own tone/honesty. But if the responses seem weird or unfair to you, it's useful to ask yourself how you might have come off the wrong way.
gherkinnn's response sheds light on why your question could have been misinterpreted as, for example, low effort.
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)
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.
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)
So, y’know, maybe a slightly different ballgame.
Agreed that in the general case 100ms to full paint (with interactivity not far behind) is really good.
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.
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.
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.
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.
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.
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.
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...
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.
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
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).
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 must be too old to enjoy recent resume building architectures....
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)
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.
https://betterprogramming.pub/creating-a-web-performance-cul...
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.
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.
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.
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.
You can use Deno modules in Node using https://github.com/denoland/dnt
There is, however, a Node compatibility layer for Deno: https://deno.land/manual@v1.14.1/npm_nodejs/std_node
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?
However... it's definitely closer to what I want "full stack" to mean than... this. Or a pile of bash scripts.
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 Laravels is pretty more close to a "full stack" framework than Fresh to be honest.
You need to ship at least a few MBs of JS to prove you are a real frontend engineer.
> 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.
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.
> But again, that's just me confused about what is "full stack"
Me too because it's grown into an amorphous definition =/
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.
[1] - https://nodewood.com
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.
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.
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.
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.
You should check out Fastify.
It does solve a lot of stuff for you. Either included in the core or with official plugins.
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.
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.
Aren't those back-end frameworks? I always undestood full-stack to mean "front-end + back-end".
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
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.
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.
My productivity with Rails 7 and Turbo has never been higher.
I don't think Django counts as full-stack, as you don't have a default front-end framework, like Rail's Stimulus.
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.
There's enough confusion here I suppose I'll start using the term "batteries included framework" for the technologies you listed.
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?
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.
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.
so, many people will look at this and say 'how is this different from ___?' and the reality is that for the most part, it's not. that's the point. you're making use of deno to do the same thing you did with node, and hopefully it's a little bit easier and/or more developer friendly.
also fwiw, deno is not really yc-affiliated; the company is backed by Sequoia, Four Rivers Ventures, Rauch Capital, Long Journey Ventures, the Mozilla Corporation, Shasta Ventures, and i think some other angel investors like Nat Friedman (former GitHub CEO).
That was grounds for:
- death threats to my twitter account
- flagging all of my comments
- justifying how i deserved it.
Just wow.
I'm skeptical
Edit:
No, it's only Netlify.
https://news.ycombinator.com/item?id=29003514
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.
[0] https://nextjs.org/blog/layouts-rfc [1] https://reactjs.org/blog/2020/12/21/data-fetching-with-react...
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’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).
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
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.
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
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.
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..
"... 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...
https://jasonformat.com/islands-architecture/
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.
Flutter is awesome for mobile dev. For web? Not so much.
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...
[1] https://jasonformat.com/islands-architecture
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.
- their module/packaging systems are totally different
- their APIs for interacting with the system are different
Deno -> Node: https://github.com/denoland/dnt
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.
- 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)
Is it worth investing in this now? It really put me off.
[0]: https://www.youtube.com/watch?v=pBcFJmQ6UVM at 15:50
> 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.
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.
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?
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 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."
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.
https://oakserver.github.io/oak/ https://eta.js.org/
Sveltekit is kind of similar in style too with single file components containing a script block, HTML, styles, etc. vs. JSX style components.
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.