31–40 of 75 posts
> In the past I've also tried Jekyll and Hugo. I found that both work great out of the box, but were hard to customize as I'm not very fluent in either Ruby or Go. Why do people not know about Eleventy, why?
Earlier quoted context omitted.
The post includes the author's reasoning.
Yes, and it's nonsense. "I needed something to convert markdown to html", "I like the component mental model", "I wanted to use Node libraries for date formatting etc.", "Next has a great developer experience" None of these justify using React. It all boils down to "I'm doing it because I can and I'm familiar with those tools".
Why would the author prefer unfamiliar tools in favor of tools they are productive with that produce the same output?
Earlier quoted context omitted.
Depends on what you're building. Client side rendering vs SSR have both different trade-offs and performance implications, and it's best to evaluate which is better for your use case. For a blog or mostly static webpage? SSR is probably the better choice. But there are many times where serving a minified React bundle to the client and letting it do all of the rendering work is better. It's actually a much lower strai…
why couldn't you cache it?
Earlier quoted context omitted.
why couldn't you cache it?
Because it could be personalized content that differs for each request/user.
Nextjs SSR 9.3+ could be the first serious replacement to Rails. Its one of the only frameworks where you can mix Statically Generated Pages, Server Side Rendering and Client Side Rendering. It doesnt have everything built-in, and the fact that Zeit has such tight control over nextjs to be a minus...but im expecting Next (and Gatsby) to some extent to drive full stack webplatforms for the next decade. You have to wri…
It is worth looking into their discussions, issues and so on, doing the tutorial and looking at the roadmap if you are interested in this kind of thing. Very opinionated and they embrace a component based approach with React, GraphQL and so on, while providing useful code generation.
Also this CMS project does a lot of things really well too:
Also pretty young but at a stage where you can use it for real things. Also code generation, GraphQL support and very modular.
But if we're pragmatic, there is still nothing that beats shared hosting LAMP stacks currently if you need a CMS and/or custom backend for a web-app in terms of operational overhead and cost. And it is not like the PHP community was sleeping either. For Rails specifically: It introduced a paradigm shift but both the Python and PHP world caught up very quickly. I don't see a big enough benefit of using either of those three except for the lower operational cost of PHP.
So I agree with your prediction, but we are not quite there yet, or at least not for small to medium projects.
I'm playing with something similar on a side project inspired to Gatsy & Next but for Elixir/Phoenix. I've created a webpack plugin that compiles Next-like React page components into .eex templates and then optionally generates a bundle to "hydrate" the page using assigns from the Phoenix controller. You get the speed/reliability of Phoenix and the (for me at least) power of creating your UI in React without having t…
Phoenix Live View is cool and all, but still not stable enough for my liking. Also, depending on the use case, it can be unviable.
Earlier quoted context omitted.
Because it could be personalized content that differs for each request/user.
You could take a mixed approach. Server render non-stateful stuff, restrict user state to client-side only. You can then CDN cache the public stuff.
Step 1: Server Side HTML -> Website needs to be more interactive. Step 2: Server Side HTML + Client Side React SPA -> Website is now interactive but performance decreased. Step 3: Server Side HTML + Server Side React + Client Side React SPA -> Website is interactive, performance is good but now it's overly complex. Step 4: Server Side HTML + Server Side React -> Let's make it a bit more simple and even more performan…
And less interactive.
I'm playing with something similar on a side project inspired to Gatsy & Next but for Elixir/Phoenix. I've created a webpack plugin that compiles Next-like React page components into .eex templates and then optionally generates a bundle to "hydrate" the page using assigns from the Phoenix controller. You get the speed/reliability of Phoenix and the (for me at least) power of creating your UI in React without having t…
Would you consider open sourcing this? I’d be interested in using this for some of my own projects, having dealt with similar problems to the one you’re describing. Phoenix Live View is cool and all, but still not stable enough for my liking. Also, depending on the use case, it can be unviable.
I have it working with a sample page that renders three dates (static webpack render date, phoenix render date and current date that updates each second with a timer) but I think I need to try it on a real page with real data.
Step 1: Server Side HTML -> Website needs to be more interactive. Step 2: Server Side HTML + Client Side React SPA -> Website is now interactive but performance decreased. Step 3: Server Side HTML + Server Side React + Client Side React SPA -> Website is interactive, performance is good but now it's overly complex. Step 4: Server Side HTML + Server Side React -> Let's make it a bit more simple and even more performan…
Step 3 is where projects end up when they grow sufficiently in complexity and/or features (React specifically is not a necessity but a good solution).
The problems that are being looked at by many of these frameworks, are pushed by the need of being able to use the same rendering and logic, tooling, language and so on for different stages of complexity/requirements.
These are real issues that people worry about and try to find solutions for. On the grand scheme of things these developments are about reducing pain and cost, while keeping up with or driving advancements in user (read: client) expectations.