4 ms·

> Let’s assume that making a JS change costs twice as much time a Ruby change, which I think is being generous to JS. Everyone's mileage varies, of course, but

by tyre 2y ago

> Let’s assume that making a JS change costs twice as much time a Ruby change, which I think is being generous to JS. Everyone's mileage varies, of course, but this is quite the assumption. It feels like a lack of familiarity/comfort with the frontend or poor tooling. With typescript and a basic UI library like MUI, this really shouldn't be the case for UI changes. If you're using raw JS and manipulating the DOM, maybe?

GiorgioG 2y ago
[flagged]
mvdtnz 2y ago
My experience with very highly paid frontend developers is they like to spend hours and hours (and thousands and thousands of dollars) building out little libraries and components and frameworks that will enable other teams to be faster. Except this never eventuates because things rarely turn out to be reusable along the right axis so a new component or library or framework is developed to solve the problem. On top of this UI developer propellor-heads love to spend time (and money) pontificating on abstract theories about functional programming and homomorphisms and endofunctors so they can render some text inside a <b> tag. It's how we wound up with utterly ridiculous pieces of code like the "hooks" API in React.
- goosejuice 2y ago
  I also get the feeling that modern frontend is a massive money pit but this seems to be a leadership problem. I wouldn't go so far as to blame the IC. There are developers over-engineering in every ecosystem.
  - Earw0rm 2y ago
    Something about the psychology of front-end - not quite as hardcore technical, a little more humanities-aligned - perhaps makes them even more susceptible. The self-consciously cool kids are always going to be more easily swayed by fashion than cave hermits.
- JOnAgain 2y ago
  Can’t get promoted pumping out 10 great pages. But a library that you can claim will enhance the productivity of 100 other engineers? Now that’s IMPACT!! Except you’re at a company where everyone has figured this out so now you have 4 competing libraries with their own teams which are all 1/2 done making every engineer less productive cause they all have bugs and slightly different priorities.
  - ctkhn 2y ago
    this is exactly the frontend team from a previous role. we were losing millions a month and had 2 major cuts within 4 months - and instead of cleaning up or simplifying our bloated frontend, the teams responsible for it started building new component libraries for the rest of the org to use on future pages
  - veidelis 2y ago
    4 competing in-house libs? How can that ever happen? Is middle management non-existant? That is anarchy, hehe
- zsoltkacsandi 2y ago
  I've had exactly the same experience.
- tannhaeuser 2y ago
  You forgot the part where everything has to be redone every 5-10 years despite grand allusions of reusability because of the cyclic nature of the frontend market. The JS framework proliferation is largely driven by skills becoming obsolete (or needing to become obsolete for economic reasons) as younger frontend devs move in who want to carve their niche and distance themselves from "horrible" previous-gen unmaintainable and wayyy overengineered stuff. Which was objectively unmaintainable either from the start as a work of love of a developer who put all his thoughts into it so it became incomprehensible ;) or became unmaintainable when later developers (who couldn't care less) had to violate the original grand vision of state encapsulation or hypermedia architecture or whatever for a trivial business form app. I guess the good thing is that comprehending our absurd web frontend creations is beyond current LLM's capabilities.
- chefandy 2y ago
  I've done a lot of back-end and a bit of front end development. You're correctly identifying a crappy outcome, but incorrectly attributing the effect of shitty developers and project management with whole disciplines and common practices within them.
marcus_holmes 2y ago
I think the author was talking about React specifically. I've worked in JS, TS, React, and RoR, and yeah I'd say making a change is probably twice as quick in RoR as in React. The thing is that Rails is an opinionated framework. If you do things that the framework is designed to do, then it's very very easy. If you go off-piste and have to fight the framework to do the thing you want it to do, it gets very hard very quickly. React is less opinionated (about most things) so the converse is true; it is slower to write stuff in, but there's less constraint.
- ajmurmann 2y ago
  I feel the comparison is really hard. Rails really is a framework that solves anything but the business logic for 80% of your app. React is really a library for rendering components and everything else is your decision to pick or build from scratch. E.g. Rails has opinions on how to build forms while React, a supposed frontend framework, doesn't have anything baked in specific to that. Sure the community has opinions about it but React doesn't like Rails does.
deleted 2y ago
[deleted]
kellysutton 2y ago
The original post could have been a bit more precise on this point. Basically, this math assumes something where the server-provided data changes in concert with the frontend. If we're using jsonapi, GraphQL, Thrift, or any other protocol that's not HTML, we need to do the following: - Make the change on the server to support the new functionality. Deploy. - Make the change on the client to adopt the new functionality. Deploy. - Remove the old functionality from the server (optional) Because the client is a separate application, it becomes riskier to deploy those changes together. I need to think about it more as a developer. With server-authored HTML, this separate client + server deploy is not required.
- leptons 2y ago
  >With server-authored HTML, this separate client + server deploy is not required. SSR has been a thing in react for a long time.
  - runako 2y ago
    If the app has a backend, aren't we still talking about modifying two distinct apps (React + backend app) vs a single one? Obviously unless the team has committed to React SSR + React backend (is this common?)
    - erikerikson 2y ago
      Not necessarily. We write Typescript for front and back ends, using statically rendered SolidJs, skipping SSR, and hosting the corresponding Typescript in Lambdas.
      - runako 2y ago
        Would love to hear more about the deployment for that.
        erikerikson 2y ago
        CDK BucketDeployment to S3 fronted by CloudFront using a simple CloudFront function that redirects all paths to the index (main entry) file. `aws s3 sync` could have been fine. Was that the piece of deployment you were curious about? If not feel free to be more specific.
psychoslave 2y ago
There is no free lunch though. Typescript and whatever frontend stack we might go with will come with their own drawback. It doesn't mean the trade-off is never worth it, but we better keep in mind that adding transpilers and a truckload of external libraries does have a maintenance cost.
- bvrmn 2y ago
  Typescript has so vast productivity benefits there is no any second though to use or not to use it.
  - Zanfa 2y ago
    I wouldn't touch a React project without Typescript. But if you use something like Web Components (or Stimulus etc) where you compartmentalize small bits of UI into distinct reusable components, JSDoc gets you 90% of the benefit of Typescript without the baggage.
Lutger 2y ago
Absolutely, this is one of the main assumptions where the blog falls apart. What takes more time and carries more risk, really depends on context. Boring, but unavoidable. This is another one: > when compared to a world where that change isn’t risky (server-rendered ERB) Server rendered html templates a la PHP - which is what ERB is, may be not risky in this smallish project with likely a fairly straightforward UX and seasoned rails devs, but it can be risky in others for sure. I think a lot of the motivation to embrace what react began was a desire to move out of a tangled mess of spaghetti templates, to be able to use means of abstraction and modularity as powerful as regular backend code. Frontend devs want to create and use components. You cannot create a component with html templates, not really. It will be a mess. Moving from server rendered html to an api + spa architecture has quite an overhead of course. Just like adding a separate backend service. That price should be worth it. And a good developer can judge whether in which context that is the case. But pretending the benefits that motivate such a change just never justify the costs doesn't make sense to me. The cost of a change is a very, very complex measure. Anyone who has a simple answer to it that is universal, true and useful will win a Nobel Prize. This is because the cost depends on the person who is making it and his peers, on its effects in the future, on the project of which it is a part, on luck and on the larger ecosystem in which it is done. There are just way too many parameters.
bvrmn 2y ago
Also it depends from API response. It could vary from FE dictating schema or backend making hard orthogonal domain modeling API. In first case FE is productive there is no need to transform data but makes BE a hot mess. Otherwise FE have to maintain layer of code to convert BE data to presentable UI data. It's harder but allows to decouple UI reqs from changes along all stack.
IshKebab 2y ago
Yeah this seems like an insane assumption on a language basis. Ruby has no static types (or not very good ones as far as I know) and is very hard to follow due to using "magic" so much. I've contributed several features to VSCode (Typescript) and it was relatively easy. I have completely failed to do the same with Gitlab (Ruby) because the code is so hard to navigate. I did manage to add some features to gitlab-runner but that is written in Go, which again is much easier to follow than Ruby. I think they are really talking about client-side vs server-side rendering. Server-side is much simpler.
deleted 2y ago
[deleted]

by tyre 2y ago

GiorgioG 2y ago

[flagged]

mvdtnz 2y ago

My experience with very highly paid frontend developers is they like to spend hours and hours (and thousands and thousands of dollars) building out little libraries and components and frameworks that will enable other teams to be faster. Except this never eventuates because things rarely turn out to be reusable along the right axis so a new component or library or framework is developed to solve the problem. On top of this UI developer propellor-heads love to spend time (and money) pontificating on abstract theories about functional programming and homomorphisms and endofunctors so they can render some text inside a <b> tag. It's how we wound up with utterly ridiculous pieces of code like the "hooks" API in React.

goosejuice 2y ago
I also get the feeling that modern frontend is a massive money pit but this seems to be a leadership problem. I wouldn't go so far as to blame the IC. There are developers over-engineering in every ecosystem.
- Earw0rm 2y ago
  Something about the psychology of front-end - not quite as hardcore technical, a little more humanities-aligned - perhaps makes them even more susceptible. The self-consciously cool kids are always going to be more easily swayed by fashion than cave hermits.
JOnAgain 2y ago
Can’t get promoted pumping out 10 great pages. But a library that you can claim will enhance the productivity of 100 other engineers? Now that’s IMPACT!! Except you’re at a company where everyone has figured this out so now you have 4 competing libraries with their own teams which are all 1/2 done making every engineer less productive cause they all have bugs and slightly different priorities.
- ctkhn 2y ago
  this is exactly the frontend team from a previous role. we were losing millions a month and had 2 major cuts within 4 months - and instead of cleaning up or simplifying our bloated frontend, the teams responsible for it started building new component libraries for the rest of the org to use on future pages
- veidelis 2y ago
  4 competing in-house libs? How can that ever happen? Is middle management non-existant? That is anarchy, hehe
zsoltkacsandi 2y ago
I've had exactly the same experience.
tannhaeuser 2y ago
You forgot the part where everything has to be redone every 5-10 years despite grand allusions of reusability because of the cyclic nature of the frontend market. The JS framework proliferation is largely driven by skills becoming obsolete (or needing to become obsolete for economic reasons) as younger frontend devs move in who want to carve their niche and distance themselves from "horrible" previous-gen unmaintainable and wayyy overengineered stuff. Which was objectively unmaintainable either from the start as a work of love of a developer who put all his thoughts into it so it became incomprehensible ;) or became unmaintainable when later developers (who couldn't care less) had to violate the original grand vision of state encapsulation or hypermedia architecture or whatever for a trivial business form app. I guess the good thing is that comprehending our absurd web frontend creations is beyond current LLM's capabilities.
chefandy 2y ago
I've done a lot of back-end and a bit of front end development. You're correctly identifying a crappy outcome, but incorrectly attributing the effect of shitty developers and project management with whole disciplines and common practices within them.

marcus_holmes 2y ago

I think the author was talking about React specifically. I've worked in JS, TS, React, and RoR, and yeah I'd say making a change is probably twice as quick in RoR as in React. The thing is that Rails is an opinionated framework. If you do things that the framework is designed to do, then it's very very easy. If you go off-piste and have to fight the framework to do the thing you want it to do, it gets very hard very quickly. React is less opinionated (about most things) so the converse is true; it is slower to write stuff in, but there's less constraint.

ajmurmann 2y ago
I feel the comparison is really hard. Rails really is a framework that solves anything but the business logic for 80% of your app. React is really a library for rendering components and everything else is your decision to pick or build from scratch. E.g. Rails has opinions on how to build forms while React, a supposed frontend framework, doesn't have anything baked in specific to that. Sure the community has opinions about it but React doesn't like Rails does.

deleted 2y ago

[deleted]

kellysutton 2y ago

The original post could have been a bit more precise on this point. Basically, this math assumes something where the server-provided data changes in concert with the frontend. If we're using jsonapi, GraphQL, Thrift, or any other protocol that's not HTML, we need to do the following: - Make the change on the server to support the new functionality. Deploy. - Make the change on the client to adopt the new functionality. Deploy. - Remove the old functionality from the server (optional) Because the client is a separate application, it becomes riskier to deploy those changes together. I need to think about it more as a developer. With server-authored HTML, this separate client + server deploy is not required.

leptons 2y ago
>With server-authored HTML, this separate client + server deploy is not required. SSR has been a thing in react for a long time.
- runako 2y ago
  If the app has a backend, aren't we still talking about modifying two distinct apps (React + backend app) vs a single one? Obviously unless the team has committed to React SSR + React backend (is this common?)
  - erikerikson 2y ago
    Not necessarily. We write Typescript for front and back ends, using statically rendered SolidJs, skipping SSR, and hosting the corresponding Typescript in Lambdas.
    - runako 2y ago
      Would love to hear more about the deployment for that.
      - erikerikson 2y ago
        CDK BucketDeployment to S3 fronted by CloudFront using a simple CloudFront function that redirects all paths to the index (main entry) file. `aws s3 sync` could have been fine. Was that the piece of deployment you were curious about? If not feel free to be more specific.

psychoslave 2y ago

There is no free lunch though. Typescript and whatever frontend stack we might go with will come with their own drawback. It doesn't mean the trade-off is never worth it, but we better keep in mind that adding transpilers and a truckload of external libraries does have a maintenance cost.

bvrmn 2y ago
Typescript has so vast productivity benefits there is no any second though to use or not to use it.
- Zanfa 2y ago
  I wouldn't touch a React project without Typescript. But if you use something like Web Components (or Stimulus etc) where you compartmentalize small bits of UI into distinct reusable components, JSDoc gets you 90% of the benefit of Typescript without the baggage.

Lutger 2y ago

Absolutely, this is one of the main assumptions where the blog falls apart. What takes more time and carries more risk, really depends on context. Boring, but unavoidable. This is another one: > when compared to a world where that change isn’t risky (server-rendered ERB) Server rendered html templates a la PHP - which is what ERB is, may be not risky in this smallish project with likely a fairly straightforward UX and seasoned rails devs, but it can be risky in others for sure. I think a lot of the motivation to embrace what react began was a desire to move out of a tangled mess of spaghetti templates, to be able to use means of abstraction and modularity as powerful as regular backend code. Frontend devs want to create and use components. You cannot create a component with html templates, not really. It will be a mess. Moving from server rendered html to an api + spa architecture has quite an overhead of course. Just like adding a separate backend service. That price should be worth it. And a good developer can judge whether in which context that is the case. But pretending the benefits that motivate such a change just never justify the costs doesn't make sense to me. The cost of a change is a very, very complex measure. Anyone who has a simple answer to it that is universal, true and useful will win a Nobel Prize. This is because the cost depends on the person who is making it and his peers, on its effects in the future, on the project of which it is a part, on luck and on the larger ecosystem in which it is done. There are just way too many parameters.

bvrmn 2y ago

Also it depends from API response. It could vary from FE dictating schema or backend making hard orthogonal domain modeling API. In first case FE is productive there is no need to transform data but makes BE a hot mess. Otherwise FE have to maintain layer of code to convert BE data to presentable UI data. It's harder but allows to decouple UI reqs from changes along all stack.

IshKebab 2y ago

Yeah this seems like an insane assumption on a language basis. Ruby has no static types (or not very good ones as far as I know) and is very hard to follow due to using "magic" so much. I've contributed several features to VSCode (Typescript) and it was relatively easy. I have completely failed to do the same with Gitlab (Ruby) because the code is so hard to navigate. I did manage to add some features to gitlab-runner but that is written in Go, which again is much easier to follow than Ruby. I think they are really talking about client-side vs server-side rendering. Server-side is much simpler.

deleted 2y ago

[deleted]