4 ms·
I do think its pretty weird to hire someone as a frontend dev and have them in Rails a bunch IF you were in models, controllers, and elsewhere a lot. If the ma
by jmuguy 5y ago
I do think its pretty weird to hire someone as a frontend dev and have them in Rails a bunch IF you were in models, controllers, and elsewhere a lot. If the majority of your work was in views, ERB or otherwise, I don't think its that strange.
There's a sort of all or nothing aspect to how you handle the view layer in Rails, at least for a smaller code base. However, I'm sure Shopify is large enough that they have apps doing a little React, a little server rendered in ERB, and others that are fully React backed with an API, and probably some that don't have any JS framework at all.
- ppeetteerr 5y agoCame here to say the same. Server-side rendered front-end is still front-end. Just because someone doesn't like the stack, doesn't mean it's incorrect. Sounds to me like this person was overwhelmed by the sheer size of the codebase and how little control they had and decided it was not for them. I don't blame them. eCommerce is tough. eCommerce on such a customizable platform must be like walking through a minefield.
- johnatwork 5y agoRight, I'm a React dev, but currently I'm at a point in my project where I have to dip into Flask/Jinja2. It's not "fun" per se in the front-end part, but it's absolutely fine, and what's required for my work. I don't mind it at all, if anything I'm happy and curious about BE/Python and how that part works.
- snemvalts 5y agoIf I need to call Rails services and methods from ERB, then it isn't frontend :) It's comparative to hiring a front-end and putting them to work on .php files. It's so far back in the past, that it becomes degrading, and you start feeling regression in front-end skills.
- powersurge360 5y agoWeb dev seems to be headed in three directions imo: 1) The old style, where the server owns the routing but can cede control over html to the frontend for discreet applications. Always cedes control of JS and CSS to the frontend. 2) A fully separated frontend and backend application that talks to one another over REST or GraphQL 3) A very javascript-light frontend that uses a technology like LiveWire, LiveView, or Hotwire to render on the server but push reactively to the frontend I think any is fine and each have their merits. I imagine that #3 is the one that is most likely to supersede #1 as it's a direct evolution. But I would think that it's a bit gatekeeping to tell someone whose whole job is HTML templates, javascript, and CSS that they are No True Frontender.
- erulabs 5y agoThere was a major release of PHP8 2 months ago. To add to that - JavaScript was invented in 1995. PHP, "so far back in the past", was invented in 1994. It's only regression in the exact language and framework you wanted to use. Certainly not "front-end skills". I worked at a company where our iOS team refused to make multiple API calls for any given view. They wanted 100% of the data for _any_ given activity the user could do to be a single call, formatted how they wanted. I pushed very hard to let that team go, but failed, although I do still chuckle at the horrific reviews the app gets for general bugginess. It's absolutely mind blowing that people getting paid 150k say "well I'll touch that code but _never_ that other code". I hate to paint with broad brush strokes, but I never once saw that attitude from a non-college graduate. Loathed to use the word "entitled", but holy cow.