5 ms·

> I can't help but think this is just a whole bunch of people up in arms about not wanting to learn something 'all the cool kids' are. There may be that. There

by porker 11y ago

> I can't help but think this is just a whole bunch of people up in arms about not wanting to learn something 'all the cool kids' are. There may be that. There's also: a) Some of us are old enough to have mortages/kids/parents to support/houses needing renovation/desire a balanced life. We value skills that stay useful, and don't have the free time to keep learning variants of the same again and again* b) Companies we work at/for value stability. They look at IT choices on a 5+year horizon; they don't have VC money to burn to 'rewrite' when JavaScript framework X no longer works. Which am I more likely to get sacked for? 1) Not using the cool thing and us missing out, or 2) using the cool thing and having to explain in 18 months time that we need another $20,000 to rewrite it into the Next Cool Thing? Before you write us off, please do a 360 and see what the field looks like from other perspectives. * I didn't say 'don't have time to learn'. We learn - but what we learn is evaluated carefully, and we have a much wider field to learn (Programming/Management/PM/Negotation - just a few of the core work-focused skills) [Edited for formatting]

madeofpalk 11y ago
Why is everyone so anxious about this? That's the part that confuses me. When we introduced a library for a new project (at a Big Old Media Company with a team varying from interns, to working-70-hours-a-week millennials, to 9-5 family people) it was fine. If someone had something to learn about one of the 5 APIs, they read the entire library documentation (which takes like 20 minutes) or just turned around and asked someone.\ I'm not convinced we found the only developers who like React, but it does seem like there's a certain audience of people (which overlaps heavily with HN) who love to complain about their self-inflicted anxiety.
- porker 11y ago
  > When we introduced a library for a new project Great, a real data point! From this and previous comments, I'm guessing the library was React? And from another comment on this page, you haven't bolted-on multiple libraries for form handling, routing etc. A few questions: * What is the projected lifetime of the new project? * Will the code be updated continuously (vs write once & freeze)? * What does your ecosystem around React look like? * What library/framework were you using before which you replaced with React? * Have yoiu committed to using React on new projects for the next.. 24 months? It'd be great to learn more, as it sounds like a non-Facebook scale project, i.e. more relevant to most of us... AFAICT no one in this thread is saying they don't like React, or if $Company paid them to learn it they wouldn't (paid learning time, what's not to love?). It's about the pace of change, reinvention, and expectation to use latest and greatest and be future-proof.
  - Klathmon 11y ago
    >expectation to use latest and greatest and be future-proof In javascript (just like in any other programming language) you generally get one or the other. You can have the "cutting edge" features or libraries, or you can stay a bit behind and have one that's stable and will stick around for a while. People are using features of JS that aren't even in the spec yet then getting burnt out when they break in the future? Using a library at version 0.0.3 and getting upset when 2.4.3 breaks something? There is nothing wrong with using mature systems, and that's why I personally feel all of this "javascript fatigue" is self inflicted. If it is going to be a project you write once then don't touch for 5 years, maybe don't use react 0.15.beta-4 as your library of choice...
pjmlp 11y ago
Fully agree with you. Coding since the 80's in all types of stacks, frontend, backend, native, web, you name it. Whatever the projects require. Nowadays doing native development just feels relaxing compared to the chaos of web based frontends.
- weego 11y ago
  Agree. The worst issue for me is how unfocused the efforts are. I experienced issues at a large media company where new features to the public site to improve user experience where delayed for entire sprints because someone in the team became obsessed with the notion that their env was wrong because they were using grunt instead of gulp, or they used a particular Sass processor that relied on Ruby and they could use one that was pure JS. I quite like writing JS and have done on and off for over 17 years, I just don't understand the constant and wilful reinvention and fragmentation in front end development.
  - Klathmon 11y ago
    That sounds like your developer's problem, not the technology's problem. Would you blame the language C++ if the developer was constantly compiling their own compiler from master every single day and spending hours upon hours dealing with that?
    - weego 11y ago
      It wasn't a single developer, it was a subset culture in the team of frontend developers. Those 2 examples were 2 different devs. I don't really get your point though. Are suggesting that JS fragments and reinvents itself outside of the will of the general populace of frontend developers? How else could the problems in frontend dev arise if not from the culture created by the people?
      - deleted 11y ago
        [deleted]
    - mtberatwork 11y ago

by porker 11y ago

madeofpalk 11y ago

Why is everyone so anxious about this? That's the part that confuses me. When we introduced a library for a new project (at a Big Old Media Company with a team varying from interns, to working-70-hours-a-week millennials, to 9-5 family people) it was fine. If someone had something to learn about one of the 5 APIs, they read the entire library documentation (which takes like 20 minutes) or just turned around and asked someone.\ I'm not convinced we found the only developers who like React, but it does seem like there's a certain audience of people (which overlaps heavily with HN) who love to complain about their self-inflicted anxiety.

porker 11y ago
> When we introduced a library for a new project Great, a real data point! From this and previous comments, I'm guessing the library was React? And from another comment on this page, you haven't bolted-on multiple libraries for form handling, routing etc. A few questions: * What is the projected lifetime of the new project? * Will the code be updated continuously (vs write once & freeze)? * What does your ecosystem around React look like? * What library/framework were you using before which you replaced with React? * Have yoiu committed to using React on new projects for the next.. 24 months? It'd be great to learn more, as it sounds like a non-Facebook scale project, i.e. more relevant to most of us... AFAICT no one in this thread is saying they don't like React, or if $Company paid them to learn it they wouldn't (paid learning time, what's not to love?). It's about the pace of change, reinvention, and expectation to use latest and greatest and be future-proof.
- Klathmon 11y ago
  >expectation to use latest and greatest and be future-proof In javascript (just like in any other programming language) you generally get one or the other. You can have the "cutting edge" features or libraries, or you can stay a bit behind and have one that's stable and will stick around for a while. People are using features of JS that aren't even in the spec yet then getting burnt out when they break in the future? Using a library at version 0.0.3 and getting upset when 2.4.3 breaks something? There is nothing wrong with using mature systems, and that's why I personally feel all of this "javascript fatigue" is self inflicted. If it is going to be a project you write once then don't touch for 5 years, maybe don't use react 0.15.beta-4 as your library of choice...

pjmlp 11y ago

Fully agree with you. Coding since the 80's in all types of stacks, frontend, backend, native, web, you name it. Whatever the projects require. Nowadays doing native development just feels relaxing compared to the chaos of web based frontends.

weego 11y ago
Agree. The worst issue for me is how unfocused the efforts are. I experienced issues at a large media company where new features to the public site to improve user experience where delayed for entire sprints because someone in the team became obsessed with the notion that their env was wrong because they were using grunt instead of gulp, or they used a particular Sass processor that relied on Ruby and they could use one that was pure JS. I quite like writing JS and have done on and off for over 17 years, I just don't understand the constant and wilful reinvention and fragmentation in front end development.
- Klathmon 11y ago
  That sounds like your developer's problem, not the technology's problem. Would you blame the language C++ if the developer was constantly compiling their own compiler from master every single day and spending hours upon hours dealing with that?
  - weego 11y ago
    It wasn't a single developer, it was a subset culture in the team of frontend developers. Those 2 examples were 2 different devs. I don't really get your point though. Are suggesting that JS fragments and reinvents itself outside of the will of the general populace of frontend developers? How else could the problems in frontend dev arise if not from the culture created by the people?
    - deleted 11y ago
      [deleted]
  - mtberatwork 11y ago