If this is true, then why does it take so many engineers to make web sites today?
People keep claiming these things increase productivity, yet there seems to be very little evidence of productivity increase.
People keep claiming these things increase productivity, yet there seems to be very little evidence of productivity increase.
EDIT: OMG it is you! xD
OTOH, so many more business websites are built for a few hundred or thousand dollars by someone on upwork to host a bootstrap site with a shopify integration, and then you have an online store that would've been 10x the cost 5 years ago.
1) As the cost of feature creation goes down, the demand for features goes up- as others have mentioned, a lot of sites now have an enormous number of interactive features or cool rendering that just wasn't there in the good old days of nothing but text, images, and marquee tags.
2) Different frameworks solve different problems, not all of which are related to "productivity." JQuery solved a browser compatibility issues and made interactivity way more approachable, AngularJS did a great job dealing with input and output mechanics, and React is pretty awesome at managing compomentization for large projects. And a lot of frameworks give a "feel" users are looking for. Frameworks improve productivity, but the difference between frameworks is not that great.
3) one thing frameworks do well is allow team scaling, and scaling teams leads to a lowering of "individual" productivity. What works on a team of 1 doesn't on a team of 5. The larger team will need more "overhead." A team of 5 won't be able to do a task an individual could do 5x faster, it'll be more like 2.5x or something. That's not why you scale a team though- you scale a team to take on new problems that can't be solved (or solved fast enough) at the scale you are at currently.
I've run a decent size team using angular JS, I shudder to think of our ability to execute using JQuery, even though I successfully accomplished scaled down projects in those frameworks before.
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/twitt...
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.)
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?
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.
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.
> 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.
Twitter does do that.
The simple heuristic for deciding which person is correct is that the one saying it is simple and easy is always wrong.
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.
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.
For anyone unaware, Twitter's whole UI changes to support right-to-left languages, not just the text.
I guess it's like anything else, what are you trying to optimize for. There's still a lot of charm in PHP being a very simple wrapper to a lot of very efficient C functions.
Nobody denies that these frameworks allow people who would never be able to program in C/C++ to create websites. Nobody denies that it takes more of these quasi-programmers to create and maintain websites than it would take more knowledgeable programmers writing in more efficient languages. So, here's the killer question: At which point do these frameworks and the large number of quasi-programmers required to maintain them cost more than just hiring somebody who can create a native app in C/C++?
So, millions of dollars, years of time for no actual benefit, and now the business is left with an app they can’t hire talent to maintain because it’s so custom.
And if industry experience says somethings, those engineers who spent that time honing their skills at wrangling the C++ stdlib will have _appalingly_ bad design and UI skills, which are very relevant for today's web and are a much more important driver of revenue.
As writing software has gained a reputation for being a lucrative and desirable profession, it has attracted more and more people. If you were someone who took up programming in the 80s it was probably because you had a good aptitude for it and found it interesting. Now, there are more people joining the profession who don't have the same level of aptitude.
So now instead of a small team of highly skilled people, you often end up with large teams of less skilled people. Interestingly there doesn't seem to be much of a halfway house - your project is either staffed by 6 people or 30+.
As someone that has been in the industry close to 20 years, my guess is that the constant churn is getting in the way. Around 2000 when I started, we had 3 tier apps, people knew how to optimise relational databases to get their application to perform.
These days we need to add Kubernetes, Docker, Nosql to cloud platforms in order for it to scale - despite never needing this stuff 15 years ago. Instead of mastering our craft we are encouraged to forget everything and use this new technology instead, as it will be the silver bullet to all our problems.
It's closer to a fashion show than engineering.
It's similar with choosing e.g. Hadoop instead of running entirely locally. You're mitigating the risk that in future your workload might exponentially increase. Yeah, it probably won't but if it does, whoever decided to on that architecture will look like a forward-planning genius. But nothing comes free.
I am discounting the artwork and asking primarily around the efficiency of the coding and development.
Each developer has a focus area. You might focus on millisecond level optimization; a web-developer might focus on content provisioning and rapid development; a data engineer might care more about sanity and robustness of data.
It's not clear how anyone can judge other engineers' ability based on arbitrary metrics without considering their engineering system's goals and requirements.
As an example, both Braid and The Witness have very limited accessibility; perhaps that wasn't a focus area of yours and again each developer to his/her own.