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?
Some of that shifts with syntax highlighting: drawing the eyes to which bits are more specifically related. The arrow => should highlight as a single operator (just as >= does), for instance. Most people call these "arrow functions" so thinking of "=>" as the arrow operator is a habit that quickly builds.
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+.
No. That's perfectly normal syntax you would use every day. It is not sophisticated or special.
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.
If you work with JSX daily, which 99% of React developers do, this is not hard to grok. It's a very typical functional composition pattern in React. Since this framework is targeted at those who want to use React, and presumably already use it, I don't see the issue. It's a snippet to show how Reactivated lets you use the React ecosystem, not how to use React - that's what the docs are for.
I’m not sure that brand new devs who have trouble reading standard JSX, are exactly the target market for a bleeding edge project that combines two popular frameworks together.
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.
Compactness and understandability are the same thing on a large scale or under time pressure. This example is definitely loaded, but compared to more wordy alternatives it just cuts to the chase.
Extended code reads like a narrative journalism. “It was an end to a long dark night and trees shyly stayed in a fog when options in a full entirety of their generous content got passed into a pure functional instance of a select tag”.
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.
I haven't used this particular framework, but having type safety in React through writing TypeScript, generating bindings to the backend so those are typed as well.
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).
Thanks for taking the time to reply, but I'm still not really understanding the benefit.
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.
I think the biggest benefit of SSR is you get the first page fully rendered out (good for SEO), and beyond that page the react SPA takes over by doing all the cool client side stuff like routing and what-not.
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.
It's because React (and other SPA technologies that also happen to work with SSR) is all the buzz. It doesn't actually necessarily make sense. The risk to a project is usually NOT the technology chosen for frontend.
Django templates are perfectly fine as long as you leverage template tags the way they were intended.
A hypertext approach such as HTMX in fact does give you server rendering, since you send to the client a normal SSR page with some extra annotations that add SPA features.
For React, SSR is secondary. For HTMX, it is primary.
You can use the same templates on the backend and frontend. That may not matter to you, at least not now, but it's a great reason in many contexts.
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!
Oh wow, this looks really good. I want to say, what I was really hoping to see is a "how does this work?" section. I'll read the source code, but it would be nice to have a quick narrative explanation.
EDIT: Looks like the "Concepts" page has what I am looking for. I would add some of that to the front page.
Same, I agree with many of the thoughts there. When you get a moment, would you mind writing a guide on how to deploy it to Render.com? It sounds like the Heroku of 2022.
Theoretically, the Dockerfile should "just work"™ with Render.com as well. Right now I focus on fly.io only because their free tier offers PostgreSQL without time limits. Render, I believe, only does so for a period of time.
I too found a lack of strong opinions and recommendations for using Django with TypeScript and modern web technologies. So, shameless plug, I built https://www.reactivated.io . Give it a look if you ever work with Django again.
Disclaimer / shameless plug: I have an OSS project in this space, https://www.reactivated.io, and plan to do a Show HN on it tomorrow.
With that out of the way, I think having more opinionated Django frameworks is a great thing. Particularly around styling and forms.
I also think it's interesting to try to "productize" (I think there's a better word) what is often done as consulting. That is, bottling up and selling experience. So while the price may seem high, there's a ton of wisdom behind it. An experienced Django consultant is easily thousands of dollars per week.
Thanks! I found Reactive somehow yesterday — haven't looked closely at it yet but I will. Always cool to see more stuff in the ecosystem. But yeah, personally I feel like there are few things the Django community could learn (or at least try) from the Laravel (and Rails) communities. I love free software, but it has downsides too! (Like the fact that I can't justify spending all my time on it.)
This looks awesome! Thanks for sharing - I've been looking for a nice django/react starter kit to play with (especially as a less front-end inclined dev). Looking forward to the thread on your Show HN!
I just tried Nix yesterday for the first time in order to play with reactivated. Was surprised by how simple it was to get it running. Made me think that perhaps containers are not as indispensable as I thought.
And reactivated is awesome, by the way. I just worry about how brittle it will be as both Django and React evolve.
Same here. Scandit was the best thing we tested but they quoted us $50k/yr. We don’t have many users that actually need that feature so the next best option was compiling zxing to wasm. That performed a little better than using the js version.
Very interesting article. But I have to ask: would taking down the system for a couple of hours be that bad?
I looked at the company, and while they seem rather large, they're not Netflix or AWS.
I imagine they need to be up for people to be able to check in, etc. But they could just block out the planned maintenance as check in times far in advance. I'm sure there's a million other edge cases but those can be thought out and weighed against the engineering effort.
Don't get me wrong, this is very cool.
But I wonder what the engineering cost was. I'd think easily in the hundreds of thousands of dollars.
I think it's always worth questioning both sides. Why is downtime acceptable? People on this site routinely complain about windows needing a restart for system updates while boasting about their Linux servers uptime.
People talk about how kubernetes is overkill for many people, but it gives you rolling deployments for your applications out of the box.
There's also the "slippery slope" argument. A 0 downtime migration means 0 downtime. A 5 minute migration creeps up to a 30 minutes migration occasionally, and then regression to the mean happens, causing standard migrations to be 30 minutes.
At least where I'm working downtime is acceptable because our customer base is composed of professionals in north america that work 9-5 thus taking the DB offline for five minutes at midnight PST has essentially no cost to our client base. To contrast that, spending three months developing a rollout plan costs our company dearly in competitive advantage.
I agree that it's always worth examining from both sides but I also think that 0 downtime migration is both a shiny interesting problem and a point of pride for developers that can cause a company to vastly over invest in a complex technical solution to a problem they never had.
A lot of 0-downtime migrations end up turning into a months-long ordeal and can still fail.
Allowing maintenance windows means you can do things in a much simple manner. Need to take a snapshot of a DB without running into issues with a production system adding data? Sure, go ahead, you just saved two months.
The principle of something like zero downtime or switching a vendor out to save 20% may not stack up against the reality in opportunity costs, employee burnout, and customer turnover.
My company is reorganizing and so everyone is trying to settle old philosophical debates during The Churn. But everyone is overextended and a number of us have started pushing back. Just the meetings to discuss changing vendors might push the break-even point out 6 months, before you even get into implementation costs. The more time we spend working on infrastructure instead of customer-facing features and bugs, the more likely those customers are to wander off.
I think the slippery slope argument is almost always a fallacy. In practice you can say "we accept 99.99% availability" (which is about 1 hour every year) and budget for that. Your service might go down for unplanned reasons such as an outage but it could also go down for planned maintenance and as long as you're within that budget it seems ok.
Unplanned? Probably. But maybe it's not as a dire as you think? Azure Active Directory (auth as a service) went down for a while, globally, and life went on. Same with GCP and occasionally AWS[1]
I'm not saying there's no downside, I'm asking against the downside of engineering cost. And that itself carries risk of failure when you go live. It's not guaranteed.
[1] AWS is so ubiquitous though, that half the internet would be affected so it makes it less individually noticeable.
So don't host on AWS, wait out their next big outage and then take down your app for that big migration, so you can hide among all the other dead apps. Half joking, of course.
OTOH I worked for several small companies that had "business hours" software - if you had to take downtime on the weekend or after hours you'd be looking at impacting <1% of users.
It absolutely is, BGP with geographically diverse paths, databases, app servers, etc, are all redundant. It's hosted in-house, so there is a cold standby database in AWS which would only be used if, say, an aircraft crashed into our server rooms.
We have everything in place to run from AWS if needed but do not operate from there because of cost.
This goes both ways -- there have been many AWS outages which have not affected us. I hear what you're saying, but we've had only one instance of extended (hours) downtime in the last 20 years.
The more experienced I become, the more such down to earth solutions seem OMG SO MUCH MORE reasonable than all the bells and whistles of "modern" engineering practices.
For postgres we send WAL files to a server in AWS which processes them. To bootstrap the database initially we sent zfs snapshots, and those WAL files are applied on an ongoing basis. If our data center were to die a horrendous fiery death, we could lose, at most, about 3 minutes of data although monitoring shows that it's closer to 30s under normal operating conditions.
For the app servers, saltstack is used and we synchronize that repository with what is needed to reproduce a production environment in AWS.
Obviously we'd have to provision servers, etc, but it's all possible in a worst-case scenario.
pg_upgrade with --hard-link option will upgrade the db in mins, I've done a 2TB db in less than a minute.
Yes, there is no rollback, but if you do enough testing prior it can be really smooth. Am in the middle of doing this across an environment where we have tens of hosts from a few GB to couple TB.
The problem happens when you estimate it will only take a few hours and at the end of the first hour it's 1% done, or it nears completion and crashes, in a loop. Now what?
A few minutes of downtime wouldn't be that bad, but it would harm the company's prestige. Unlike AWS and Netflix, we are not based on massive consumption, but on a few customers. Losing one good customer can make a difference. We believe it worth the investment of time.
Update: The cost is a good point. It wasn't that high. We actually updated the article to reflect this. It was two engineers, working full-time on it, for three weeks.
Do not use a blocking modal. Ever. Gracefully insert it so the user can finish whatever they were doing, but still see your prompt. So a banner that slides in below the title, or at the bottom, etc. It is not overlaid. And can be dismissed at any time.
That way, the request for feedback itself is not a negative, jarring experience. This is what I did on https://www.joyapp.com and had very positive results.
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.