7 ms·

unless you're doing a lot of math - where python/numpy/sklearn/scipy/BLAS/LAPACK/Tensorflow is unparalleled - you should do everything in JS/TS. something like

unless you're doing a lot of math - where python/numpy/sklearn/scipy/BLAS/LAPACK/Tensorflow is unparalleled - you should do everything in JS/TS. something like nextjs - with built in frontend+backend is ideal.

MoSattler 6y ago
The JS ecosystem is unfortunately lacking anything as powerful as the Django ORM.
- djstein 6y ago
  This is it. If you can’t connect to your database effectively and safety execute queries + migrations (looking at you people who write SQL queries by hand in Typescript) you’re just writing something that is one key stroke away from destroying your database.
  - nicoburns 6y ago
    > you’re just writing something that is one key stroke away from destroying your database. 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.
    - dstep-init 6y ago
      It just seems kind of like building a car by hand to me. Why would you want to use raw SQL when you can leverage the power of your favorite programming language? Isn't it cleaner to write a Model with Pythonic field constraints, methods, and subclassing? Don't get me wrong - knowing SQL is important for every developer, but one doesn't need to be an SQL expert to be a back-end development expert.
- nicoburns 6y ago
  The ORM space is actually getting much closer. Both TypeORM and Objection.js are good options. But if you're talking about Django as whole then I totally agree.
  - arcturus17 6y ago
    I’ve considered them before along with Sequelize but their repos are chock-full of issues, and I’ve read some very negative opinions about all of them. They make me unsure that they’re production-worthy.
bpt3 6y ago
> unless you're doing a lot of math - where python/numpy/sklearn/scipy/BLAS/LAPACK/Tensorflow is unparalleled - you should do everything in JS/TS 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.
- bliteben 6y ago
  even just wiring up a management command / cron job is a huge pain in javascript right now with the require vs import stuff. typescript makes it better, but until type script is more supported this type of stuff is going to continue to be an issue.
  - bpt3 6y ago
    Agreed, I think it's much easier to make a list of what is not a huge pain in javascript that it would be to make a list of everything that is.
djstein 6y ago
Look, this argument is always thought provoking, but not worth any devs time to execute. Django/Rails/Spring/.Net have years of combined dev experience. They contain almost all the things every web application needs, with highly adopted off the shelf plugins for everything else. When engineers fall for the trap of Flask/Express/Sinatra/Go they don’t realize they’ll either be a. Writing everything the above frameworks have by hand or b. Cobbling together a ton of different/non related tools that may not be battle tested. In either case they spend time writing features we solved 20 years ago. My favorite example of this is database connections/migrations/translations. 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.
- sandGorgon 6y ago
  im very conscious that this may trigger a very opinionated war. so let me backoff for a moment. 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-admin-template/20978545 https://themeforest.net/item/react-material-bootstrap-4-admi... https://themeforest.net/item/react-next-modern-landing-page-template/23169879 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
toinbis 6y ago
You should NOT use nuxt, react, gatsby in bussiness environment for anything but internal employee-facing applications. 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 :)
- sandGorgon 6y ago
  would love to hear from you about this. Doesnt react have like a massive ecosystem of integrations around this ? for example Optimizely - https://docs.developers.optimizely.com/full-stack/docs/javascript-react 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 ?
  - toinbis 6y ago
    Client-side a/b testing/personalizations(default option for google optimize, visual website optimizer, optimizely) mean you have to use page hiding snippet - https://support.google.com/optimize/answer/7100284?hl=en https://support.google.com/optimize/answer/7100284?hl=en. 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.
tomcam 6y ago
How many line of business apps do you maintain?
arcturus17 6y ago
I love React and JavaScript but I completely disagree with this. I've moved to Django for my back-ends and it's an infinitely better experience than any Node.js-based backends. It provides a structure and set of facilities which are completely unmatched in the JS server world. I would only use Node.js again for the back-end if I explicitly needed its performance characteristics.

MoSattler 6y ago

The JS ecosystem is unfortunately lacking anything as powerful as the Django ORM.

djstein 6y ago
This is it. If you can’t connect to your database effectively and safety execute queries + migrations (looking at you people who write SQL queries by hand in Typescript) you’re just writing something that is one key stroke away from destroying your database.
- nicoburns 6y ago
  > you’re just writing something that is one key stroke away from destroying your database. 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.
  - dstep-init 6y ago
    It just seems kind of like building a car by hand to me. Why would you want to use raw SQL when you can leverage the power of your favorite programming language? Isn't it cleaner to write a Model with Pythonic field constraints, methods, and subclassing? Don't get me wrong - knowing SQL is important for every developer, but one doesn't need to be an SQL expert to be a back-end development expert.
nicoburns 6y ago
The ORM space is actually getting much closer. Both TypeORM and Objection.js are good options. But if you're talking about Django as whole then I totally agree.
- arcturus17 6y ago
  I’ve considered them before along with Sequelize but their repos are chock-full of issues, and I’ve read some very negative opinions about all of them. They make me unsure that they’re production-worthy.

bpt3 6y ago

> unless you're doing a lot of math - where python/numpy/sklearn/scipy/BLAS/LAPACK/Tensorflow is unparalleled - you should do everything in JS/TS 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.

bliteben 6y ago
even just wiring up a management command / cron job is a huge pain in javascript right now with the require vs import stuff. typescript makes it better, but until type script is more supported this type of stuff is going to continue to be an issue.
- bpt3 6y ago
  Agreed, I think it's much easier to make a list of what is not a huge pain in javascript that it would be to make a list of everything that is.

djstein 6y ago

Look, this argument is always thought provoking, but not worth any devs time to execute. Django/Rails/Spring/.Net have years of combined dev experience. They contain almost all the things every web application needs, with highly adopted off the shelf plugins for everything else. When engineers fall for the trap of Flask/Express/Sinatra/Go they don’t realize they’ll either be a. Writing everything the above frameworks have by hand or b. Cobbling together a ton of different/non related tools that may not be battle tested. In either case they spend time writing features we solved 20 years ago. My favorite example of this is database connections/migrations/translations. 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.

sandGorgon 6y ago
im very conscious that this may trigger a very opinionated war. so let me backoff for a moment. 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-admin-template/20978545 https://themeforest.net/item/react-material-bootstrap-4-admi... https://themeforest.net/item/react-next-modern-landing-page-template/23169879 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

toinbis 6y ago

You should NOT use nuxt, react, gatsby in bussiness environment for anything but internal employee-facing applications. 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 :)

sandGorgon 6y ago
would love to hear from you about this. Doesnt react have like a massive ecosystem of integrations around this ? for example Optimizely - https://docs.developers.optimizely.com/full-stack/docs/javascript-react 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 ?
- toinbis 6y ago
  Client-side a/b testing/personalizations(default option for google optimize, visual website optimizer, optimizely) mean you have to use page hiding snippet - https://support.google.com/optimize/answer/7100284?hl=en https://support.google.com/optimize/answer/7100284?hl=en. 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.

tomcam 6y ago

How many line of business apps do you maintain?

arcturus17 6y ago

I love React and JavaScript but I completely disagree with this. I've moved to Django for my back-ends and it's an infinitely better experience than any Node.js-based backends. It provides a structure and set of facilities which are completely unmatched in the JS server world. I would only use Node.js again for the back-end if I explicitly needed its performance characteristics.