It incorporates most of these best practices, along with React server side rendering in addition to regular Django templates.
Full disclosure: I'm the creator.
> export const Flavor = () => <Select options={flavors} />;
When I read the above, I fear for the new devs. The number of concepts to grasps and the level of parsing and mind bending to do is incredible.
I used to teach code, before arrow functions and React. And I am convinced I would have lost some students to this snippet, especially the "= () =>" segment.
Are we gone too far syntactically for the sake of compactness rather than understandability, allin the name of (fake, IMO) readability?
Also, consider functional languages like Haskell or whatever. Their syntax is exceptionally foreign for users of C-like languages, and so are the concepts. Still, they're (relatively) widely used.
Haskell though requires significantly more work than JS to grasp, for sure.
Could you elaborate on that, please? The way I read this, I could not be further from agreement :)
Maybe we can find consensus by avoiding the extremes.
"Extended code" as you name it is certainly bad with regards to explicitness, while extreme compactness like (some) one liners are as bad as the former but with regards to readability.
Both are negatively impacting understandability.
I think the target market is experienced people who want to use both react and Django, and feel that this project saves time on conceiving and writing their own integration.
One of the reasons perl faded away, imho
For instance, look how blocks are declared in Objective-C: http://fuckingblocksyntax.com/
They are controversial and everyone has different opinions, but I also think this is where programming ligatures come in extremely handy. When => looks more like ⇒ and is even more obviously an arrow, I think that also starts to make it easier to visually "parse" the flow of code like that.
For what it is worth, arrow functions weren't added solely for compactness, but also to fix some historic issues with classic function syntax. (Lexically scoped `this` versus caller scoped `this` being the big one.) A new type of function syntax was desired anyway for those reasons, and the compact syntax was the icing on the cake.
I haven't had the pleasure of teaching such things to students at this point in my career, but I have given a hand to many a junior developer to grasping some of these ideas and I don't think it is that tough, though it can be a shock/surprise if the last JS you touched was many years before. Especially if you are trying to also learn what JSX and/or TSX add on top of all the changes in ES2015+.
I've seen this pattern a lot recently but haven't figured out what the extra complexity gets you
There's also a _ton_ of preexisting React components you can generally drop in and use, which is less true these days with something like a Django template.
You also have the option of doing SSR and then doing more dynamic stuff on the client side, as a sort of optimization (and plain better user experience than making _more_ server requests to get the initial page state loaded).
Type safety is incredibly important if you're lots of logic in a language, which is why TS is great for SPAs. Does the type safety of TS get you anything if you're just doing SSR with not a whole lot of logic in TS? All of your application logic will be on the Python side of things.
>You also have the option of doing SSR and then doing more dynamic stuff on the client side
Isn't this just the old-school way of doing things before SPAs came around? i.e you render the page on the server and then add dynamics features using JS. I think the new way of doing this is with htmx, hotwire, etc.
The biggest benefit for SSR in my opinion is SEO + first load is fast because its already generated. After that though, its just the plain old SPA experience.
Personally I find JSX to be a terrific templating system, much better than anything like Django's, but if you're familiar with both and prefer Django's, this benefit does not apply to you!
Django templates are perfectly fine as long as you leverage template tags the way they were intended.
Of course there's many ways around this, but doing them in a declarative, type-safe way is not trivial when using Django templates.
Or is it an apples to oranges comparison?
This does make testing a lot easier, as the server response is identical to the hydrated client.
For React, SSR is secondary. For HTMX, it is primary.
EDIT: Looks like the "Concepts" page has what I am looking for. I would add some of that to the front page.
See here: https://github.com/silviogutierrez/reactivated/blob/main/dev...
https://github.com/silviogutierrez/reactivated/blob/main/dev...
https://github.com/silviogutierrez/reactivated/blob/main/dev...
The docs site itself: www.reactivated.io . Notice no JS loaded on the client side. It's purely SSR. The code is in the repo under /website.
My personal blog: www.silv.io
And my business: www.joyapp.com
I don't track others that use it, but hopefully they're out there!