Hacker News Reader

Comment by borplk | Hacker News Reader

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.

View on HN

> 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.

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.

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).

What we have is basically worse than flash. At least nothing serious except video was strictly dependent on Flash.

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.

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.

>it could not succumb to CADT.

I had to look up CADT.

Got this via Google:

CADT stands for Cascade of Attention-Deficit Teenagers

I love it.

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.

Yeah this seems to be the key point that is confused.

> 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.

One wonders if the web would be a better place if developers used machines and networks slower than their users'.

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.

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.

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/

Check out my library for using react in Django easily.

https://github.com/pycampers/react-pages

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

Reply on news.ycombinator.com