21–30 of 75 posts
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…
At times like this is when I most think of Svelte’s aspiration, to remove the framework and compile its uses to regular DOM calls. It just bothers me so much with their magic syntax.
PS: Maybe something similar could be made for React Hooks? If a component doesn’t use any hooks it’s marked as static and doesn’t need the framework or to be re-hydrated. If it uses any, we only need to create a discrete React root for that component and its children.
Why do people not know about Eleventy, why?
Is this serious or just a troll post? Because this triggers me a lot. Why wouldn't you just use a normal templating language that render html? Isn't this seriously all the same except you just add a massive dependency for no reason? This is why I hate the javascript community. The only word I find for this is that this is dumb.
The post includes the author's reasoning.
"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".
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…
Is that using Phoenix LiveView? Sounds pretty cool!
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 write javascript anyway in Rails...why not go JS all the way ? And Typescript is definitely a fantastic language.
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".
"I'm using x technology because I'm familiar with it" is exactly what most people should be doing. Many people try to create production sites with tooling they're not familiar with, or take too long learning something new.
Why do none of these justify using React? They probably care about different things than you do.
Is this serious or just a troll post? Because this triggers me a lot. Why wouldn't you just use a normal templating language that render html? Isn't this seriously all the same except you just add a massive dependency for no reason? This is why I hate the javascript community. The only word I find for this is that this is dumb.
Good, it should be server side only.
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…
-> 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 performant by making it less interactive again.
Step 5: Server Side HTML
-> More performant than the previous iteration, also less complex.
You can see that nothing really changed but developers are super happy because they improved the experience all the time.