Am I the only one that sees the "do not use in production" warning as a challenge? ;)
Fresh – Next-gen web framework
301–310 of 463 posts
Re: Fresh – Next-gen web framework
#302Earlier quoted context omitted.
Why not both? Certainly everyone who creates a (somewhat serious) web framework is at least aware that they could also participate in the development of an existing on. If they feel there is something to gain by going from scratch, why not? I don't think the popular existing frameworks exactly suffer from under-contribution.
The incentives here seem strongly skewed towards having your name on a new framework for career purposes rather than improving the ecosystem at large
That seems wrong, intuitively. If anything, having meaningful contributions to a long standing project go through should relatively advance your cause, not hinder it.
Re: Fresh – Next-gen web framework
#303Slowly getting somewhat cynical. This is the only space where both "prebuilds everything and therefore saves rendering time and improves caching" and "no build step and so speeds up deployment" are both considered valid feature pitches.
On the last decade and half the entire group mind of the computing discipline switched from "no build step will speed-up development and deployment" into "a heavy build step will speed-up development and deployment". So, it's not like the web developers were going at it alone.
Anyway, the change happened because of real environmental changes. Developers everywhere didn't just wake-up and decide their old values were the exact opposite of the truth, both opinions stand on valid models of the world and hard-acquired empirical information.
Re: Fresh – Next-gen web framework
#304Earlier quoted context omitted.
I've actually worked with things like Create React App, Vue CLI etc a lot but never any of the "meta frameworks". Based on what you are saying, it seems like the main difference it where things are evaluated? So, if I do my filtering on the client (with React) I need to make a request, get all the data, filter, render. For something like Remix or Fresh, you can do it on the server first [0]. Either way, the user has…
For responding to user interactions (like filtering or searching) there isn't really a significant difference; like you said, it's just moving the "wait" elsewhere. But many sites are more heavily read than interacted with: blogs, news, documentation, even to some extent HackerNews and comments. These are all "write rarely, read often" sites. In those cases, prerendering can be way faster both for the end-user (it's…
I hate Drupal as much as the next guy, but I have to defend one thing about it: it doesn't have to be slow, and it doesn't have to have jQuery. Just get rid of all of the bloatware that comes out of the box, and then don't solve every problem with a plugin/module. I know, a 3rd party module for every little thing is exactly how Drupal development looks in most companies. Sorta like jQuery a decade or so ago.
Anyway, with a bit of discipline and some frontend tricks (preconnect, preload, async) you can create a Drupal page that's super fast. And it would actually serve less code to the end user than a page based on JS frameworks (as all things happen on the server).
Example: https://www.magneticpoint.com/
Re: Fresh – Next-gen web framework
#305Earlier quoted context omitted.
> No, that's a requirement on most business cases, my comment stated 'complex and dynamic web apps'. Re-rendering the whole page everytime the user checks a box or clicks a button just to replace some fields in a whole page is (a) terrible UX, (b) hard to track the state between page refresh, (c) wrong practice and (d) bad performance. You can have the backend render partials and only send the affected part. This has…
> Except for cases where the team doesn't know anything other than JS, using this is significantly simpler than forcing the whole backend to be in JS. Also, there are several other options. Of course you shouldn't use a full-js stack if your team of developers doesn't know JS, no one is arguing that because it doesn't make sense.
I never claimed you argued for that. I'm simply stating the cost of each solution. Thrift is definitely much simpler in practice in all cases, except the case I mentioned as being an exception.
Re: Fresh – Next-gen web framework
#306Earlier quoted context omitted.
For responding to user interactions (like filtering or searching) there isn't really a significant difference; like you said, it's just moving the "wait" elsewhere. But many sites are more heavily read than interacted with: blogs, news, documentation, even to some extent HackerNews and comments. These are all "write rarely, read often" sites. In those cases, prerendering can be way faster both for the end-user (it's…
I hate Drupal as much as the next guy, but I have to defend one thing about it: it doesn't have to be slow, and it doesn't have to have jQuery. Just get rid of all of the bloatware that comes out of the box, and then don't solve every problem with a plugin/module. I know, a 3rd party module for every little thing is exactly how Drupal development looks in most companies. Sorta like jQuery a decade or so ago. Anyway,…
Yeah but next gets you the same benefits without needing PHP or a DB (for the frontend). Drupal requires a LEMP stack, which is both hard to maintain and hard to scale/replicate.
You still need a place to store actual content/data, of course. But that could be any store or service that gives you an API endpoint to fetch from.
Re: Fresh – Next-gen web framework
#307Earlier quoted context omitted.
Quoted post unavailable.
The difference is that it doesn't take 600ms for a Rust binary to render "Hello world!" to stdout. In the context of CLI apps, binary size is irrelevant to the functionality of the demo. In the context of web apps, bundle size and speed _does_ matter, so 108KiB and 600ms are very relevant data points. Besides, I'm pretty sure that in this framework's case the final bundle can also be trivially stripped, but would tha…
I know this comparison isn’t exact, but I didn’t attempt to engage with the supposed latency measure. That kind of measurements are really variable and hard to pin down. You’d need percentiles to make even an uneducated judgement, not a single random sample.
Still… a 100KiB bundle is not that bad of a starting point. It objectively isn’t, if you measure it up to other popular frameworks.
Re: Fresh – Next-gen web framework
#308Earlier quoted context omitted.
For responding to user interactions (like filtering or searching) there isn't really a significant difference; like you said, it's just moving the "wait" elsewhere. But many sites are more heavily read than interacted with: blogs, news, documentation, even to some extent HackerNews and comments. These are all "write rarely, read often" sites. In those cases, prerendering can be way faster both for the end-user (it's…
Given all the benefits you have listed, would the next big bottleneck to solve be the backend? I think it would be better to reduce/get rid of JS/Node and move on to server side Julia or C++.
For that simple page, the backend is a headless CMS that the vendor maintained. We just put content in and get GraphQL out and did not have to worry about how they hosted at all.
Re: Fresh – Next-gen web framework
#309Earlier quoted context omitted.
I'm not an Uncle Bob fan by any stretch of the imagination, but he wrote a somewhat famous article about this phenomenon: http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html With each new wave - we get people that either lack the time, the willpower or the conditions to understand what came before them (the ground they're standing on), and this is how we end up rediscovering things every 2-3 years. It's much…
I've been doing both, or rather different kinds of combinations from almost full PHP to PHP with jQuery/Backbone/Angular, and since a while React SPA to Node based including Nextjs. Also just using dependency less JS and htmx as well. All depending on the scope and requirements of the particular projects. For side projects I've built stuff with quite few other languages. This is for professional context. My conclusio…
Cost is a big reason in many countries. PHP is still the cheaper option for dynamic websites. Shared webhosting costs peanuts.
Re: Fresh – Next-gen web framework
#310Earlier quoted context omitted.
> Rehydration is a really big deal. Sounds dorky but it dramatically speeds up load times and such by serving flat HTML and injecting JS afterward, like the old days, except you can write code like it's not the old days. Hydration is actually a compromise, and not a great one for UX. It’s in fact been said to be “pure overhead”, which I think is an overstatement but only slightly. What you’re describing in the abstra…
> Hydration in the current sense is re-running most of what the server already did, to recreate the runtime state it already had. It’s interesting that the problems with hydration is in some sense caused by the insistence on one-way data binding (deriving the view from the state). I imagine that with two-way data binding then you’d just need to attach event handlers and then the state would be derived from the view o…
I’m not sure that gets you much. You still have to know which parts of the code are implicated in executing those event handlers, which very likely close over other state and call into other logic. To an extent you can get that with static analysis (as Qwik does, with one-way binding), but highly dynamic code is tricky no matter what.