Hacker News Reader

Comment by em-bee | Hacker News Reader

If an application has lots of client-side state, for example, that means you have a whole additional lifecycle of your code to reason about.

not really, because you no longer need to track that state in the backend. the backend can be reduced to data storage and business logic calculations. the cases where you need track some state in both frontend and backend should be rare. from my experience all the UI code is moved from the backend to the frontend. it's not being duplicated.

duplication of code can happen during a transition, but it should be temporary

View on HN

It's not so much that a single case affects state in both the frontend and the backend; it's that in some cases, you're going to have to reason about the lifecycle of your backend, whereas in others, it's the frontend lifecycle that's relevant. Both come with their own set of concerns, and it's more context switching and lifecycles to keep in mind.

well, yes, sure, but that's not much different than any two projects. sure, if all your projects are using the same framework then maybe that's easier, but if you are working on multiple projects, chances are you also work with multiple frameworks. at least i do.

and if i specialize, i'd do it with one frontend framework and one backend framework. ok, so that's two instead of one. anyone beyond a junior developer should have no problem with this.

Exactly - "heavy" frontend frameworks are like adding another project. It's not that there aren't plenty of situations where that is perfectly fine, but if all you need to do is adding a few client-side effects, I'd suggest using something more light-weight.

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