Show HN: Django and React SaaS boilerplate tutorial
github.com
github.com
ie.
Their approach in accounts models.py:
https://github.com/saasitive/django-react-boilerplate/blob/m...
Over the standard approach in their notes models.py:
https://github.com/saasitive/django-react-boilerplate/blob/m...
[0]: https://docs.djangoproject.com/en/3.1/topics/auth/customizin...
Does anyone have a solution they like for this kind of isomporphic Django problem?
I've done as you describe, separate Django views have different client components and those components import subcomponents which are shared as needed, throughout the site. I just have the webpack build each "root" client component individually, and you can separate subcomponents into libraries.
You can even have multiple react apps rendered into their own containers that do not share state as long as you separated them cleanly.
I wanted to bring a single react app into the django project using a root dom element from a django template using the same template inheritance as the rest of the site. (common navbar)
Benefits of this approach on Django side were adherence to Django structure and session-based auth for the react app's API calls.
My goal was to minimize customization while retaining the "spirit" of both Django and react.
I decided the react app should flow from an unejected Create React App (CRA) project. This provides the developer experience of CRA's development environment hot-reload and production build bundling.
It also makes it more likely the react app can be migrated to new versions of CRA.
The webpack config changes needed to pull this off are not extensive but do leverage Create React App Configuration Override (CRACO). [1] CRACO is the best-supported config layer for CRA today, supporting CRA 4.*.
Key aspects of my implementation are:
- Use of package.json poststart to move files generated by CRA's run script and update paths made by CRA-generated files to work inside django.
- Use of the package.json postbuild script to move and rename files to nestle assets into their proper place in a django static path.
- Customization of HtmlWebpackPlugin to modify CRA's:
- Out-of-box behavior of webpack bodyTags and headTags.
- webpackConfig.output to use a project-excluded directory that facilitates hot reload during dev
Being relatively new to modern web front end toolchains I ended up rewriting much of the of the user documentation for CRACO as part of my learning process for this mash of Django and React. [2]
I have not released my solution but I have stubbed out the problem and solution description [3].
If someone is very much in need of this project, please write me. I have wanted to release it but have just not had time yet, and I need to update it to CRA 4.
All this said and done, having accomplished my initial goals, I am less certain now that it is worth trying to integrate a CRA-app into Django, at least if the goal is to retain shared sub templates from the rest of the Django app.
Instead, I suspect the better method would be to expect to have to maintain a react-compatible implementation of say a navbar or other "common" portion of the UI on the server-rendered pages and leverage only django's session auth on the SPA.
Ultimately, this integration experience made me take a hard look at my investment in Django. I know and enjoy python and the Django framework. But at least for new projects, I can't help but feel they faces an existential threat from modern web (react) paired with a node backend.
[1] https://github.com/gsoft-inc/craco
It's untyped, messy, buggy, inconsistent, ugly and altogether a pain in the arse to use. Yeah sure it's "simple", but working with React and Typescript is a million times healthier for any sort of workload.
And if you really want to do an SSR'd app and don't want to go the SPA route, there's better alternatives to Django IMO (Flask for one).
A product manager may establish customer demand for an experience on the site that a react SPA would facilitate very well.
The org may want to dip its toe in react without throwing out or re-writing vast, stable aspects of the site that may also need ongoing changes.
However, the Django admin system is extremely powerful and saves you a HUGE amount of dev time. Every single saas product needs an admin interface from an operations point of view. I haven't seen anything out there that is better than Django Admin.
Currently I still use allauth for social authentication, though I'm not a fan of how little flexibility I get with it especially in such a setup (it makes a lot of assumptions about a template setup).
The other weakness in this stack is the lack of API typings. I haven't bothered messing with OpenAPI yet; I probably should but I understand that it's not a silver bullet in terms of typings either, so I just end up writing my own types for the API and it does become a very repetitive maintenance burden…
There are some new ones coming on the scene, like Dino and Tortoise, but nothing mature.
Jinja templates at least let you use normal python syntax in the tags. You can easily do something like {{ items.filter("books")[:5] }} — in Django, you would have to write a special accessor or template tag to call filter("books") as it doesn't let you specify arguments to function calls, and you'd use the awful |slice:":5" to slice it.
But more than anything else, Django templates are not just untyped, they are untypeable. You can't really validate them. Best you can do is try to compile them in a CI job see if anything fails. Not to mention that the way you're outputting HTML essentially arbitrarily anywhere in the page means there is no way for the editor / tools / even yourself to know if some piece of code is syntactically or semantically valid in context. Got a list_item.html with a naked "<li>{{ item }}" inside? Why the fuck not! Could even be raw css or js outside a tag in your template, could be valid in some includes, invalid in some others. Everything goes. You can't even know whether a template is in use, as it's completely arbitrary code that calls these template inclusions, via string filenames (which therefore can be included however you want).
It's impossible to create these problems with react/typescript. And react heavily encourages code reuse: creating reusable components that are as small as possible. Django templates encourage copy-pasting.
1. Deploy the React static pages and JS/CSS resources completely separately from Django. Cloudfront/S3 is my personal choice. You will need to tweak the CORS_ORIGIN_WHITELIST and CORS_ALLOW_HEADERS in the django settings but that's relatively easy.
2. Use Gatsy or something similar to help you with static site generation using react. Remember: React is in charge of HTML/JS/CSS of any type and Django should not get involved.
3. Use https://github.com/ctrlplusb/react-async-component or something similar to help break up your SPA so the browser doesn't have to load all of it at once and only loads smaller components on an as needed basis.
Don't mess with webpack and eject unless you have a very specialized need that cannot be addressed with everything out there.
Once we had proved that this improved the site, we went all in and started to use the "proper" way, building the JS and deploying to a CDN.
In parallel to this we set up Django Rest Framework and set up alternate routes to fetch the view data as JSON.
In retrospect I would probably skip the hybrid system and just start building view components, but it was done this way so we could more easily revert if it didn't work out.
why?
Django's frontend rendering is still a major part of the framework, so advising everyone not to use it in a post about Django is a bit misgiving.
Having something cohesive is much more reliable than having some template there, some js there, some template there again.
If you stick up to one way of doing things, testing and debugging becomes trivial because you are not mixing up three different way of doing something
Can you give me a solid usecase of why not to use djangos templating and use - as per your example - an SSG?
Seems like the usecases are edge cases. Why use Django just to make api calls when smaller and nimbler alternatives abound.
Its no wonder React devs command such a strong hourly fee. They'll mostly be fixing dung with more dung and hooks.
Pardon the rant. Im at a job where no one seems to be listening to my case against react when plain whole JS would do. The code will be verbose but there is no magic or illusion. Anyone from junior intern to senior dev can understand the codebase without much help. Its not that big either.
grrr
Django has lots of stuff besides the template system, in particular the admin, authentication, and ORM which allow rapid iteration and getting your product into production.
After some growth though, you may find yourself constrained by the framework: a mixture of difficulty implementing functionalities, performance problems, and organizational/deployment problems (i.e. several teams wanting to deploy simultaneously).
Around that time you'll probably start looking at taking your (obviously well-designed) monolith apart and peeling off the business domains out into separate services. Maybe rewrite some parts Go or Rust? Anyway if you use the template system, you'll have a much harder time doing this than if you're only slinging JSON around.
Another advantage is that you get right from the start is having the ability to modify purely display parts of the UI without having to touch the back-end, it doesn't sound like much but is incredibly useful when prototyping/testing new ideas.
For an SSG though, for me that's the wrong use case. For that I would use Zola which is incredibly fast and uses a template system that's basically a Rust port of Jinja, so a Django developer is right at home.
IME (not a senior dev) it's easier to turn the entire front-end over to React. I don't want to rebuild the wheel and write custom CSS every time I need a new component. I want to be able to plug in common components, with unsurprising and predictable props. If I'm already using React for dialog boxes, it may well as handle my click handlers as well. Then it can also grab data.
I agree with the spirit of avoiding more dependencies though and for this reason I try to avoid Redux. I find React absolutely invaluable for styling and reusable components however.
You are telling me it is worth migrating to a new architecture/build with all the overhead just so we can have less time writing custom css? Surely you jest. Devs should not define their jobs as cookie cutters. We use common stuff as a base to start work on the customized business facing solution yo.
I've seen some custom PHP production codebases with plain css and jquery doing its thing with 1x10^6 plus weekly traffic. It was a pleasure to read and figure out. I could throw an intern at it and he would figure it out. Verbose as hell too.
I've worked on plenty of those. I've handled more traffic with uglier shit, too. This isn't a performance thing, nor is it a premature optimization thing. It's about developer productivity.
Refactors are faster. Components are easier to break down. Bugs are easier to catch at compile time. Some classes of bugs are entirely avoided. A LOT of UI logic makes a ton more sense when written declaratively (as React forces you to), than imperatively. And none of that is even getting into the realm of how much easier it is to find devs who will work on a ReactJS codebase (and even more so, will be happy to do so).
My field Python experience surpasses my Typescript/React experience easily 50x. And yet, I'll be much faster at picking up a new client's React/TS codebase than their equivalent Python one. The productivity gains are real.
Plus, you may have gotten lucky with that app, but that’s very often not the case.
I don't know your job, your coworkers or your context. You may be right… probably not, though. React is a powerhouse in terms of developer productivity.
I have 17 years of software engineering behind me, and while I dabbled in a lot of things, most of these years have been spent using Python (and Django). And the current typescript+react ecosystem is several orders of magnitude more productive than anything else I've ever used, be it in Python or any other language.
You say "overcomplication", but React is far, far simpler than Django's template system. You're basically throwing away a LOT of overly complex shit that is simply there to generate HTML in non-html. React generates HTML with actual HTML -- well, okay, JSX/TSX is not technically HTML, but it maps perfectly where it needs to, and still gives you that added layer of typing for extra safety. React can't generate invalid HTML, and if your app compiles, you won't ever have a client-side syntax error.
I can't stress how bad a tool Django templates are for the job of generating HTML.
Oh and JS without React? I mean, sure, if you're literally just adding a couple of dynamic elements on a mostly static site. If you're actually going to have JS-driven UI elements in a dynamic interface, just use React. Not saying you have to, but it's probably the correct choice.
There's a lot of purists out there who will cry foul at 50kb more of some gzipped code, but do you want to spend your time tweaking and manually testing imperative UI behaviour for all your little widgets and how they interact with each other, or do you want to be productive?
Feel free to email me more context on your situation and I can give you a more specific assessement … but my €.02 here is, spend some time learning react & typescript, and playing with the more useful bits of it (NextJS+Typescript). It's not time that will be wasted either way. Give it a week and re-assess.
But it's the best of both worlds: Django SSR using statically typed JSX.
See for example my blog or business sites (on profile). Both SSRed by Django using React templates.
Then when the client loads, it gracefully "attaches" for dynamic interactive behavior as needed.
By far the biggest pain point is having to run node and python on the server. So I'm working on the best way to do that.
What we want from something like react after all is reactivity, and it's possible to get that if you were to use something like https://github.com/jonathan-s/django-sockpuppet
So if you've got an open mind and want to test it's there for the taking.
More details on this approach here: https://www.saaspegasus.com/guides/modern-javascript-for-dja...
It’s a tool that solves very specific issues that most people won’t have and often adds quite a bit of complexity.
Off the topic, I mainly write in Python. I started programming in C/C++. I very often miss header files from C/C++ during Python programming. In C++ header files you have the full interface definition and it was easy to understand the code. Somehow, the redux and C header files are for me similar (in the sense of clear code).
https://create-react-app.dev/docs/proxying-api-requests-in-d...
Is there anything on the Demo page (https://boilerplate.saasitive.com/) that would be different?
In my experience as a user, everything that uses React is always an annoyance in one way or another. But I am happy to understand if there are legit use cases.
Otherwise django + react makes sense when there're different people (or teams) handling the frontend and the backend.
The boilerplate code runs with docker-compose on single server but in the future the frontend and backend can be easily divided, so separate teams can work on them.
The typical hn startup is expected to grow to that size, to an enterprise scale, so you’re not going to see a lot of people use Django.
Can you list one annoyance you see as a user with React?
- Should use the django-env package to have a generic settings file
- Models are incomplete
- Where does registration happen? In the backend? Fronted?
- Weird code around the user model
- Unused imports
Overall this needs some polish in order to be a strong boilerplate solution. I’d say request code reviews from the community in order to improve it. Also think about using cookie cutter for it as well.
Coming from academia/data science and learning this from the scratch, the python backend + js frontend boilerplates are quite cryptic. The tools for sure seem useful, but there's a lot to grasp for a noob - rabbits, celeries, and so on.
There is a docker-compose provided to set up and run this boilerplate application on single server machine. It can be easily adjusted to your needs.
I think the Django admin is great, I use it a lot and recommend it for new/small projects, but it's tightly coupled to the Django ORM which can be restrictive in some usecases.
I would maybe use this if it was Django and React only, there are many things in the tech stack which I just don't want to get into.
For example, I would be happy with sqlite instead of postgres. I'll migrate if sqlite ever gets near capacity.
Adding Postgres to a Django project is like 20min of config... And it doesn't really modify the API, it only supersets it.
Using SQLite on a production environment and only migrating up when you fill it up sounds like a big wtf
These services all support your choice of front-end and back-end programming language. All these providers also allow hooks into features like security, database, apis, ci/cd, and so on. You would be in a serverless architecture also which provides scalability and keeps costs low up front. Not trying to discredit the author here, which is admirable in the intent, but feels like it's trying to solve for something that several other solutions exist for unless I'm missing something critical.
But I hope some of HNers illuminated me.
I don't do React/vue .
Only SRR + some javascript (modals, effects, etc).
What I am missing? Serious question, Am I missing TOO much or maybe 20% productivity?
1. I am a one man shop doing Django sites, SRR only. When I need to interact with front end for more "Reactivity" I use javacript + a view exporting json.
2. About admin: It is good for me or the operator but I dont feel like my user should be using it?
Then I do my own "admin" for the customer.
Please what I am missing?
The #1 I feel once you have 2-3 they may make sense (separating functions).
The #2 the community answer was : "Not for user, only staff or operator and not for general consumption"
I would glad hear your points.
Thank You
The best of both worlds is a static site sprinkled with React components where they make sense. Angular can't really do this, but react is designed to work in parts of pages.
So if your customer wants one really crazy sortable filterable list view you can do that in clean react code instead of a bunch of jacky jquery
a) react/svelte/next/nuxt/gatsby/sapper/angular for apps;
b) django/rails/express.js for sites;
after this week's release of React Server Components I'm feeling even more convinced that having 2 tools to tackle different ends of the problem is better than trying to make 1 tool fit everything.
Would live to share quote from https://news.ycombinator.com/item?id=25358976: "I feel like we're in a transition period where we will eventually get both the nice developer experience and flexibility combined with nice performance".
Am wondering if anyone tried to bundle vanilla js for dom manipulations alongside server-rendered react componenents which deliver html+css server-side. Where do you put js code inside the component folder? What are the patterns and best practices of using react only for html+css composition and using vanilla js for interaction? Thanks a lot for any tips!
With regard to the admin, my experience is that usually the customer will have specific tasks that they need a workflow for, and the admin panel is often not a good fit for that (and things get messy quickly if you try to bend the admin panel to be something it isn't).
After a week of wasting time due to needless complexity caused by React (I don't want an SPA), I took React out of the loop and got on with actually developing features that are needed. I don't feel like anything is missing from the final product nor am I missing out on any productivity gains that would be realized after my initial learning curve.
Having said that, I don’t know enough about your use case to say that react is a better choice.
Having a React / Vue whatever in addition to your Django server allow you to split the "View" from the "Model-View-Control" paradigm that Django respect, when you have django & react, Django is only "MC" and react becomes "V"
Simply put, when you are in the template paradigm you are producing HTML files, when you are using React you are generating HTML.
For instance, I'm not building up an "account" page, i'm building up a "detail" page that can be reused with a query that I'm passing in. That query is a function that defines the call to Django. Eventually I'm passing parameters to the component to drive it's behaviour.
I'd simply suggest you to go learn some react, it is difficult and it takes time, but it will allow you to see more solutions to problems that you might be handling in the "industrial" way (eg: writing 10 templates and having some jquery mixxed in the html)
I've been working with django and react for a while now, and i'm now used to 100% coverage without much hassle and very good productivity (dare I cite my boss :) )
A framework is an opinionated piece of code that helps several people understand the code everyone is creating.
If you are alone, the need for a front end framework is equal to 0
something like nextjs - with built in frontend+backend is ideal.
Is it any more difficult to destroy your database in Django DSL than it is in raw SQL? We're using a lot of raw SQL at day job, and the two junior developers on our team who had no priory experience of working with SQL databases at all have picked it up just fine.
In my opinion, JS development is unpleasant because of the many, many inconsistencies and corner cases that must be accounted for when writing code, the dumpster fire that is the npm ecosystem, and the lack of established frameworks like Django. Things like TypeScript make writing code less painful, but I only use JS when I have to (i.e. I need something to execute in a browser).
> something like nextjs - with built in frontend+backend is ideal.
This is completely subjective, and I would disagree.
You suggested using nextjs for the backend. This weeks flavor of nextjs database connections is to be done with Prisma. Setting the two up together is no walk in the park. So great, you’ve spent a week setting up Prisma and the layers which connect it to your API. You’ll probably now task yourself with connecting the database to a GraphQL API with a Playground (another week). What about auth? Hand roll of reach some the suggested Auth0 library for nextjs. Another week of integrating. You can see the pattern. Meanwhile, the Django user has everything setup in day one, nextjs app for front end only deployed on day 2, and is building user features day 3.
We haven’t even talked about setting up request middleware, integration with logging tools, distributed tracing, exception aggregators, sending email, scheduled background tasks. Which you can spend another week for each or just go to your battle tested framework of choices’ doc page.
My comment is in context of this project and not a generic statement. My startup is built entirely in python.
A boilerplate - by definition is a get started quickly tool for people that are (by choice or otherwise) not interested in going to the depths of a framework. In that very particular context, a Nextjs based boilerplate will beat this one.
As an example, let me share a nextjs template that you can buy for 20$ https://themeforest.net/item/react-material-bootstrap-4-admi...
https://themeforest.net/item/react-next-modern-landing-page-...
again, im not trying to crap over the OP's attempt. I seriously commend it. But if there's someone looking for a boilerplate to get something with a frontend/backend up and running quickly...i still do think doing it in one language/framework is much better.
P.S. And I do think TS is a fantastic language. But again, my point was not a purist Python vs TS/JS slugfest
If I needed a full webapp spun up quickly (db, auth, api emails, etc), I'd choose Django before Next.
e.g. https://nextjs.org/commerce
here's one with Firebase auth, graphql, everything already setup https://themeforest.net/item/livani-react-next-ecommerce-sto...
Next itself does not help you with Firebase or databases or any kind of persistent storage. It's entirely left up to you. That's a huge difference from Django, Rails, etc. The same is true of auth and many other things.
Firebase is also a third party backend.
Any recommendations on one where you can own the backend yourself, like Django? Without composing all the pieces manually?
I'm currently running a Django backend, Vue frontend, and think Django is a fine tool -- but occasionally look for a nice cohesive Django alternative in the JS world.
The general result is that the code quality is very low and the class names are not specific enough, so you get bogged down in css when you try to customize things.
Fool me once ... fool me twice ... fool me three times ...
Reasons being, that nextjs&friends(hydrated site alongside js-based navigation) make it:
a)impossible to do decent a/b testing;
b)impossible to do decent personalizations;
c)impossible to have decent page load times;
d)impossible to have any decent web analytics;
e) team is unable to understand what's going on with a page after looking into source code - devs get more control in expense of ppc teams, ux teams, cro teams, analytics teams, data teams, sysadmins, monitoring teams. This is the biggest killer argument even though a)-d) arguments might seem fancier at first. Sooo many devs just can't ever relate to this, because yes - reactgasm is a strong emotion. But you have to think about others. Devs can survive jquery. Marketer can not survive react.
So You just stick to css+html+vanilla js+web components(svelte or stencils or whatever). That is based on my 8+ years working as a marketer/product owner building billion-grade ecommerce projects.
As you have not spent too much time on elaborating your points but throwing out strong opinion to the wild, I will do more or less the same.
Happy to discuss in comments though :)
Doesnt react have like a massive ecosystem of integrations around this ? for example Optimizely - https://docs.developers.optimizely.com/full-stack/docs/javas...
what do you think ? i mean i dont like kubernetes...but the ecosystem is already there right ?
Which, if you look at it closer - "'dataLayer',4000," 4000 ms mean that you basicly make your website white blank for up to 4s while all the ab testing loading stuff is happening behind the scenes.
And this makes your initial load UX a very very awkward experience.
If personalization / ab testing is happining on load-time parameters (i.e. country), well, you are in a situation where I have mentioned hydrated site is out of options to be considered for the stack selection.
That's when you either try to go this way with gatsby: https://www.gatsbyjs.com/plugins/gatsby-plugin-no-javascript... .
That's when you are stuck with sapper: https://stackoverflow.com/questions/64507516/how-to-disable-... .
That's when you end up in tickets like this with Nextjs: https://github.com/vercel/next.js/issues/4381 . And never look back.
Take a look at my top comment of https://news.ycombinator.com/item?id=25342767 for more details.
I’m working on a simple internal enterprise app for managing document workflow right now. It should just be a basic CRUD application maintained by 2-3 devs at most. Because of how it’s architected (extreme normalization on the backend, Vue used for every single simple component on the front end), we have a team of 15 devs on the project.
I had to update the options in a simple select drop-down menu last week. It took me a full day and modifying six files to get it right. 10 years ago it would have been a 20 minute task and two files.
It’s sickening because the entire team thinks this is normal.
c) I can attest that this is complete bollocks, I have React apps in production that are blazing fast, and I have seen many others in the wild. I've also built a few prototypes in Next.js and got near-perfect speed scores without optimizing anything. I can only imagine it's gotten better in the last year or so.
d) I guess depends on definitions of "decent" analytics, but I've seen a few analytics solutions working with React in production and they worked more than decently.
As a closing thought, Facebook uses React all over the place. They are massive on personalization, analytics and A/B testing, for better and for worse, at hyperscale. I guess you think it's just the exception that confirms the rule?
Reply to c) Your react app is 30% slower that anything decent. Why would any bussiness owner would ever sign this off to happen in their acquisition funnel(i.e. where user experience is especially crucial)?
Reply to d) Decent is ~100% correctness and completeness versus ~70%.
Reply to "I guess you think it's just the exception that confirms the rule?" -> You keep mentioning companies and brands instead of implementations which suggest you have no experience on the implementation part. That is the thing - facebook does a/b testing server-side. And i'll just mention that facebook also used react to create their, arguably, second most important project - facebook ads manager. And it's a complete 'bollocks'(using your words) architectural decision to build such tool for react - it's a UX as terrible as it can get and i've used it for 5 years and I know at least 100 advertising agency employees who would sign this statement with their sweat and they are one of two. Just to give a counter-argument of the same origin as Yours one.
So am very thankful for constructive discussion - all your arguments are fair and well elaborated. Just you can't buy any of them. Really hope am not insulting with my strong opinions, always happy to discuss further!
This doesn't make any logical sense. I was clearly referring to Facebook primarily as an implementation, not as a brand.
> Client side a-b testing is impossible to be decent
OK, so Netflix, Facebook, Instagram, AirBnB - all web app implementations - cannot decently A/B test, but you can. Gotcha.
> Your react app is 30% slower that anything decent
How would you know, anyway? The web apps I've worked on (not app, in singular) are faster than just about anything "decent", faster than many SSR industry peers or competitors, and objectively so under many industry-standard performance tests.
You further resort to a personal attack by questioning my implementation or engineering chops without any evidence of them - just my evidence-based opinion that SPAs are not inherently slow at all (they really aren't).
I've got nothing against SSR, it's got its use cases and I've personally used it too, but you on the other hand seem to be an SSR jihadist - surely that could be a telltale sign of a really poor engineer?
Facebook is a product of 100000 different implementations which might theoretically change daily. If we were discussing can we do thing X or Y with MySQL, and you'd say 'look - there is facebook, it's working, it means you can('t) do thing X or Y with MySQL' - that would not not be very specific. I'll add term 'architecture' to discussion.
>> OK, so Netflix, Facebook, Instagram, AirBnB - all web app implementations - cannot decently A/B test, but you can. Gotcha.
So, let's talk architectures. "Netflix, Facebook, Instagram, AirBnB" - if you can, please specify what architecture and for what purpuse they have implemented. And tell about the specific example. We will have something to discuss, now we just don't.
For instance, https://docs.developers.optimizely.com/full-stack/docs/optim... -> this is architecture of optimizely experiment for React. This is other feature https://www.youtube.com/watch?v=NRLhlTopFzw being showcased, but you can get a sense of how the SDK is being used. Let's say bussiness requirement is to run experiment where for 50% of traffic you show nothing at the top of the page, for other 50% you show country flag image and city flag(cout of arms) image. Site is built with next.js. The next day you throw next.js out and build your site from scratch on other page. How would you implement that?
>>How would you know, anyway?
a) You use common technical sense and realize that's the only way it can be;
b) If you don't trust your guts, you go and analyze performance tests: https://css-tricks.com/radeventlistener-a-tale-of-client-sid... and learn that react is 40x slower that the industry standard. Not stressing 40x, just - it's slower, was and will always be (except RenderToStaticMarkup and Server Side Components).
c) You go and check what world is using - https://w3techs.com/technologies/comparison/js-jquery,js-rea... , you realize that, statistically speaking, no one is actually using react, probably for a reason. (Ok ok, this argument is also a bit overstrech, and yet... :)
d) You can only know for sure by building stuff and comparing. You build https://turboeshop.com/fastestpageintheworld/ and https://gatsbyeshop.com and compare: https://imagebin.ca/v/5lrH1VnQBac7 .
>> 'faster than many SSR industry peers or competitors'
'Not worse then most competitors' is not how you win in bussiness competition, is it? :)
>> You further resort to a personal attack
Honest apologies if that sounded that way. If I may - I take all that back.
>> I've got nothing against SSR, it's got its use cases and I've personally used it too, but you on the other hand seem to be an SSR jihadist
Ok, now we talk. For the record - I write a lot of client-facing vue code, sometimes a bit of react. Love both, great developer experience, I call them both 'godsend' for frontend development.
Yes, I do turn radical when people start shouting 'react is the answer, what was the question'. And this tread we are having discussion in began with 'you should do everything in JS/TS' statement. And believe me, there are many devs like this.
When faced such statements and situations I do take a stance and say that there are so many bussiness requirements that make hydration/js-navigation/react-vue-svelte obsolete from day one, they are just out of consideration when picking a stack.
Problem is devs makes usually make choices and bussiness usually does not not the costs they are incurring in letting devs to use tech stack they do love. Reactgasm(term found online) has it's high costs for some bussinesses. It sure does. It has obvious gains as well. Which are the greater - devs only can never decide, yet it happens that they think they can.
My main profession, broadly speaking, is e-commerce marketing. And when dev comes and says 'i'll use react in the acquisition funnel of the project you'll be optimising' - sometimes turning to SSR jihadism is the only way of winning an argument. Am glad we finally came to a conclusion that 'it depends on bussiness requirements', which I honestly think is always a start and end of discussions as such.
My final point is "react&friends are not default options for tech stack for ecommerce bussiness acquisition funnel (I have quite some expertese and many years of experience in this specific domain, that's why I allow myself strong statements), but in practice it may surely be a comlete opposite if bussiness decides so". That says nothing about that react or vue ar not great projects they do not have their use cases. In a neutral environment without react-jihadism i'm perfectly fine saying 'tech stack needs to meet bussines requirements', but that's only with an asterisk *if bussiness requirements are actually being taken into consideration, not devs just picking what they love and pretending everything else does not actually matter.
Many thanks for good discussion, apologies again if any of the statements were impolite, am not a native English speaker. Feel free to challange my technical discussions above, but I think I'll resist of pushing this further, as I've elaborated my point of view and then I believe it's about sharing ideas not winning arguments why we are in HackNews :) Kindest regards and happy holidays!
I would only use Node.js again for the back-end if I explicitly needed its performance characteristics.