Having that productivity and flexibility without the SPA complexity and other JS cruft has real value.
a. A completely static site with no frontend javascript and no client side hydration, or
b. client hydration in which case all the components needed in the page will need to be loaded in the client.
If you want something in between, ie. only some sections need to be interactive, it requires jumping through some hoops eg. creating separate webpack entrypoints that call ReactDOM.render for specific DOM nodes. It is doable but more work and maintenance effort.
Astro simplifies handling for these kind of islands by using a server side templating language that is component aware and familiar to users already writing jsx.
I mean if JSX is considered as something particularly powerful (not saying it does) doesn’t Vue actually do that https://vuejs.org/guide/extras/render-function.html ?
For static sites, this means that you get functions and objects the entire way through the render pipeline right up until there is a full tree built and the final output is rendered.
You still get all the separation powers of contexts, the component based reusability, etc, and it is all regular JavaScript / typescript except for the JSX macro itself and React's APIs (which are just JavaScript). Conversely, with templating engines like handlebars / erb / et al you need to learn the specific DSL of the template engine- custom loops and controls, imports for partials, and your custom helpers are limited to what they can do. Even Vue's render function has special markup for control (v-if, v-else).
PHP intermingled with HTML was bad because developers would do things like run database queries and other operations that caused side effects directly in the markup. Every templating system still has logic in it, and almost every templating system as a way to create custom helpers which are written in the host language.
Since API calls and calls to react's `setState` are asynchronous, and the rendering pipeline is synchronous, it is still obvious that you can't put code that makes an AJAX call in your html markup.
In short, you can do those things maliciously, but if you do them naively it is immediately obvious when you run the code that it's not correct.
Compare that to the original analogy to mixing raw PHP and HTML templates. Since the rendering process is blocking, you can easily stuff form handling, remote API calls, and database calls in amongst your markup, and can make it "work" even if it's not clean.
Even Laravel's blade components let you write custom components and helpers in PHP which can do all of those things from the template- you just don't see the actual SQL mixed with the HTML in the same file. The problem is still there, just now it is harder to see.
Plenty of people were also taught that proper architecture involved an AbstractGetterVisitorFactoryFactory.
That doesn't make either of those things true.
As a side note, if you find yourself wanting a loop but using `map` isn't sufficient, you should probably be preparing the values ahead of time and still using map. It'll be more efficient, and the code easier to read.
But React (like Vue and Svelte) are fundamentally about interactivity. If I had a project where I knew for sure that I only wanted to generate HTML sans JS on the server (or with a static build process) I wouldn't even consider using React.
It barely even makes sense. Your "React components" would just be JavaScript functions that take props and return some JSX. None of the interesting React features and hooks would even make sense, other than maybe context (and presumably most or all popular static HTML templating tools have comparable features).
<%~ includeFile('./navbar', { pages: [
'home',
'about',
'users'
] }) %>
<navbar pages={['home', 'about', 'users']} />
They can also be async functions that process data independently. Whereas templates are commonly just passed in data from the controller.
If you are building a growing design system with any degree of complexity, React is one of the best tools available.
Is that a joke? You get autocomplete from typescript and props to be fully typed functions, or any kind of object for that matter. That compares to autocomplete that's just some ad-hoc, bug ridden tools that locks you into some IDE or editor, and who cares because all the attributes have the same type (string) anyway.
My bash scripts are often edited, I could not imagine using a compiled language where I would have to store the source as a separate file from the executable, then compile it each time.
I'd love to know your more specific use cases, if you don't mind. I'm always happy to learn something new. Could you share some Rust that most people would script in Bash as an example? What's your build and deploy (to ~/.local/bin I presume) strategy?
> What's your build and deploy (to ~/.local/bin I presume) strategy?
You can run scripts as you would with bash, you don't have to manually build and run the executable. For example, `cargo run (inside the script source folder)` and `sh script.sh` do basically the same thing, end user wise. `nim compile --run script.nim` is similar in that the language compiler will automatically compile and run it together.
> Could you share some Rust that most people would script in Bash as an example?
I was creating dotfiles the other day and I didn't want to use some dotfile manager program as I had some specific steps I wanted to follow, so I started it as a bash script. Well, it got kind of annoying so I made it into a Rust script with some nice features like interactive prompts, text coloring, etc with libraries like `clap`. You can do this in bash of course, but the Rust version was more ergonomic. When I need to run the script, I just did `cargo run` and it worked great.
For instance, my most-used bash script takes a file as input and opens either VIM or Emacs depending on whether the file is a .md or .org (simplified example). I run it like so:
$ n foo.org
$ nim compile --run n foo.org
I'm asking because I'd love to rewrite this script in e.g. Rust, but I don't see any good way to deploy it to ~/.local/bin/n.
eg:
$ code script.nim
#!/usr/bin/env nimcr
echo "hello world"
$ ./script.nim
hello world
There's also the possibility of using nimscript, using nim e. It works similarly but you'd change the shebang line to something like
#!/usr/bin/env nim e --hints:offIn config.nims:
switch("hints", "off")
task hello, "say hello world":
echo "hello world"
$ nim hello
hello world type ADT =
| { case : 'a', a : Number }
| { case : 'b', b : string }
function f (c : ADT) {
switch(c.case) {
case 'a' : return c.a
case 'b' : return Number.parseInt(c.b)
// case 'c' : return 0 // compile error
// case 'b' : return c.a // also compile error
}
}Specifically I can think of parts of the websites' functionality is editing highly technical structured data documents by highly trained domain experts.
I mean basically where years of developer productivity was thrown down a React hole when it could have been months in SGML / XML based tooling for what was required.
I can say that because I have built big solutions in both stacks, though.
I'm not a web dev by trade but I have a website for a hobby project. I had taught myself React thinking I might make an app. (I never did.)
So now I want to maintain this thing on the side with not much effort using what I already know. And that keeps those skills fresh, which is great.
I'm very interested in Astro.