4 ms·

Anyone who says front end isn’t bloated and it just feels like coding backend really haven’t tried either one of these or both. Have you tried upgrading your R

Anyone who says front end isn’t bloated and it just feels like coding backend really haven’t tried either one of these or both. Have you tried upgrading your React app that was 1.5 years old? How many times upgrading anything in npm gives you the worst nightmares? It’s not just bloat, it’s the stress that front end dev brings. It’s a chaotic world, constantly changing for god knows why and the entire ecosystem does not value robustness and longevity. In fact, they've made it cool to break things all the time. Robust tools are considered "old fashioned". Apart from Angular, which is a still finicky, the rest of the dependency management is a complete nightmare. I can easily revive a 4 year old backend code. Most likely without a single error. With absolute and 100% certainty, I can guarantee the opposite for any front end code, even Angular projects. Node js, the backbone of managing js projects itself doesn’t value backwards compatibility.

tomstoms 6y ago
Not fair. Upgrading java libs like spring is just as laboursome given enough major releases have lapsed. Backenders need need to get their oumf out of their oumfs, and realize this is all about what you’re used to. Upgrading spring if you know spring is not as hard as upgrading React when you have no clue about React. There’s no significant difference.
- systemvoltage 6y ago
  I cannot tell you how many times I've stumbled on SO post that just recommends - "Just use Node v10". Usually, with no explanation. Ohhh....
jariel 6y ago
I have been coding UIs for over 20 years on and off, and I've done everything. React is a special beast, I don't like it, yes, it's a little bloated and no, I don't so much think it's quite suited to the front/back of frontend division. Your problem with bloat and fragmentation though, is not about this particular form of division of labour. Front ends change a lot more for a variety of reasons. One reason the front end evolves more is there's more going on, and more detail. The backend is logic, which can be more succinctly articulated by code. That's what code is for. Most code was never designed for UI, and even HTML/CSS was never designed to do what it's doing. A simple web form can involve a lot of cross-cutting artifacts and complex statefulness. Even with a great set of tools it can be quite hard to get right, and requires a different way of thinking than on the backend. Front end problems are usually however, narrow in scope - a screen can usually only ever be so complicated, whereas on the backend, true scale can make a lot of things hard.
- systemvoltage 6y ago
  It's true, frontend is complex. User interfaces and interactions are full async and all behavior needs to be captured and tested. Server side code can get complex but there is a lot less externalities and requirements are well defined. My main gripe is the people behind major frontend projects - Node, npm, React, etc. and their overall philosophy. The community is a shitshow and I hate how unorganized, unplanned, broken the entire ecosystem is. The worst part is that this is celebrated.
- catmanjan 6y ago
  With your experience, what do you recommend?
  - jariel 6y ago
    Keep it as simple as possible and focus on the experience not the technology. For straight up web or small companies, Wix, Shopify or Wordpress is fine. Look how great HN is with minimal tech. For 'Web Apps' it's obviously more difficult, and the current of tech is unavoidable, but if you stay in the middle lane and don't use anything to risky, certainly with 'backed' tech like React you should be fine. If your business is Widgets, then everything else should be 'off the shelf'. If your business actually is web-tech in some way, you can start to push the boundaries.
nawgz 6y ago
I’ve never experienced these problems, and I run productionized apps from 2016 still. What kind of feature sets were you trying to achieve? I wrote a collaborative model editor in React and MobX, using some nigh unknown JS library to manage collaborative aspects and d3 for visualizations. All while interacting with multiple services. I upgraded seamlessly across webpack versions, despite continuing to use legacy decorators. Plus, churn in the front end is completely overstated. Most libraries from a few years ago have the exact same APIs, but perhaps also added a new way of working. You do not need to adhere to this new way of working, or you can progressively adapt it. Small libraries died, but isn’t it professional diligence to evaluate the likelihood of that happening and the risk you take in the first place not doing it yourself? Especially when it is simple.
gherkinnn 6y ago
Interestingly, I spent more time fighting gems and nuggets than npm, despite spending vastly more time with npm. A thoughtlessly npm’d together FE is a pain, as is any thoughtlessly bolted together anything. Granted, some things lend themselves more to disaster than others. I think it’s a people thing. Hire lots of hardcore .net peeps to wire up a complete setup, and of course nuget will be solid and npm a flaming mess.
mattacular 6y ago
> I can guarantee the opposite for any front end code, even Angular projects I'd say ESPECIALLY on Angular projects (or React or Vue). Look at the package.json of any JS "web app" in any of the popular frameworks. Now imagine how many of those packages will have breaking changes in 1 year. By 2 year mark, many of them will be abandoned completely forcing the app maintainer to replace, or continue using an old version if that is even possible.

tomstoms 6y ago

Not fair. Upgrading java libs like spring is just as laboursome given enough major releases have lapsed. Backenders need need to get their oumf out of their oumfs, and realize this is all about what you’re used to. Upgrading spring if you know spring is not as hard as upgrading React when you have no clue about React. There’s no significant difference.

systemvoltage 6y ago
I cannot tell you how many times I've stumbled on SO post that just recommends - "Just use Node v10". Usually, with no explanation. Ohhh....

jariel 6y ago

I have been coding UIs for over 20 years on and off, and I've done everything. React is a special beast, I don't like it, yes, it's a little bloated and no, I don't so much think it's quite suited to the front/back of frontend division. Your problem with bloat and fragmentation though, is not about this particular form of division of labour. Front ends change a lot more for a variety of reasons. One reason the front end evolves more is there's more going on, and more detail. The backend is logic, which can be more succinctly articulated by code. That's what code is for. Most code was never designed for UI, and even HTML/CSS was never designed to do what it's doing. A simple web form can involve a lot of cross-cutting artifacts and complex statefulness. Even with a great set of tools it can be quite hard to get right, and requires a different way of thinking than on the backend. Front end problems are usually however, narrow in scope - a screen can usually only ever be so complicated, whereas on the backend, true scale can make a lot of things hard.

systemvoltage 6y ago
It's true, frontend is complex. User interfaces and interactions are full async and all behavior needs to be captured and tested. Server side code can get complex but there is a lot less externalities and requirements are well defined. My main gripe is the people behind major frontend projects - Node, npm, React, etc. and their overall philosophy. The community is a shitshow and I hate how unorganized, unplanned, broken the entire ecosystem is. The worst part is that this is celebrated.
catmanjan 6y ago
With your experience, what do you recommend?
- jariel 6y ago
  Keep it as simple as possible and focus on the experience not the technology. For straight up web or small companies, Wix, Shopify or Wordpress is fine. Look how great HN is with minimal tech. For 'Web Apps' it's obviously more difficult, and the current of tech is unavoidable, but if you stay in the middle lane and don't use anything to risky, certainly with 'backed' tech like React you should be fine. If your business is Widgets, then everything else should be 'off the shelf'. If your business actually is web-tech in some way, you can start to push the boundaries.

nawgz 6y ago

I’ve never experienced these problems, and I run productionized apps from 2016 still. What kind of feature sets were you trying to achieve? I wrote a collaborative model editor in React and MobX, using some nigh unknown JS library to manage collaborative aspects and d3 for visualizations. All while interacting with multiple services. I upgraded seamlessly across webpack versions, despite continuing to use legacy decorators. Plus, churn in the front end is completely overstated. Most libraries from a few years ago have the exact same APIs, but perhaps also added a new way of working. You do not need to adhere to this new way of working, or you can progressively adapt it. Small libraries died, but isn’t it professional diligence to evaluate the likelihood of that happening and the risk you take in the first place not doing it yourself? Especially when it is simple.

gherkinnn 6y ago

Interestingly, I spent more time fighting gems and nuggets than npm, despite spending vastly more time with npm. A thoughtlessly npm’d together FE is a pain, as is any thoughtlessly bolted together anything. Granted, some things lend themselves more to disaster than others. I think it’s a people thing. Hire lots of hardcore .net peeps to wire up a complete setup, and of course nuget will be solid and npm a flaming mess.

mattacular 6y ago

> I can guarantee the opposite for any front end code, even Angular projects I'd say ESPECIALLY on Angular projects (or React or Vue). Look at the package.json of any JS "web app" in any of the popular frameworks. Now imagine how many of those packages will have breaking changes in 1 year. By 2 year mark, many of them will be abandoned completely forcing the app maintainer to replace, or continue using an old version if that is even possible.