5 ms·

+1. For example, according to one of their job listings[1], Twitter currently has 25 people working on the main twitter.com experience. Twenty-five people! For

+1. For example, according to one of their job listings[1], Twitter currently has 25 people working on the main twitter.com experience. Twenty-five people! For a Twitter client! And they're still trying to hire more! (Important to keep in mind: this doesn't include any of the people working on the database, or the advertising algorithm, or the server architecture, or any of the other hard problems Twitter faces. This is just the team that writes the JavaScript code that takes the Tweets from the JSON API response and puts them onto the screen.) [1] https://careers.twitter.com/en/work-for-twitter/201910/twitter-com-senior-javascript-engineer.html https://careers.twitter.com/en/work-for-twitter/201910/twitt...

taurath 7y ago
The amount of ignorance of the complexity required in a globally reachable frontend web app is astounding in this thread.
- csande17 7y ago
  I understand why it's hard to make a popular, globally-reachable web service -- you have to run a bunch of servers in different locations, and distribute the database, and solve concurrency problems and stuff. So I get why Twitter might have large back-end and ops teams. But client-side code doesn't have scaling issues like that. If I put some JavaScript code in a static file, it'll work exactly the same when 1 person runs it as when a million people run it. What "complexity" is Twitter's front-end team facing as a result of their global reach? Like, I guess they have to localize their app, but the hard part there is getting the text translated; the technical implementation is usually as easy as putting all your UI strings in a dictionary that you swap out based on the user's language. (Maybe if they're extra fancy, they make a version of their stylesheet that flips the layout horizontally for Arabic users.)
  - x0x0 7y ago
    I doubt you've ever done a translation in a large webapp. Wait until German overflows your text boxes. Or you have to deal with date formats and number formats and ... And rtl languages are just a stylesheet away. Hah, but no. And how many devices across how many OSes do you test on? Particularly all the devices that functionally no one in the global north purchases? What is your accessibility test plan and how often do you run it?
    - TeMPOraL 7y ago
      > Wait until German overflows your text boxes. Or you have to deal with date formats and number formats and ... And rtl languages are just a stylesheet away. Web browsers handle all of that correctly by default. A big part of web bloat is just developers including frameworks and libraries than break things by trying to reimplement them in a way more convenient for devs and designers - and then having to include more libraries and custom code to fix the breakage. All of that is self-inflicted.
      - dx034 7y ago
        > Web browsers handle all of that correctly by default. Unfortunately, they don't. Many websites don't look nice in languages that tend to have longer words (e.g. German). Yes, the browser will cut if off so that it doesn't destroy the design. But that makes it unreadable and not nice to use for speakers of that language. To have a beautiful design that works with many translations is an enormous task.
  - as1mov 7y ago
    I used to do fullstack development, but have recently moved to pretty much full time backend because the amount of headache present in the frontend dev. > If I put some JavaScript code in a static file, it'll work exactly the same when 1 person runs it as when a million people run it. No it wouldn't, because the million people have million different devices with different screen sizes, browser implementation and HTML/CSS/JS support for standards. The website should render properly on devices ranging from 5" mobile screens to 32" 4k monitors, while looking beautiful. This is in addition to proper support for multiple languages, accessibility features, and whatever new-fangled PWA bullshit that the business team wants. Implying that frontend is `just` making API calls and putting JSON responses on the screen reeks of naivety. This could've been true in 2005, but in 2019 unfortunately websites have taken place of full blown desktop apps, and are required to behave as one. There's a reason why frontend dev is a specialist job position now and pays on par with backend dev.
  - Izkata 7y ago
    > (Maybe if they're extra fancy, they make a version of their stylesheet that flips the layout horizontally for Arabic users.) Twitter does do that.
  - ericb 7y ago
    Often on Hacker News, and other places too, I see an argument where one person is hand-waving away a task and saying how easy and trivial it is. The simple heuristic for deciding which person is correct is that the one saying it is simple and easy is always wrong.
threeseed 7y ago
So you think you know how to run Twitter Engineering better than Twitter ? That's a pretty confident claim. Anyway Twitter.com could include writing all of the Javascript for advertising management e.g. creating new ads, content management e.g. deleting/reviewing Tweets as well as the various types of Tweet content e.g. videos, VR etc. Typically what the public sees is a fraction of the total surface area.
- dx034 7y ago
  I don't think that was the claim. The question is rather, why do you need 25+ people for these tasks? They don't add new types of tweets every week/month and much of the interface (luckily) hasn't changed in a while. But I'd guess that these 25+ people spend only a fraction of their time programming and the rest with stakeholder management and corporate politics.
0xEFF 7y ago
Only 25? I’d expect more. No wonder they’re hiring.
jogjayr 7y ago
I'm shocked it's only 25. I would have expected an order of magnitude more given the number of features and sheer reach of Twitter. That can't possibly be right. Not sarcasm btw. I think you're underestimating how much work there is. First, there are a ton of features: lazy-loading tweets, retweet, favorite, lists, all the stuff related to analytics, settings. Simply maintaining that stuff with security updates and bugfixes is a significant commitment. Then there's accessibility and localization to consider. Next there's fix and feature experimentation. They probably don't release new features and fixes to everyone at once. Instead they roll them out slowly, or show different versions to different users, compare, analyze and iterate. Browsers update approximately every 6 weeks, so that's something to keep abreast of. At Twitter's scale, a CSS rendering bug that affects 0.1% of sessions will be seen by hundreds of thousands of users. And it's not just "a Twitter client". It's THE Twitter client - the canonical one. It has to have higher standards of performance, quality, and reliability than a random Twitter Android or iPhone app.
- Izkata 7y ago
  > Then there's accessibility and localization to consider. For anyone unaware, Twitter's whole UI changes to support right-to-left languages, not just the text.

taurath 7y ago

The amount of ignorance of the complexity required in a globally reachable frontend web app is astounding in this thread.

csande17 7y ago
I understand why it's hard to make a popular, globally-reachable web service -- you have to run a bunch of servers in different locations, and distribute the database, and solve concurrency problems and stuff. So I get why Twitter might have large back-end and ops teams. But client-side code doesn't have scaling issues like that. If I put some JavaScript code in a static file, it'll work exactly the same when 1 person runs it as when a million people run it. What "complexity" is Twitter's front-end team facing as a result of their global reach? Like, I guess they have to localize their app, but the hard part there is getting the text translated; the technical implementation is usually as easy as putting all your UI strings in a dictionary that you swap out based on the user's language. (Maybe if they're extra fancy, they make a version of their stylesheet that flips the layout horizontally for Arabic users.)
- x0x0 7y ago
  I doubt you've ever done a translation in a large webapp. Wait until German overflows your text boxes. Or you have to deal with date formats and number formats and ... And rtl languages are just a stylesheet away. Hah, but no. And how many devices across how many OSes do you test on? Particularly all the devices that functionally no one in the global north purchases? What is your accessibility test plan and how often do you run it?
  - TeMPOraL 7y ago
    > Wait until German overflows your text boxes. Or you have to deal with date formats and number formats and ... And rtl languages are just a stylesheet away. Web browsers handle all of that correctly by default. A big part of web bloat is just developers including frameworks and libraries than break things by trying to reimplement them in a way more convenient for devs and designers - and then having to include more libraries and custom code to fix the breakage. All of that is self-inflicted.
    - dx034 7y ago
      > Web browsers handle all of that correctly by default. Unfortunately, they don't. Many websites don't look nice in languages that tend to have longer words (e.g. German). Yes, the browser will cut if off so that it doesn't destroy the design. But that makes it unreadable and not nice to use for speakers of that language. To have a beautiful design that works with many translations is an enormous task.
- as1mov 7y ago
  I used to do fullstack development, but have recently moved to pretty much full time backend because the amount of headache present in the frontend dev. > If I put some JavaScript code in a static file, it'll work exactly the same when 1 person runs it as when a million people run it. No it wouldn't, because the million people have million different devices with different screen sizes, browser implementation and HTML/CSS/JS support for standards. The website should render properly on devices ranging from 5" mobile screens to 32" 4k monitors, while looking beautiful. This is in addition to proper support for multiple languages, accessibility features, and whatever new-fangled PWA bullshit that the business team wants. Implying that frontend is `just` making API calls and putting JSON responses on the screen reeks of naivety. This could've been true in 2005, but in 2019 unfortunately websites have taken place of full blown desktop apps, and are required to behave as one. There's a reason why frontend dev is a specialist job position now and pays on par with backend dev.
- Izkata 7y ago
  > (Maybe if they're extra fancy, they make a version of their stylesheet that flips the layout horizontally for Arabic users.) Twitter does do that.
- ericb 7y ago
  Often on Hacker News, and other places too, I see an argument where one person is hand-waving away a task and saying how easy and trivial it is. The simple heuristic for deciding which person is correct is that the one saying it is simple and easy is always wrong.

threeseed 7y ago

So you think you know how to run Twitter Engineering better than Twitter ? That's a pretty confident claim. Anyway Twitter.com could include writing all of the Javascript for advertising management e.g. creating new ads, content management e.g. deleting/reviewing Tweets as well as the various types of Tweet content e.g. videos, VR etc. Typically what the public sees is a fraction of the total surface area.

dx034 7y ago
I don't think that was the claim. The question is rather, why do you need 25+ people for these tasks? They don't add new types of tweets every week/month and much of the interface (luckily) hasn't changed in a while. But I'd guess that these 25+ people spend only a fraction of their time programming and the rest with stakeholder management and corporate politics.

0xEFF 7y ago

Only 25? I’d expect more. No wonder they’re hiring.

jogjayr 7y ago

I'm shocked it's only 25. I would have expected an order of magnitude more given the number of features and sheer reach of Twitter. That can't possibly be right. Not sarcasm btw. I think you're underestimating how much work there is. First, there are a ton of features: lazy-loading tweets, retweet, favorite, lists, all the stuff related to analytics, settings. Simply maintaining that stuff with security updates and bugfixes is a significant commitment. Then there's accessibility and localization to consider. Next there's fix and feature experimentation. They probably don't release new features and fixes to everyone at once. Instead they roll them out slowly, or show different versions to different users, compare, analyze and iterate. Browsers update approximately every 6 weeks, so that's something to keep abreast of. At Twitter's scale, a CSS rendering bug that affects 0.1% of sessions will be seen by hundreds of thousands of users. And it's not just "a Twitter client". It's THE Twitter client - the canonical one. It has to have higher standards of performance, quality, and reliability than a random Twitter Android or iPhone app.

Izkata 7y ago
> Then there's accessibility and localization to consider. For anyone unaware, Twitter's whole UI changes to support right-to-left languages, not just the text.