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
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 ...
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.
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 :)
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’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.
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.
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.
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.
I would only use Node.js again for the back-end if I explicitly needed its performance characteristics.
something like nextjs - with built in frontend+backend is ideal.