Comment by em-bee | Hacker News Reader

Comment by em-bee | Hacker News Reader

Parent Full thread

that's part of what i am disputing. the frontend logic is moved to the frontend framework, and the backend is dramatically simplified. the overall complexity is not much greater than having everything in the backend framework. so i am only adding another project in terms of dealing with two frameworks instead of one, but at least on the backend i am only using 50% of that framework now.

what's more, this simplifies the backend so much that in most cases it is reduced to CRUD in such a way that i can reuse it more easily. since using frontend frameworks i haven't in face needed to do any backend coding anymore because i could just reuse the backend i already had unchanged. so in my case, i only ever had to deal with one project, except for the first time where i wrote the REST API into the backend. every other website after that was a frontend project only.

for dozens of projects i can now maintain a single backend implementation (with multiple instances as needed, that all share 100% of the code). that alone makes using a frontend framework worth it even just for a few simple client-side effects.

I think this is just a case of you arguing from a different set of assumptions. The thread starter started out with a Django app and wanted to distinguish between frontend libraries' conceptual "heaviness" for adding bits of interactivity to their website. Obviously in that case (i.e. being comfortable in Django and wanting to keep that) a framework that assumes that you'll move all logic into it is then conceptually pretty heavy, given that they're not going to do that.

If you are, then sure, those frameworks are conceptually lighter.

you are right. i am arguing based on the assumption that this:

being comfortable in Django and wanting to keep that

is a bad idea. because whoever is doing that is missing out on a lot of potential.

sure, there are many cases where sticking with django for everything is the right choice, but that's not always true, and i am trying to argue that there is a benefit to exploring the alternative.

i was a backend developer too, django, laravel, others,, and i shunned javascript as much as i could, but when i discovered angularjs (the first version, before it was popular) it just won me over as the better way to build frontends.

in particular, not having to track state in the server, i feel, makes the whole development process so much easier.

i could summarize it thusly: i would use a lightweight option only if the site is mostly stateless (which many content sites tend to be) but as soon as it is necessary to track state, i find a frontend framework talking to an API is the better choice, because tracking state in the browser is so much easier.

Heh I mean, I'm a frontend engineer too and agree with you that there's so much to be had in the frontend :) But I also understand that people have preferences and habits, and that there's a cost to investigating potential other paths one could take without knowing in advance whether they're right for them.

well, you never know in advance, and while i don't fault people for feeling overwhelmed by the many ever changing frontend frameworks, everyone should at least build one true SPA with any frontend framework to learn what the fuss is all about. because you can't make an informed choice about the suitability of building an SPA if you are not familiar with the choices. there is also the aspect of using frontend frameworks for mobile development, where an SPA is more likely to be suitable to enable disconnected operation.

Reply on news.ycombinator.com