8 ms·

Isn't it a fun time to be a front-end developer?

baybal2 9y ago
>Isn't it a fun time to be a front-end developer? No. I came to frontend development on the peak of web 2.0 craze, when 10mb of jQuery "bells and whistles" on a corporate front page was considered hip and progressive. No matter how awful these 10mb of animation scripts were, they ran faster than 1mb of "highly optimised" react spa today.
- meandmycode 9y ago
  Can you really prove that feeling? because that's far from my experience and far from logical too.. Additionally, this 'fatigue' with front-end is getting a bit over told, I suspect it might be more alienation from developers who hacked jquery scripts together and feel they need to transition to app frameworks (I see so many simple websites and landing pages as react etc now).. where as those sites should just transition to vanilla js + dom.. The thing about inspired frameworks and 'churn' isn't a javascript/front-end thing, it happens everywhere, constantly... how many IOC, DI, ORM frameworks did Java and .NET have..
  - eterm 9y ago
    My perspective is this: A lot of people got a lot of productive work done 'hacking' together jquery and jquery-ui scripts. The result wasn't pretty and was a bit of a maintenance nightmare. They are not only a bit of alienated by having to work with frameworks, but they're expected to be as productive with these frameworks as they were hacking together jquery scripts and snippets, but are still the 1-man or 2-man developers within a wider business. These frameworks are great in a business built around the web such as a SAAS business, but a lot of people are in businesses where their saas part is secondary, or are trying to maintain sites which just aren't the main product of the business. They're pressured by well meaning but often misguided higher-ups to use the latest and greatest and feel the pressure of churn.
    - baybal2 9y ago
      >They are not only a bit of alienated by having to work with frameworks, but they're expected to be as productive with these frameworks as they were hacking together jquery scripts and snippets, but are still the 1-man or 2-man developers within a wider business. So so so true... but I can give a correction to the size of the team. I personally witnessed 10 to 45 man teams doing things as simple as a web app with a sole function being "login, enter account number to send money to, enter amount of money to send, and press the button" While 45 is a bit of exaggeration on my side, as it counts team's own accountants, HRs, and 20 something PMs, "change manager" types, and other obscure managers of managers
  - baybal2 9y ago
    >Can you really prove that feeling? because that's far from my experience and far from logical too.. Cyclomatic complexity went up many times. Going over a simple for loop in under 100 kilocycles for client side page generation was considered ok back 10 years ago. Even then, browsers had no problem with that. Compare that with 20 plus layers of deep merges, with closure tricks, with prototype swapping on the fly in a transpiled observer pattern style input event handler - things like that you have in relatively simple SPAs today
    - brlewis 9y ago
      I wouldn't describe modern front-end web dev that way at all. Here's how I describe it: https://medium.com/front-end-hacking/how-it-feels-to-learn-javascript-in-2017-a934b801fbe https://medium.com/front-end-hacking/how-it-feels-to-learn-j...
      - eropple 9y ago
        FWIW, this post is awesome. Thank you for sharing it. I just submitted it: https://news.ycombinator.com/item?id=15108546 https://news.ycombinator.com/item?id=15108546
iansowinski 9y ago
Well, I think that compared to other fields, it's quite hard to get on board - there is so much tooling that it's really hard to catch up. There is node, npm/yarn, webpack, gulp, scss/sass. If you're back-end dev coding in ruby, you just pick rails and you're done if you're python webdeveloper, you pick django, and so on. With front-end? After hours of fighting with Babel and Webpack, you can pick Angular, React or Vue. And it's hard to know witch one to choose if you're some beginner who just want to code efficiently.
- shados 9y ago
  if you make a simple backend thing, pick up rail and you're done, but you're essentially building something that's a solved problem. The frontend equivalent is dropping a script tag on a page and uploading it by FTP. But there's a reason backend communities accepted devops long before frontend. Between all of the various BE platforms, all with their own dependency management intricacy, all the various databases, big data stores, queues, streams, object stores, cache systems, containers (docker, VMs, etc), the OS (for FE you can just drop your stuff on S3 and stick a CDN in front and it will scale to near infinity...try to scale your rails app like that for giggles). BE is 100x worse.
  - iansowinski 9y ago
    Yes, but STARGING in backend is easier. I don't try to say that FE is harder, just that this wall between beginner and modern standards is higher here. After this wall it's probably harder in BE that in FE, but I think this wall is higher for FE devs.
  - deleted 9y ago
    [deleted]
bartread 9y ago
No: it leaves no goat unblown. Particularly for people new to it. Back in the day anyone could hack together a bit of JS for their website and get something up and running, even if it was a bit Heath Robinson. You actually still can do this but you wouldn't necessarily come away with that impression from reading about front-end development. Cynically, it sometimes feels like front-end developers are overcompensating for years of JS derision from "real" programmers with the plethora of tools and technologies you "need" to know. If people want to use this, well, they're welcome. I can even see some benefit to a very lightweight UI/framework, especially if you don't have to worry about any version of Internet Explorer below 11, because the browser APIs these days are pretty comprehensive, and tend to behave reasonably consistently. Likewise CSS. [1] Still, I can't get in any way excited about yet another library/framework. Go ahead and use it if you like but don't be trying to evangelise me about it. ([1] As an aside: I will say that IE11 is still something of a problem child in terms of not supporting some things I use, or not supporting them well - flexbox is an obvious example. Conversely, "scumbag" Chrome can be a problem child simply because it lets you get away with doing things that you shouldn't be allowed to do at all. E.g., `element.style = 'display: none'` instead of `element.style.display = 'none'`, meaning that when you come to test your code in other browsers... it breaks.)
- greyskull 9y ago
  > it leaves no goat unblown That's a first. Is that a common saying somewhere? Does it refer to literal oral sex with a goat?
  - bartread 9y ago
    Sadly I cannot claim it as my own: http://www.urbandictionary.com/define.php?term=blows%20goats http://www.urbandictionary.com/define.php?term=blows%20goats.
  - dasil003 9y ago
    "blows goats" goes back decades, but tbh I never really thought about what it meant until this comment came forth with the hyperbole of fellating literally every goat in existence.
ng12 9y ago
Hell yeah! We're finally iterating on the problems that have made web development suck -- state management, non-imperative models, reasonable abstraction layers, modularization, etc. Fatigue is a good problem to have, it means people are trying really hard to solve important problems.
- mmargerum 9y ago
  Part of the fatigue is the analysis paralysis everyone is suffering waiting for things to settle down. Also rewriting everything every five years has a way of fatiguing a person. Meanwhile I have 20 year old object pascal code continuing to work and run in production. Even iOS which is a fast moving target provides fantastic compatibility with older code that I wrote in 2009
brylie 9y ago
This is why I am orienting my frontend work towards Web Components. There are several libraries/frameworks that enable us to write Web Components now, even though browser support for the spec isn't fully there. E.g. [Aurelia](http://aurelia.io/ http://aurelia.io/) and [Polymer](https://www.polymer-project.org/ https://www.polymer-project.org/) have great features, component APIs, and cross-browser support.
- dmitriid 9y ago
  > This is why I am orienting my frontend work towards Web Components. ... > There are several libraries/frameworks > browser support for the spec isn't fully there. The irony is lost on frontend developers

>Isn't it a fun time to be a front-end developer? No. I came to frontend development on the peak of web 2.0 craze, when 10mb of jQuery "bells and whistles" on a corporate front page was considered hip and progressive. No matter how awful these 10mb of animation scripts were, they ran faster than 1mb of "highly optimised" react spa today.

meandmycode 9y ago
Can you really prove that feeling? because that's far from my experience and far from logical too.. Additionally, this 'fatigue' with front-end is getting a bit over told, I suspect it might be more alienation from developers who hacked jquery scripts together and feel they need to transition to app frameworks (I see so many simple websites and landing pages as react etc now).. where as those sites should just transition to vanilla js + dom.. The thing about inspired frameworks and 'churn' isn't a javascript/front-end thing, it happens everywhere, constantly... how many IOC, DI, ORM frameworks did Java and .NET have..
- eterm 9y ago
  My perspective is this: A lot of people got a lot of productive work done 'hacking' together jquery and jquery-ui scripts. The result wasn't pretty and was a bit of a maintenance nightmare. They are not only a bit of alienated by having to work with frameworks, but they're expected to be as productive with these frameworks as they were hacking together jquery scripts and snippets, but are still the 1-man or 2-man developers within a wider business. These frameworks are great in a business built around the web such as a SAAS business, but a lot of people are in businesses where their saas part is secondary, or are trying to maintain sites which just aren't the main product of the business. They're pressured by well meaning but often misguided higher-ups to use the latest and greatest and feel the pressure of churn.
  - baybal2 9y ago
    >They are not only a bit of alienated by having to work with frameworks, but they're expected to be as productive with these frameworks as they were hacking together jquery scripts and snippets, but are still the 1-man or 2-man developers within a wider business. So so so true... but I can give a correction to the size of the team. I personally witnessed 10 to 45 man teams doing things as simple as a web app with a sole function being "login, enter account number to send money to, enter amount of money to send, and press the button" While 45 is a bit of exaggeration on my side, as it counts team's own accountants, HRs, and 20 something PMs, "change manager" types, and other obscure managers of managers
- baybal2 9y ago
  >Can you really prove that feeling? because that's far from my experience and far from logical too.. Cyclomatic complexity went up many times. Going over a simple for loop in under 100 kilocycles for client side page generation was considered ok back 10 years ago. Even then, browsers had no problem with that. Compare that with 20 plus layers of deep merges, with closure tricks, with prototype swapping on the fly in a transpiled observer pattern style input event handler - things like that you have in relatively simple SPAs today
  - brlewis 9y ago
    I wouldn't describe modern front-end web dev that way at all. Here's how I describe it: https://medium.com/front-end-hacking/how-it-feels-to-learn-javascript-in-2017-a934b801fbe https://medium.com/front-end-hacking/how-it-feels-to-learn-j...
    - eropple 9y ago
      FWIW, this post is awesome. Thank you for sharing it. I just submitted it: https://news.ycombinator.com/item?id=15108546 https://news.ycombinator.com/item?id=15108546

iansowinski 9y ago

Well, I think that compared to other fields, it's quite hard to get on board - there is so much tooling that it's really hard to catch up. There is node, npm/yarn, webpack, gulp, scss/sass. If you're back-end dev coding in ruby, you just pick rails and you're done if you're python webdeveloper, you pick django, and so on. With front-end? After hours of fighting with Babel and Webpack, you can pick Angular, React or Vue. And it's hard to know witch one to choose if you're some beginner who just want to code efficiently.

shados 9y ago
if you make a simple backend thing, pick up rail and you're done, but you're essentially building something that's a solved problem. The frontend equivalent is dropping a script tag on a page and uploading it by FTP. But there's a reason backend communities accepted devops long before frontend. Between all of the various BE platforms, all with their own dependency management intricacy, all the various databases, big data stores, queues, streams, object stores, cache systems, containers (docker, VMs, etc), the OS (for FE you can just drop your stuff on S3 and stick a CDN in front and it will scale to near infinity...try to scale your rails app like that for giggles). BE is 100x worse.
- iansowinski 9y ago
  Yes, but STARGING in backend is easier. I don't try to say that FE is harder, just that this wall between beginner and modern standards is higher here. After this wall it's probably harder in BE that in FE, but I think this wall is higher for FE devs.
- deleted 9y ago
  [deleted]

bartread 9y ago

No: it leaves no goat unblown. Particularly for people new to it. Back in the day anyone could hack together a bit of JS for their website and get something up and running, even if it was a bit Heath Robinson. You actually still can do this but you wouldn't necessarily come away with that impression from reading about front-end development. Cynically, it sometimes feels like front-end developers are overcompensating for years of JS derision from "real" programmers with the plethora of tools and technologies you "need" to know. If people want to use this, well, they're welcome. I can even see some benefit to a very lightweight UI/framework, especially if you don't have to worry about any version of Internet Explorer below 11, because the browser APIs these days are pretty comprehensive, and tend to behave reasonably consistently. Likewise CSS. [1] Still, I can't get in any way excited about yet another library/framework. Go ahead and use it if you like but don't be trying to evangelise me about it. ([1] As an aside: I will say that IE11 is still something of a problem child in terms of not supporting some things I use, or not supporting them well - flexbox is an obvious example. Conversely, "scumbag" Chrome can be a problem child simply because it lets you get away with doing things that you shouldn't be allowed to do at all. E.g., `element.style = 'display: none'` instead of `element.style.display = 'none'`, meaning that when you come to test your code in other browsers... it breaks.)

greyskull 9y ago
> it leaves no goat unblown That's a first. Is that a common saying somewhere? Does it refer to literal oral sex with a goat?
- bartread 9y ago
  Sadly I cannot claim it as my own: http://www.urbandictionary.com/define.php?term=blows%20goats http://www.urbandictionary.com/define.php?term=blows%20goats.
- dasil003 9y ago
  "blows goats" goes back decades, but tbh I never really thought about what it meant until this comment came forth with the hyperbole of fellating literally every goat in existence.

ng12 9y ago

Hell yeah! We're finally iterating on the problems that have made web development suck -- state management, non-imperative models, reasonable abstraction layers, modularization, etc. Fatigue is a good problem to have, it means people are trying really hard to solve important problems.

mmargerum 9y ago
Part of the fatigue is the analysis paralysis everyone is suffering waiting for things to settle down. Also rewriting everything every five years has a way of fatiguing a person. Meanwhile I have 20 year old object pascal code continuing to work and run in production. Even iOS which is a fast moving target provides fantastic compatibility with older code that I wrote in 2009

brylie 9y ago

This is why I am orienting my frontend work towards Web Components. There are several libraries/frameworks that enable us to write Web Components now, even though browser support for the spec isn't fully there. E.g. [Aurelia](http://aurelia.io/ http://aurelia.io/) and [Polymer](https://www.polymer-project.org/ https://www.polymer-project.org/) have great features, component APIs, and cross-browser support.

dmitriid 9y ago
> This is why I am orienting my frontend work towards Web Components. ... > There are several libraries/frameworks > browser support for the spec isn't fully there. The irony is lost on frontend developers