4 ms·

I haven't gone through this page yet, but thank you for at least the attempt at reaching somebody in my state of affairs. Front End work is very hard. The front

I haven't gone through this page yet, but thank you for at least the attempt at reaching somebody in my state of affairs. Front End work is very hard. The front end design & what I would call the back-end front-end disciplines are supposed to meld together according to job postings and over-zealous recruiters, but it's a good deal more complex than I have been willing to put up with, mostly because of the materials to get started and the unintuitive tools that people who know what they are doing swear by. Imagine being solid at design, pushing pixels, using HTML, CSS. Then suddenly these program frameworks which are created by back-end programmers not visual designers appear and the ramp up for the average technical person is immense. For me it's been enough to turn me off them all together and make it a talking point that "my javascript skills fall off at X,Y or Z" so recruiters and employers know that despite being able to do a lot, I can't suddenly become everything UI and everything back end just because the title of anything "front end" is so versatile.

thirdtruck 11y ago
I feel your pain. Job expectations for front-end work (and, no doubt, other tech areas) have grown terribly incoherent. It seems like a lot of companies expect new hires to train themselves into unicorns on their current employer's time, when they could just hire someone now and give them a decent amount of time to ramp up instead.
- michaelbuddy 11y ago
  I think for the needs of front end, the recruiting world would be better off targeting back end people heavy programmers, maybe .net or java and their migration to the front end frameworks will be much easier than the designers will be. It sounds awesome for a designer to pick up javascript and just run with it, but I personally see a pretty thick wall between focusing on design, graphics, presentation and then solving all the programming problems to go with it. Again personal experience, it's been easier for me to shut off the valve of code completely, so I'm not distracted by consequences of how it will be built. I know that sounds counter intuitive but just knowing some of the avid javascripters, those who can build apps with it, they don't really have the ability to get out of that mode to design something, they are always living the framework. They will make something nice, but alone their work rarely surpasses the level of beauty or refinement of a really good designer artist. Yes I know those hybrids exist, but unfortunately there aren't nearly enough of them to fill all the positions. Not only that, but I'd argue that a lot of them who are hybrids, you're not going to get their best work from both areas if they are expected to deliver from both disciplines on projects. Not on the deadlines that employers will set at least. And I suspect a similar problem exists in actual building architecture. Yeah some building designers are good at accomodating for all the variables of planning codes, but they aren't going to be (nearly as often) fantastic at aesthetics that somebody who works outside those constraints might be capable of. There's a lot of value in designing first, then put those styles of thinking together (designers and architects) separate people and from that point later in the process of creation you start solving the challenges like plumbing codes, metallurgy afterwards. Part of this is me complaining, but it's my attempt at experience of always being a crossover person and how you never really feel like you're honing a craft, you just feel like you're being left behind and not properly cultivating what you enjoy most.
  - ritchiea 11y ago
    The problem is anyone who identifies himself or herself as a backend person probably hates dealing with HTML & CSS. And that's without also getting into the backend devs who also despise Javascript. As far as I can tell anyone who is a backend dev only is saying "I don't want to deal with any of the bullshit on the front end." Good luck convincing those people the next technology they should learn is React or Angular or SCSS.
    - michaelbuddy 11y ago
      fantastic point.
applecore 11y ago
What do you mean? This: var createItem = function(itemText) { return ( <li>{itemText}</li> ); }; return ( <ul>{this.props.items.map(createItem)}</ul> ); ...is clearly so much more logical than: <ul><li>{{item}}</li></ul> Source: https://www.airpair.com/angularjs/posts/angular-vs-react-the-tie-breaker#1-9-templating https://www.airpair.com/angularjs/posts/angular-vs-react-the...
- garry 11y ago
  This obscures React's main strength, which is making it so that you don't have to worry about edge case states. In complex UI's, this is the #1 source of bugs.
  - applecore 11y ago
    For sure! But you should have empathy for the front-end designer who may not totally understand the advantages of React over "traditional" HTML templates and directives.
- cdelsolar 11y ago
  Yes it is. What is {{item}}? Where did it come from?
  - ehsanu1 11y ago
    It's missing the `ng-repeat="item in items"`.
    - pete_mitchell 11y ago
      What is "items" and where did it come from?
      - ehsanu1 11y ago
        It would be some array defined on the angular $scope object, presumably instantiated when an angular directive/controller is instantiated for a component. I'm guessing that's roughly analogous to "this.props" in the react example, though I'm not very familiar with react.
ricardobeat 11y ago
These frameworks are not actually created by back-end programmers, clientside code has become as complex and specialized (sometimes more) than the server in the past decade. But there is still room for good designers who code; plenty of research, user testing and prototyping to be done before getting down the tech rabbit hole. A good team is multi-disciplinary and not necessarily composed of 'unicorns' only.

thirdtruck 11y ago

I feel your pain. Job expectations for front-end work (and, no doubt, other tech areas) have grown terribly incoherent. It seems like a lot of companies expect new hires to train themselves into unicorns on their current employer's time, when they could just hire someone now and give them a decent amount of time to ramp up instead.

michaelbuddy 11y ago
I think for the needs of front end, the recruiting world would be better off targeting back end people heavy programmers, maybe .net or java and their migration to the front end frameworks will be much easier than the designers will be. It sounds awesome for a designer to pick up javascript and just run with it, but I personally see a pretty thick wall between focusing on design, graphics, presentation and then solving all the programming problems to go with it. Again personal experience, it's been easier for me to shut off the valve of code completely, so I'm not distracted by consequences of how it will be built. I know that sounds counter intuitive but just knowing some of the avid javascripters, those who can build apps with it, they don't really have the ability to get out of that mode to design something, they are always living the framework. They will make something nice, but alone their work rarely surpasses the level of beauty or refinement of a really good designer artist. Yes I know those hybrids exist, but unfortunately there aren't nearly enough of them to fill all the positions. Not only that, but I'd argue that a lot of them who are hybrids, you're not going to get their best work from both areas if they are expected to deliver from both disciplines on projects. Not on the deadlines that employers will set at least. And I suspect a similar problem exists in actual building architecture. Yeah some building designers are good at accomodating for all the variables of planning codes, but they aren't going to be (nearly as often) fantastic at aesthetics that somebody who works outside those constraints might be capable of. There's a lot of value in designing first, then put those styles of thinking together (designers and architects) separate people and from that point later in the process of creation you start solving the challenges like plumbing codes, metallurgy afterwards. Part of this is me complaining, but it's my attempt at experience of always being a crossover person and how you never really feel like you're honing a craft, you just feel like you're being left behind and not properly cultivating what you enjoy most.
- ritchiea 11y ago
  The problem is anyone who identifies himself or herself as a backend person probably hates dealing with HTML & CSS. And that's without also getting into the backend devs who also despise Javascript. As far as I can tell anyone who is a backend dev only is saying "I don't want to deal with any of the bullshit on the front end." Good luck convincing those people the next technology they should learn is React or Angular or SCSS.
  - michaelbuddy 11y ago
    fantastic point.

applecore 11y ago

What do you mean? This: var createItem = function(itemText) { return ( <li>{itemText}</li> ); }; return ( <ul>{this.props.items.map(createItem)}</ul> ); ...is clearly so much more logical than: <ul><li>{{item}}</li></ul> Source: https://www.airpair.com/angularjs/posts/angular-vs-react-the-tie-breaker#1-9-templating https://www.airpair.com/angularjs/posts/angular-vs-react-the...

garry 11y ago
This obscures React's main strength, which is making it so that you don't have to worry about edge case states. In complex UI's, this is the #1 source of bugs.
- applecore 11y ago
  For sure! But you should have empathy for the front-end designer who may not totally understand the advantages of React over "traditional" HTML templates and directives.
cdelsolar 11y ago
Yes it is. What is {{item}}? Where did it come from?
- ehsanu1 11y ago
  It's missing the `ng-repeat="item in items"`.
  - pete_mitchell 11y ago
    What is "items" and where did it come from?
    - ehsanu1 11y ago
      It would be some array defined on the angular $scope object, presumably instantiated when an angular directive/controller is instantiated for a component. I'm guessing that's roughly analogous to "this.props" in the react example, though I'm not very familiar with react.

ricardobeat 11y ago

These frameworks are not actually created by back-end programmers, clientside code has become as complex and specialized (sometimes more) than the server in the past decade. But there is still room for good designers who code; plenty of research, user testing and prototyping to be done before getting down the tech rabbit hole. A good team is multi-disciplinary and not necessarily composed of 'unicorns' only.