8 ms·

Front end engineers are not selected for their skills in understanding algorithms and data structures. It's quite easy to speed up a web site if you understand

Front end engineers are not selected for their skills in understanding algorithms and data structures. It's quite easy to speed up a web site if you understand how CPU works on a low level and how Javascript is compiled to machine code, but it requires a lot of knowledge.

walshemj 8y ago
Err you don't need to know how Js is compiled. You need to understand how html css and js work and not cut and paste megabytes of cruft.
mercer 8y ago
Very little knowledge is needed to know how to speed up a website (or keep it from becoming slow). Almost every front-ender I've met, including those who never got beyond inserting jQuery snippets, knows enough.
- walshemj 8y ago
  In 16 plus years of consulting I have had precisely 2 occasions when I found a dev team that knew what they where doing.
  - tyingq 8y ago
    My experience over a similar time period is that most of what appears to be dev team incompetence...isn't. It usually maps to constraints they can't control.
- sureaboutthis 8y ago
  Speeding a site up is one thing. Speeding it up substantially is another and I doubt your example of one who only knows how to insert jQuery snippets knows enough to both understand and implement all the details from server to network to browser.
  - mort96 8y ago
    You don't need to know enough to understand and implement all the details from server to network to browser, you just need to know enough to remove the <script> tags related to ad networks and tracking to see huge load time and ux improvements. It's not really the web developers who are the issue; they just implement what the people above them in the org chart wants. You could argue that the web developers should push back on it more than they do, but I don't buy that they're not knowledgeable enough to fix it. That's not to say that there aren't actual technical issues; the recent trend of throwing front-end frameworks on content-heavy pages, making the users' low-powered phones parse and run hundreds of megabytes of JS before the page can be interacted with, is an example.
    - walshemj 8y ago
      From experience its not the tracking code that's the big slowdown, its poor page design, bloated implementation no you do not need custom fonts. The worst culprit is not knowing how to use photoshop to optimise images properly.
      - cpburns2009 8y ago
        Shouldn't you be using one of the command line image optimizers?
        walshemj 8y ago
        Yes and I have done ;-) but. 1 A lot of the front end production staff wont be comfortable using a cli - its designers that should be providing the images not developers. 2 Photoshop in some ways produces better results and is already part of the work flow.
    - sureaboutthis 8y ago
      If one thinks all they need to do is remove javascript to speed things up substantially, then they fit into my category of people who only know jQuery snippets only think they know enough. There are a multitude of issues that can be tweaked to speed things up more so than javascript elimination. You can switch to HTTP/2, implement server push, image compression, header compression, compressing HTML/CSS/Javascript downloads, preloading, above-the-fold downloads, and much more. A jQuery plugin user might not know half those things and I only mentioned maybe half the things one should know.
- izacus 8y ago
  > Very little knowledge is needed to know how to speed up a website (or keep it from becoming slow). Almost every front-ender I've met, including those who never got beyond inserting jQuery snippets, knows enough. And yet somehow they decided to not use that knowledge until Google pushed them into corner.
untog 8y ago
Haha what? You absolutely do not need to understand how a CPU works to make a fast site. 90% of the job is getting rid of shitty third party ad and tracking code, something most front engineers don't control. Beyond that most is just sensible practices. In depth knowledge of the DOM would serve you a lot better than knowing about CPUs. What triggers a repaint, how you can avoid it, and so on.
- hnuser355 8y ago
  We were looking for someone to do basic web dev for us, but when our leading candidate failed to even derive KKT conditions from scratch in our interview we simply had to eject him from the candidate pool
  - freedomben 8y ago
    Did you find someone? "basic web dev" and "derive KKT conditions from scratch" do not sound like combinations that I would expect to find often, but it's always interesting to hear about different industries/expectations out there.
    - hnuser355 8y ago
      Sorry it was a joke :)
      - freedomben 8y ago
        Oh haha, it was an excellent joke then cause I lol'ed :-D
  - hitsthings 8y ago
    I am praying this is a joke.
hellisothers 8y ago
The obsession with data structures and algos is getting out of control, cargo culting this idea around is going to lead to requiring an L5 to change a button color.
- grogenaut 8y ago
  If setting the color theme for the company having a l7 make that choice would be reasonable. One site I worked on had 172 shades of the main color by engineers "guessed". An l6 spent over a year in comitte and editor dropping that to 16.
yowlingcat 8y ago
The reason you're being downvoted is not necessarily because the first part of your broad sweeping generalization is always wrong. At least at the more junior levels, frontend focused engineers don't always have the same level of DS&A fundamentals as backend focused engineers. However, many engineers usually run into their first performance related issue in the first few years of their on the job experience, at which point they learn to speed things up. It's in the second part of your statement where you're completely and totally wrong. Speeding things up on the whole does not require a lot of knowledge, and it does not require understanding how the cpu works at a low level and how javascript is compiled to machine code. Knowing how that stuff works can help you squeeze the last 1% of optimization out of code, but in practice, you get the first 99% of speed from decisions: - Which frameworks do you use? - What "add-ons" that are key to business do you end up embedding in the front-end and how much page size and slow down do they add? - Where are your hot loops? Are you doing anything expensive inside them? - Do you have things that are synchronous where they could be in parallel? - How much eye candy are you adding to the page? Does it all need to be there? - How much CSS are you using? Are you using it in a manner where CSS optimizations can do heavy lifting? - What does the frontend and the backend API contract look like? Are there places where excess requests are occurring, and could they be rolled up so that there is less waste? You may have noticed that many of these decisions boil down to architectural concerns as well as product and business level decisions, which are tangentially related to the labor of front-end engineering. I don't want to lob ad-hominems at people, but I find this kind of attitude one of the most tiresome parts about certain parts of the engineering community. There's this haughty, holier than thou mentality that places data structures and algorithms at the very top of engineering skills. There's a giant world out there where those skills are not at the top of the hierarchy, and actually are least useful because any sufficiently advanced development there ends up being commodified and available as open source software or as a paid SaaS (IE AWS). Based on this short, flippant comment, it's obvious you actually have no idea how to actually speed up a web site because you have no idea about what the actual top ten things are that you'd do to speed it up in any kind of commercial production usage. What's even worse is that instead of trying to figure out something you don't know, you're instead making up an answer that sounds reasonable but is actually completely wrong and something any experienced frontend or full-stack engineer would understand is poor judgment and an ineffective approach. This is an extremely dangerous attitude to allow into an organization, because you end up with a culture where people are focused on one-upping each other and attempting to look elite as opposed to pragmatically arriving at the right approach for the problem, specific to all of its constraints. I've worked on these kinds of teams before, and it ends up being a miserable waste of time for everyone involved, and I've endeavored to work on teams that don't behave this way and to create teams that don't suffer from this. Any engineer that gave this kind of a response to an interview question of "We've got a web app that's slow on the frontend and exhibiting XYZ symptoms -- how would you determine the root cause and diagnose it" would be rejected on the spot by me. That's the kind of attitude that can cause engineering organizations millions of dollars a year in engineering resource misallocation. As a professional community, we need to evolve away from attitudes like yours. They symbolize an idealized, fictional world that is anything but the pragmatic reality of what good software engineering is.
dang 8y ago
We detached this subthread from https://news.ycombinator.com/item?id=18693451 https://news.ycombinator.com/item?id=18693451 and marked it off-topic.

walshemj 8y ago

Err you don't need to know how Js is compiled. You need to understand how html css and js work and not cut and paste megabytes of cruft.

mercer 8y ago

Very little knowledge is needed to know how to speed up a website (or keep it from becoming slow). Almost every front-ender I've met, including those who never got beyond inserting jQuery snippets, knows enough.

walshemj 8y ago
In 16 plus years of consulting I have had precisely 2 occasions when I found a dev team that knew what they where doing.
- tyingq 8y ago
  My experience over a similar time period is that most of what appears to be dev team incompetence...isn't. It usually maps to constraints they can't control.
sureaboutthis 8y ago
Speeding a site up is one thing. Speeding it up substantially is another and I doubt your example of one who only knows how to insert jQuery snippets knows enough to both understand and implement all the details from server to network to browser.
- mort96 8y ago
  You don't need to know enough to understand and implement all the details from server to network to browser, you just need to know enough to remove the <script> tags related to ad networks and tracking to see huge load time and ux improvements. It's not really the web developers who are the issue; they just implement what the people above them in the org chart wants. You could argue that the web developers should push back on it more than they do, but I don't buy that they're not knowledgeable enough to fix it. That's not to say that there aren't actual technical issues; the recent trend of throwing front-end frameworks on content-heavy pages, making the users' low-powered phones parse and run hundreds of megabytes of JS before the page can be interacted with, is an example.
  - walshemj 8y ago
    From experience its not the tracking code that's the big slowdown, its poor page design, bloated implementation no you do not need custom fonts. The worst culprit is not knowing how to use photoshop to optimise images properly.
    - cpburns2009 8y ago
      Shouldn't you be using one of the command line image optimizers?
      - walshemj 8y ago
        Yes and I have done ;-) but. 1 A lot of the front end production staff wont be comfortable using a cli - its designers that should be providing the images not developers. 2 Photoshop in some ways produces better results and is already part of the work flow.
  - sureaboutthis 8y ago
    If one thinks all they need to do is remove javascript to speed things up substantially, then they fit into my category of people who only know jQuery snippets only think they know enough. There are a multitude of issues that can be tweaked to speed things up more so than javascript elimination. You can switch to HTTP/2, implement server push, image compression, header compression, compressing HTML/CSS/Javascript downloads, preloading, above-the-fold downloads, and much more. A jQuery plugin user might not know half those things and I only mentioned maybe half the things one should know.
izacus 8y ago
> Very little knowledge is needed to know how to speed up a website (or keep it from becoming slow). Almost every front-ender I've met, including those who never got beyond inserting jQuery snippets, knows enough. And yet somehow they decided to not use that knowledge until Google pushed them into corner.

untog 8y ago

Haha what? You absolutely do not need to understand how a CPU works to make a fast site. 90% of the job is getting rid of shitty third party ad and tracking code, something most front engineers don't control. Beyond that most is just sensible practices. In depth knowledge of the DOM would serve you a lot better than knowing about CPUs. What triggers a repaint, how you can avoid it, and so on.

hnuser355 8y ago
We were looking for someone to do basic web dev for us, but when our leading candidate failed to even derive KKT conditions from scratch in our interview we simply had to eject him from the candidate pool
- freedomben 8y ago
  Did you find someone? "basic web dev" and "derive KKT conditions from scratch" do not sound like combinations that I would expect to find often, but it's always interesting to hear about different industries/expectations out there.
  - hnuser355 8y ago
    Sorry it was a joke :)
    - freedomben 8y ago
      Oh haha, it was an excellent joke then cause I lol'ed :-D
- hitsthings 8y ago
  I am praying this is a joke.

hellisothers 8y ago

The obsession with data structures and algos is getting out of control, cargo culting this idea around is going to lead to requiring an L5 to change a button color.

grogenaut 8y ago
If setting the color theme for the company having a l7 make that choice would be reasonable. One site I worked on had 172 shades of the main color by engineers "guessed". An l6 spent over a year in comitte and editor dropping that to 16.

yowlingcat 8y ago

The reason you're being downvoted is not necessarily because the first part of your broad sweeping generalization is always wrong. At least at the more junior levels, frontend focused engineers don't always have the same level of DS&A fundamentals as backend focused engineers. However, many engineers usually run into their first performance related issue in the first few years of their on the job experience, at which point they learn to speed things up. It's in the second part of your statement where you're completely and totally wrong. Speeding things up on the whole does not require a lot of knowledge, and it does not require understanding how the cpu works at a low level and how javascript is compiled to machine code. Knowing how that stuff works can help you squeeze the last 1% of optimization out of code, but in practice, you get the first 99% of speed from decisions: - Which frameworks do you use? - What "add-ons" that are key to business do you end up embedding in the front-end and how much page size and slow down do they add? - Where are your hot loops? Are you doing anything expensive inside them? - Do you have things that are synchronous where they could be in parallel? - How much eye candy are you adding to the page? Does it all need to be there? - How much CSS are you using? Are you using it in a manner where CSS optimizations can do heavy lifting? - What does the frontend and the backend API contract look like? Are there places where excess requests are occurring, and could they be rolled up so that there is less waste? You may have noticed that many of these decisions boil down to architectural concerns as well as product and business level decisions, which are tangentially related to the labor of front-end engineering. I don't want to lob ad-hominems at people, but I find this kind of attitude one of the most tiresome parts about certain parts of the engineering community. There's this haughty, holier than thou mentality that places data structures and algorithms at the very top of engineering skills. There's a giant world out there where those skills are not at the top of the hierarchy, and actually are least useful because any sufficiently advanced development there ends up being commodified and available as open source software or as a paid SaaS (IE AWS). Based on this short, flippant comment, it's obvious you actually have no idea how to actually speed up a web site because you have no idea about what the actual top ten things are that you'd do to speed it up in any kind of commercial production usage. What's even worse is that instead of trying to figure out something you don't know, you're instead making up an answer that sounds reasonable but is actually completely wrong and something any experienced frontend or full-stack engineer would understand is poor judgment and an ineffective approach. This is an extremely dangerous attitude to allow into an organization, because you end up with a culture where people are focused on one-upping each other and attempting to look elite as opposed to pragmatically arriving at the right approach for the problem, specific to all of its constraints. I've worked on these kinds of teams before, and it ends up being a miserable waste of time for everyone involved, and I've endeavored to work on teams that don't behave this way and to create teams that don't suffer from this. Any engineer that gave this kind of a response to an interview question of "We've got a web app that's slow on the frontend and exhibiting XYZ symptoms -- how would you determine the root cause and diagnose it" would be rejected on the spot by me. That's the kind of attitude that can cause engineering organizations millions of dollars a year in engineering resource misallocation. As a professional community, we need to evolve away from attitudes like yours. They symbolize an idealized, fictional world that is anything but the pragmatic reality of what good software engineering is.

dang 8y ago

We detached this subthread from https://news.ycombinator.com/item?id=18693451 https://news.ycombinator.com/item?id=18693451 and marked it off-topic.