4 ms·

A huge reason some people consider frameworks like Django obsolete is because they are focused on an older web paradigm of constructing elaborate html pages on

by borplk 8y ago

A huge reason some people consider frameworks like Django obsolete is because they are focused on an older web paradigm of constructing elaborate html pages on the server side and pushing it out and letting some basic extra js stuff augment it. That's what lead to things like server side HTML form definition and form handling code. After the emergence of things like React, Angular, etc those "html templating" facilities get in the way because that stuff is baked into the react app and is focused on the client side, it may get server side rendered with nodejs. A modern fancy web application using React in 2018 doesn't need something like Django forms or Flask-WTF and those types of things conflict and overlap with things like React. The backend is turning more into a data/API/GraphQL service than "get html" service that was popular when these frameworks emerged.

blattimwind 8y ago
> because they are focused on an older web paradigm Which usually is faster and easier to use. > A modern fancy web application using React in 2018 Takes ages to load and melts your CPU.
- messe 8y ago
  One wonders if the web would be a better place if developers used machines and networks slower than their users'.
  - ASalazarMX 8y ago
    Definitely. Often adding more hardware is justified because developer time is more valuable, but if you're wasting the time or resources of thousands of users, it shouldn't be acceptable.
  - dep_b 8y ago
    Heh well I'm trying to explain my customers that the load times I'm experiencing could be similar to their users and might be a problem. One of the advantages of being a remote developer with a pedestrian SDSL connection.
andybak 8y ago
> an older web paradigm of constructing elaborate html pages on the server side and pushing it out and letting some basic extra js stuff augment it. Sounds like an awesome idea. > That's what lead to things like server side HTML form definition and form handling code. You make these sound like bad things. > those types of things conflict and overlap with things like React So why presume the thing to abandon isn't React for many use cases? > The backend is turning more into a data/API/GraphQL service than "get html" service that was popular when these frameworks emerged. Which is fine if you're building a complex web app but stop encouraging people to build content sites this way. It's a terrible idea and they usually have deep UX flaws due to incomplete attempts to rebuild functionality that you get for free if you stop reinventing the wheel. 50% of the sites I visit seem to break some subtle aspect of bookmarking, navigation, caching, reloading or something else that they have no business messing with.
- chipotle_coyote 8y ago
  Yes! There are an awful lot of web sites out there--including the one we're on right now--which are, well, web sites, not web apps. I have a strong suspicion this conflation comes from reasoning kind of like this: (1) My web site would benefit from some kind of API. (2) Hey, if it has an API, wouldn't it be simpler if it just had an API, and all interaction was through clients? (3) So, [insert JavaScript framework] to the rescue! It'll be just like the original web site, but better! Except that it isn't automatically "better" for either performance or usability. Content-focused sites tend to perform very well using the server-side model.
- KyeRussell 8y ago
  The world needs more people like you. Thank you. I have a very varied workload which includes both complex web applications and content driven sites (very basic, accomplishable-by-WordPress marketing sites). I had a client move their very basic portfolio + blog site to a new developer who rewrote it from scratch. The new site has a loading / splash page before the real site displays. It's entirely JS driven and ticks all the boxes for bad implementation (badly implemented fake links, no use of the history API, bad accessibility.etc). I don't see how this is not a step backwards. Nothing was gained here except for some resume-driven development. Frankly, it strikes me as something that inexperienced developers do because they aren't aware of a world outside of React (or at the very least consider it to be obsolete).
rglullis 8y ago
Not true. django-rest-framework is so well adopted and widespread and it lets you very quickly put together a REST service. If you just want to talk json/xml/whatever with your client, it is easy. But the really cool thing about DRF is how it simply generalizes some of the concepts that already existed in in Django. If you started in Django and learned about Form and ModelForm, you can easily pick up DRF Serializers and ModelSerializers to get input validation. With django channels, you can also very easily break away from wsgi and have real time services, web sockets, all talking with your Django code. There is no "focus on older web paradigms". Django may have been slower to get things that other shiny JS frameworks already have, but this is only because Django had already successfully been used in projects of different sizes and it could not succumb to CADT.
- vram22 8y ago
  >it could not succumb to CADT. I had to look up CADT. Got this via Google: CADT stands for Cascade of Attention-Deficit Teenagers
  - KyeRussell 8y ago
    I love it.
douglaswlance 8y ago
You are not required to use Django's templating engine. It works great with React, Vue, Angular, etc. if you use Django Rest Framework as the intermediary.
- augbog 8y ago
  Yeah this seems to be the key point that is confused.
damon_c 8y ago
I haven't used Django to render HTML in at least 3 years.
RobertRoberts 8y ago
It seems you are confusing (conflating?) web pages with web app. >...constructing elaborate html pages on the server side and pushing it out and letting some basic extra js stuff augment it. I will take server side rendered webpage up against a fancy js spewed template any day of the week. In every metric possible the server side render wins. Load speed, SEO, accessibility, file size, time to paint, time to render, time to interactivity. Not a single point goes towards the js rendered web page, period. In fact, it has almost every conceivable downside, including the obvious, it requires javascript. I develop webapps for a living, and I hate using them for browsing content, they suck for that. Vue.js/React/Angular for web apps all the way, for web pages/content, server side hands React its behind.
dfsegoat 8y ago
Django REST framework (1) gives you the best of django + a RESTful API really, and is just another `pip install` and a few lines added to settings file. You still have some of the same performance issues as with any ORM - but it makes setting up a Django based RESTful API fairly trivial. Some things I like about DRF: - viewsets which allow RESTful read + CRUD ops on an existing django model. - easy to set up different serializers for a model view: flat, nested with child relations etc. - auto generated API docs in the browsable format of your choosing. 1 - https://www.django-rest-framework.org/ https://www.django-rest-framework.org/
devxpy 8y ago
Check out my library for using react in Django easily. https://github.com/pycampers/react-pages https://github.com/pycampers/react-pages

by borplk 8y ago

blattimwind 8y ago

> because they are focused on an older web paradigm Which usually is faster and easier to use. > A modern fancy web application using React in 2018 Takes ages to load and melts your CPU.

messe 8y ago
One wonders if the web would be a better place if developers used machines and networks slower than their users'.
- ASalazarMX 8y ago
  Definitely. Often adding more hardware is justified because developer time is more valuable, but if you're wasting the time or resources of thousands of users, it shouldn't be acceptable.
- dep_b 8y ago
  Heh well I'm trying to explain my customers that the load times I'm experiencing could be similar to their users and might be a problem. One of the advantages of being a remote developer with a pedestrian SDSL connection.

andybak 8y ago

> an older web paradigm of constructing elaborate html pages on the server side and pushing it out and letting some basic extra js stuff augment it. Sounds like an awesome idea. > That's what lead to things like server side HTML form definition and form handling code. You make these sound like bad things. > those types of things conflict and overlap with things like React So why presume the thing to abandon isn't React for many use cases? > The backend is turning more into a data/API/GraphQL service than "get html" service that was popular when these frameworks emerged. Which is fine if you're building a complex web app but stop encouraging people to build content sites this way. It's a terrible idea and they usually have deep UX flaws due to incomplete attempts to rebuild functionality that you get for free if you stop reinventing the wheel. 50% of the sites I visit seem to break some subtle aspect of bookmarking, navigation, caching, reloading or something else that they have no business messing with.

chipotle_coyote 8y ago
Yes! There are an awful lot of web sites out there--including the one we're on right now--which are, well, web sites, not web apps. I have a strong suspicion this conflation comes from reasoning kind of like this: (1) My web site would benefit from some kind of API. (2) Hey, if it has an API, wouldn't it be simpler if it just had an API, and all interaction was through clients? (3) So, [insert JavaScript framework] to the rescue! It'll be just like the original web site, but better! Except that it isn't automatically "better" for either performance or usability. Content-focused sites tend to perform very well using the server-side model.
KyeRussell 8y ago
The world needs more people like you. Thank you. I have a very varied workload which includes both complex web applications and content driven sites (very basic, accomplishable-by-WordPress marketing sites). I had a client move their very basic portfolio + blog site to a new developer who rewrote it from scratch. The new site has a loading / splash page before the real site displays. It's entirely JS driven and ticks all the boxes for bad implementation (badly implemented fake links, no use of the history API, bad accessibility.etc). I don't see how this is not a step backwards. Nothing was gained here except for some resume-driven development. Frankly, it strikes me as something that inexperienced developers do because they aren't aware of a world outside of React (or at the very least consider it to be obsolete).

rglullis 8y ago

Not true. django-rest-framework is so well adopted and widespread and it lets you very quickly put together a REST service. If you just want to talk json/xml/whatever with your client, it is easy. But the really cool thing about DRF is how it simply generalizes some of the concepts that already existed in in Django. If you started in Django and learned about Form and ModelForm, you can easily pick up DRF Serializers and ModelSerializers to get input validation. With django channels, you can also very easily break away from wsgi and have real time services, web sockets, all talking with your Django code. There is no "focus on older web paradigms". Django may have been slower to get things that other shiny JS frameworks already have, but this is only because Django had already successfully been used in projects of different sizes and it could not succumb to CADT.

vram22 8y ago
>it could not succumb to CADT. I had to look up CADT. Got this via Google: CADT stands for Cascade of Attention-Deficit Teenagers
- KyeRussell 8y ago
  I love it.

douglaswlance 8y ago

You are not required to use Django's templating engine. It works great with React, Vue, Angular, etc. if you use Django Rest Framework as the intermediary.

augbog 8y ago
Yeah this seems to be the key point that is confused.

damon_c 8y ago

I haven't used Django to render HTML in at least 3 years.

RobertRoberts 8y ago

It seems you are confusing (conflating?) web pages with web app. >...constructing elaborate html pages on the server side and pushing it out and letting some basic extra js stuff augment it. I will take server side rendered webpage up against a fancy js spewed template any day of the week. In every metric possible the server side render wins. Load speed, SEO, accessibility, file size, time to paint, time to render, time to interactivity. Not a single point goes towards the js rendered web page, period. In fact, it has almost every conceivable downside, including the obvious, it requires javascript. I develop webapps for a living, and I hate using them for browsing content, they suck for that. Vue.js/React/Angular for web apps all the way, for web pages/content, server side hands React its behind.

dfsegoat 8y ago

Django REST framework (1) gives you the best of django + a RESTful API really, and is just another `pip install` and a few lines added to settings file. You still have some of the same performance issues as with any ORM - but it makes setting up a Django based RESTful API fairly trivial. Some things I like about DRF: - viewsets which allow RESTful read + CRUD ops on an existing django model. - easy to set up different serializers for a model view: flat, nested with child relations etc. - auto generated API docs in the browsable format of your choosing. 1 - https://www.django-rest-framework.org/ https://www.django-rest-framework.org/

devxpy 8y ago

Check out my library for using react in Django easily. https://github.com/pycampers/react-pages https://github.com/pycampers/react-pages