I don't think engineers use frameworks because they think it makes them look cool. They may choose between multiple, competing frameworks based on community perception, but not between using a framework and not using one.
It's usually an argument from business needs that leads to application bloat. For example, what PM on a startup would sign off on spending two weeks to implement a custom date library and date picker component when there are excellent, if sizable options available to install right now? What small- or medium-sized company is going to create an in-house application framework when React is very good, and there are thousands of people you can hire who already know how to use it? A major reason applications get bloated is because development time costs the company more than client bandwidth and CPU do.
So, in that sense, it's not a matter of convenience either: It's a selection made based on weighing the constraints and options and selecting the best one. If poor application performance started costing companies a lot of revenue, I'm sure the result of the calculation would change.
> I don't think engineers use frameworks because they think it makes them look cool.
I've been in this line of work for a long time, and I'll admit its a huge factor. Webdev is a very fad-driven business, and I've seen numerous technologies come-and-go where they were hot, but not they are now super not. And to some degree this is logical, because you want people who can adapt to whatever is latest-and-greatest and not just a particular platform. But when recruiting it certainly helps.
Plus the old chestnut that 50%-80% of software projects are failures, and looking out for number one means resume-oriented development for the next job. You are probably better off with a failed project on a 'cool' framework than a successful project on an uncool one.
I've talked to several really enthusiastic developer advocates about technology in the corridor and when it comes to describing the actual product or use of the technology they tend to mumble, or wave hands, or state some product that HN would argue about (e.g. advertising). All the developer advocates I've met who promote latest tech really don't seem to like their companys product.
I would say that developers try to make it a fad to keep themselves interested and engaged in an otherwise boring, soul destroying or socially harmful job.
Don't forget that a dev may need another job in the future. And it doesn't help finding one when spending the last 2 years building an app with some "oldschool" tech stack that performs well. Most companies are looking for dev's who worked with the cool fancy stuff like react because that's already the tech stack they are using.
And what is so bad trying to make my job interesting? If it's boring I wouldn't care much about the end result. Just another 9 to 5 job then.
Nothing bad about making something interesting. You would be interested in the end result - but for developers who do this the end result is the technology they produce and not the product that the tech is being used for.
I think it would be one of the reasons why "putting devs before users" happens.
Also - look at the HN Who's Hiring threads. Almost all postings don't talk about the product or their users. They talk about the technology.
That's true, in most of the company's I worked (includes the current one) I'm not interested in the product at all. I work there because I can decide which tech stack we use, try and learn the fancy stuff and have some fun building it. Why? Because I can - I am one of the few "good" dev's out there. So many companies are hiring and they take what they can get. And I as a dev can choose where I want to work. And of course I choose the interesting one. In conclusion there are much more companies hiring then good dev's looking for a job. So the company has to make itself interesting for dev's.
But I don't think that's bad at all. With modern devices and Browsers you can't tell the difference between using a framework or not.
> That's true, in most of the company's I worked (includes the current one) I'm not interested in the product at all.
This way of thinking would honestly have never occurred to me. If I'm really not interested in the product a company produces, then I don't think that I'm qualified to work there.
> With modern devices and Browsers you can't tell the difference between using a framework or not.
That was a funny bit of honesty. You should have stuck with it till then end and tell it like it is: It doesn't work on slightly older devices. Or something like: You really notice things don't work when using a slightly older device.
Jokes aside, I cant seem to find data on the age distribution of interneted computers.
You are the kind of person who believes that every app should support ie8 and even before that, right? Don't forget to limit your 500ps car to drive only 25mph...
It isn't your fault they hire people who don't care about the product. That you pick a tech stack that inspires you is a logical [and predictable] follow up.
I think a lot of people still think things are/should be something like: First the product, 2nd the customer, 3rd the company, 4th the investors and the employees last.
But the reality is often more like: First the investors, 2nd the employees, 3rd the company, 4th the customer, and oh we need some kind of product too!
You get the open floor plan so that the investor can see lots of people working. A nice ping pong table to illustrate the lack of employee equity. A fun tech stack to attract and keep the employees happy. Large expensive chunks of plastic with the company name on it. Great customer service to help the customer with their problems and lastly a product that doesn't work.
Again, I'm not suggesting any of this is your fault. On the contrary, one cant teach passion. You either care about the product or you don't.
I think it is like this because it is kind of awful on so many dimensions, and we have hacked the browser to do all sorts of things. It's kind of amazing, but now we have to deal with it.
> I don't think engineers use frameworks because they think it makes them look cool.
Or, management tells engineers what tools to use because they think it makes them look cool.
Our company recently got word from above that "all these old technologies go out the window, you're now all becoming JS devs and we'll use microservices for everything".
The result is that for one project I could probably build entirely by myself with a LAMP stack in one week, we now have 15+ people in 3 teams & 3 different countries each working on tiny parts of a very small simple app barely used by anyone, using a whole shopping list of tech that you simply don't need.
When I asked one of those management "evangelist" guys during an informal dinner "so why all of a sudden JS frameworks?" his answer was something honestly along the lines of "I don't know it seems the thing to do nowadays".
Needless to say I'm job hunting like my life depends on it.
Buisness schools need a new lecture: Management as a Liability: Tech debt, tech insolvency and what one can do to prevent it.
I worked in automation for quite a while now- and seriously, i would be glad by now if management would push for new technology. The tech here is stagnant since the 80s.
They start debates when you talk about object orientation.
I recently graduated and majored in CIS as well as CS, and the CIS classes were in the business school. This is something we talked about a good deal in one of my CIS classes. Unfortunately, it was a specific major class, not something all business majors took. I am unsure if normal management majors were taught similar ideas but I thought the class I took was rather well done.
Yeah, have experienced this also, and I think there are competing interests between "best engineering option to get the product out fastest/most efficiently" and things like "hiring" and "getting investment funding"
Using the latest and greatest buzzwords helps greatly with hiring and getting investment (it's a positive feedback loop that just feeds itself and increasingly adds pressure to make those decisions).
> A major reason applications get bloated is because development time costs the company more than client bandwidth and CPU do.
If development time was really the biggest issue then I think we'd be seeing far fewer SPAs and complicated frameworks along with many more drag and drop VB apps or simple cgi sites, especially on internal tooling for small-medium companies. These also generally perform much better.
But between developers wanting to work on more exciting things and PHBs wanting sexier looking apps we end up with the current nightmare.
> It's a selection made based on weighing the constraints and options and selecting the best one. If poor application performance started costing companies a lot of revenue, I'm sure the result of the calculation would change.
This is not often the case, where even senior level engineers at FAANGs end up selecting tools based on their personal tastes with complete disregard for long term maintenance and operational costs.
I’ve seen projects with 6 different LISPY languages to solve the most trivial problem, including a couple developed in house.
I’ve seen all kinds of complexity from people choosing a random design pattern and using it to solve literally every problem. Recently I came across a code base where every call to every other class uses the visitor pattern... just because.
I’ve seen teams building internal platforms that picked one of most unknown languages for their customer teams to write business logic in... only because the senior engineer is an expert. These folks want other teams who have no background in this language — literally their main customer — to write production quality code, understand its nuances and write idiomatic code.
You’re placing too much faith in PMs or any of these management functions having a worthwhile role technical decisions, especially ones they don’t understand and don’t have time to disambiguate.
I’ve been at three different FAANGs where teams are literally drowning in idiotic decisions of some clown devs before them who invented technical complexity solely for the sake of getting promoted and then moved onto other teams. It’s not just devs... I’ve seen engineering managers sit comfortable and let people make dumbass decisions. They celebrate the new launch with beers or champagne but then leave within a couple months after because they know operational costs and escalations meant they’d get an unlubed pounding with a 2x4.
And it’s not just at FAANGs - I commented on a Ask HN thread a few days ago where the poster asked what’s the best stack for web development. Without a single blink, every other post was some random framework the commenter likes working with - never mind any nuanced discussion of functional or non functional requirements or even beginning to think about support or organizational alignment.
I can attest to this problem. I like to call it, the "architect" who never sticks around. First, this guy gets rewarded for getting a project rolling and showing results as quick as possible. Second, he will get no reward (nor satisfaction) for sticking around. The company also seeks to reproduce point one, long term results are drowned. Rinse and repeat.
Refreshing to see even FAANGs have to deal with this. I guess it's like politicians in the government. Same problems everywhere. I dealt with this in nearly all the companies I worked for.
Perhaps it provides a boost in the initial development. But the applications that I've seen and used that use frameworks almost always provide an inferior user experience when compared to those that don't.
I say unfortunately because the product quality is reduced as a result. So yes, we have may have more stuff, but most of it is seriously substandard.
This may be a positive thing for some people. It's a negative thing for me, though, because it increases the difficulty of finding good solutions, and reduces the number of good solutions that exist.
Frameworks allow websites to be built faster, maintained with less expertise, and changed faster over time. That is the benefit to the user. That things are slower than they could be doesn't matter to most users. Most companies can't afford to pay people to maintain a "good + fast + quick to make changes" site.
There's an argument to be made that if business would just simplify their needs and desires to make sure everything is simple and fast, isn't that in and of itself putting devs before users? This works both ways.
Also, if you don't want to pare down your features to barebones, and you're not going to use a framework, someone's inventing one. If you have someone who's going to build you a superfast framework and be a cool hacker, then you probably can't afford them, or you can't afford to keep them. Then we get a post on HN about how bad this one coyboy coders's framework was and all the effort that was spent to modernize using %modern_framework%.
Jonathan Blow has a good presentation containing some interesting facts about the companies that employ thousands of engineers and can't get simple things to work. It's the first part of https://www.youtube.com/watch?v=k56wra39lwA
The ones that have a lot of engineers have 50x more features today. Businesses and brands want a beautiful website with analytics and A/B testing out of the box, skinnable, changable via a CMS so that non technical designers can drag and drop in new components at will, and also get graphs of their efficacy. You have built in support chat systems to spend less on phone support. Your IT department to support, not develop, this site was 30+ with colo space in 2008 but now its like 3 dedicated ops people and the rest are devs.
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.
+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.)
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.
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.)
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.
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?
> 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.
> 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.
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.
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.
There's a lot of shops that are pure django, drupal, laravel, wordpress experts, who would never be able to put something together from scratch, but can probably glue you a customized website in not a lot of time from relatively well tested components. I remember going to a meetup for level 10 in Dallas, TX. Huge beautiful building they had, all from django and wordpress revenue.
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.
> There's a lot of shops that are pure django, drupal, laravel, wordpress experts, who would never be able to put something together from scratch, but can probably glue you a customized website in not a lot of time from relatively well tested components.
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++?
Hire a C/C++ programmer and see how that goes for you. If what you’re saying is true they can revolutionize the industry and make a billion dollars with their superior code.
I’ve seen it happen. The code is faster, but it doesn’t matter because users don’t care. It also took two years to rewrite, doesn’t have the features of the original, and all of the operational experience had to be relearned by the engineering and ops teams.
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.
The C/C++ engineers are going to spend their time dealing with memory management issues that have no relevance to the final delivery of product features.
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.
My intuition (that I have no data to support) is because the average level of skill of software engineers is dropping.
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+.
> My intuition (that I have no data to support) is because the average level of skill of software engineers is dropping.
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.
Frameworks also effectively hide “bare metal” from developer, so they develop magical thinking. I’m really tired at my job of debunking magical and simply wrong assumptions and claims about how something works. Being unable to understand and implement something yourself, shadowed by Framework Authority, dooms one to remain in a pit of false incompetence.
Part of the productivity "gain" is increasing agility, making it easier/faster to scale/pivot if you need to. Whether you actually do or not is up to you, and you pay a time penalty as an overhead for those abilities when using a framework.
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.
Why would it take a single engineer 3+ years to build a Mario-like game with a tweak around time-mechanics?
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.
>Frameworks allow websites to be built faster, maintained with less expertise, and changed faster over time.
As someone that has done maintenance programming on an AngularJS application and a React application in the last couple of years I would say that is not true. Getting some simple changes made is a complete nightmare, there are loads of third party libraries that seem to be inconsistent in the way that they render and are next to useless if you don't use them in a particular way.
Frameworks allow websites to be built faster, maintained with less expertise, and changed faster over time. That is the benefit to the user.
How did the user benefit from breaking changes between framework versions requiring no new features to be delivered while everything is rewritten for no particular reason?
In the Python community 2 to 3 freaked everyone out but webdevs do it every 6 months!
I find this development incredibly sad. Originally, SPAs looked promising from a technical perspective because they could potentially eliminate lots of redundant server-side HTML rendering and duplicate transmission of data (because templates, code and data items could be cached on the client and assembled as needed).
Today, we somehow seem to have gotten the worst of both worlds: We got the additional overhead of client-side rendering but we can still not reliably cache data, so not a lot of processing or bandwidth can be saved.
I think Turbolinks is a good answer. Only serve what’s changed, which on a normal website isn’t a lot. And it works without having to switch your whole stack to Javascript which is a plus.
Anecdotally I can say this is because people either fail to implement or actively fight browser based caching techniques. I can forgive people for not taking the time to implement ETags, but it's surprisingly common practice to include headers on REST calls to disable caching.
For me the main appeal to SPAs are testing oriented. Assuming I need some kind of interactive functionality that can't be done using a form, testing across the browser interface is difficult when doing HTML view production on the server side. If you are doing HTML view production on the client side, suddenly it's much easier. I test that the server produces the correct data given a request and I test that the client renders the correct views given the data. In Michael Feather's parlance, I've got a viable "seam" for testing against.
But if something can be done with links and forms, SPA makes it harder to test. So I prefer using JS only for islands of interactivity within specific pages, not making the whole application one big island.
Out of couriosity, how is testing on the client easier?
I'd think you still have to verify the same way that the results are correctly rendered - except now you have to verify that the DOM is correctly generated as well.
I originally started my career as a Rails developer, and for the last few years have been doing more frontend JavaScript (React), as that's where the €€€ is. For all of the projects I've worked on, server-side rendered Rails would have been a much better stack choice. It would have been quicker to develop for, easier to hire for, and more performant to the end user.
Now I'm not trying to say this works for everyone, maybe when you get to unicorn scale it makes sense to do something different, but these are small projects with no more than a handful of developers. Hiring React developers is easy, hiring Rails developers is easy, but hiring developers who know both well is much harder.
Most of the projects have been for pre-revenue startups, so what's important at that stage is speed of development. You really can't beat Rails for development speed of CRUD applications (which let's be honest, most apps are), and then you can add a sprinkling of JavaScript on top for some modern features (and with something like react-rails you can easily integrate React). If at a later stage you need an API for mobile applications, Rails makes that easy (you can even share the same code for API endpoints and regular HTML views).
In terms of performance, at this stage of a company you can get pretty far by horizontal scaling. Rails is a fairly mature framework, so it's easy to maintain and isn't going to introduce any breaking changes anytime soon - compare this to one of the projects I worked on, which is stuck on React 15 with vanilla JS and probably will never be upgraded.
Now just to repeat I'm not saying this works for everyone. Another project I recently worked on was a React + Typescript app. There was already an existing GraphQL endpoint and it needed a lot of interactivity, so Rails wouldn't have been a good choice here. But for a lot of projects I'd say that server-side rendered Rails is a better choice. it may not be sexy anymore, but if you are a startup and want to get something done fast and for it to be maintainable, it's probably the right choice.
I wish more people would think like this. Javascript only gains you in latency if you handle things locally - which nobody does. That means that server-side rendering beats pretty much all SPA's, and somehow nobody cares. And if a client action results in 5 requests, as it often does, then server-side rendering is a lot faster.
Or to put it directly: craigslist is faster than amazon.com. And, frankly, more fun to use.
Html is a language. CSS is a language. JavaScript is a language. You can build the Dom by loading html, and you can build the Dom by making calls from JS. You can write style rules against a selector using CSS, or you can write some declarative JS that looks almost the same but with more commas and fewer semicolons. Going back to the good-old-days isn't going to save you since the language is incidental.
Anyone who puts up their first Gatsby site is going to be amazed by how fast the performance feels. They certainly won't be wishing they'd burned their JS stickers.
My biggest problem with the article is that it ignores the cost of "putting users before devs". Writing the simplest, most performant iteration of a site that matches the minimum requirements as you perceive them for today's users isn't that expensive. But that approach crumbled quickly as parameters change slightly. You're one bad focus group or new CEO away from needing to completely rebuild from scratch, except you'll probably need to keep maintaining the old site forever. Then the new site when it becomes the new old site. Then the next one. Repeat until your increasingly-expensive business is completely unviable.
CSS is a dystopian nightmare from a Lovecraftian dimension of metaphysical horror.
I had to do a teeny-tiny bit of CSS work before Christmas and I literally had to look up the edge cases and exceptions for all of the five common CSS statements I ended up using, because they were all context-dependent in insane ways - endless "This only works if XXXX is also applied here, but does nothing/fails silently if it isn't, even though you might expect it to work, and this mode is only documented on StackExchange etc because the official CSS docs are incomprehensible and no one ever reads them anyway. And by the way, you'll also need a file of resets for many of the most common options."
I'm much happier using some css-in-ts solution, because then I can use stricter types against what I define. No need to track down why my `background-colour` isn't doing anything somewhere, or setting up some separate tool to validate it.
While we're looking at cultural problems, this view of style-work as somehow being easier/lighter/less-important/etc. vs the "real" code is at the root of so many of these problems. It's very fashionable to praise functional programming and all the virtues of being declarative, yet we can't connect that with good practices for style.
> Writing the simplest, most performant iteration of a site that matches the minimum requirements as you perceive them for today's users isn't that expensive. But that approach crumbled quickly as parameters change slightly.
Maintaining two apps (front end and back) instead of one--that seems like an approach whose affordability crumbles more quickly when change is needed to me.
The author makes a very weak argument, not even listing any examples. There is no modern framework that is 2-3MB, that is absurd. The whole point of SPAs is to increase performance. Sure there are sites with horrible implementations of SPAs where loading the page triggers a second refresh (cough spectrum.chat cough) or that are just outrageously slow (eg. gmail), but those are certainly not the majority, and are caused by poor engineering, not the framework. Poor performance is more often caused by ads (ever surf the internet without adblock?), tracking, unoptimized images, poor client-side rendering, etc.
Although web performance is certainly a problem, the bigger problem with the web in my opinion is actually poor UX. Often when I'm on a website it's very confusing how to figure out how to do basic tasks like finding the search bar. Medium has the most appalling comment system I've ever seen, requiring 3+ clicks/refreshes to read a comment on an article.
Although I agree the web performance is a serious problem, this is a very weak article, and I'm surprised it's on the front page. I guess people will upvote anything that complains about web performance, no matter how poorly reasoned and misplaced the blame is.
I believe it, but it's not because of what framework they are using. React is only 100k. It's because of writing bloated websites without a concern for performance.
It's not the UI framework that's adding the bloat, it's a bunch of tracking and fingerprinting scripts. They would still be there even if the UI was server-rendered HTML, because that's Medium's business model!
People are not using frameworks because they are fun. That is because using frameworks is in no reasonable way fun.
I would argue that developers who aren't having fun are going to create bad products. They certainly are not going to push themselves or be particularly creative. I further don't believe for a second that the utility of libraries like moment.js (and the many improved children it inspired) has anything to do with maximizing "fun". Depending on your objective and perspective, they make the job tolerable and/or possible with far fewer bugs than would exist if you tried to build something from scratch.
I do have good news for everyone, however: you can use tools like Stimlus Reflex (Rails) or LiveView (Phoenix) to build reactive UIs that require none of the heavy client libraries slowing down your pages. Using these tools is simpler, faster and indeed more fun because you're managing state changes on the server and only delivering the bytes that have changed.
Here's a reactive tabular data navigator that supports sorting, filtering and paging without any app-specific JS code required, period. Total JS payload is 54k over the wire, and to be clear... that's for every example on the site.
I don't like to punt, but this seems like perhaps it's on your end. Thankfully, we haven't had other complaints of this nature and it sounds like perhaps you have a security layer (firewall, browser plugin perhaps) that is not giving you a neutral testbed.
One surefire way to tell is to try the site in Incognito Mode. You could also try on your phone, although admittedly most of the demos are still slanted towards desktop interaction. That's 100% on us and not the tech itself.
So much of the backlash is due to the simple (but very significant) confusion between web pages and web apps.
No one should build a web page as an SPA with JS. Most web pages are ideally suited for static site generators. Just abiding by this simple rule would make life vastly better for users.
By the same token, it would be relative folly to try to build a chat client using server-side rendering. It can be done, but a chat client, like a spreadsheet or email client, are all proper applications, and so are ideally suited to being built as SPAs.
There are some projects that lie in between, and in my experience, these usually work out best if coded using a server-side framework with a tiny amount of client JS for UI tweaks. Reddit is a good example of this. Reddit has become significantly worse once re-coded as an SPA.
As for the whole idea of building web apps without using frameworks: I lived in the era and did just that. Usually, the result was a total nightmare, with a rat’s nest of jQuery and various other crap. If you were lucky, you worked for a company that knew the value of abstracting out common features and using a pattern such as MVC or MVP. In that case, you end up with what’s more or less a framework by the end, and indeed, most large companies and consultancies had their own in-house client-side frameworks. If you’re doing that, it makes sense to open source the framework to share the burden with other companies.
The real complaint seems to be the misuse of client-side frameworks. But this is a function of junior devs and poorly-trained devs misusing a framework, not the framework’s fault. Such developers would make even slower apps without a framework, believe me. Only it would be be a rat’s nest of unorganized spaghetti code.
It's not you. This is a cycle that repeats itself every 10 years or so. We're in that spot in the circle where frameworks are too heavy and complicated and everybody's ready to go back to creating spaghetti in raw js. That's exactly what happened 10 years ago when Flash gave way to ES5.
I wish the author had included an example instead of just going after a straw man.
There are lots of devs out there that don't know what they're doing or aren't permitted time to optimize their apps. Frameworks are a tool that can be used and misused.
I fully believe a lot of developers and software enginers put their job satisfaction above their users or customers.
I agree wholeheartedly the web on average is getting more bloated.
But as a counter point: My own job satisfaction derives from delivering an amazing and snappy experience to end users. And I'm sure there are others like me out there!
Don't make bloated websites. Use plain html if necessary. Hacker News seems to have a great design - do they use a complicated framework?
Sure, it's harder. But it's also better. If you're not interested in performance then just keep doing whatever everybody else is already doing. Every decision is about compromises. Figure out what to prioritize (developer time, loading time, server cost, whatever) and build the best thing you can based on your goals. If you want to build something materially better than is normal, expect it to be substantially more work and money.
Don't worry about the fud these people are spreading and use the tool you know to get the job done. If that is ruby on rails using templates with plain html and css do that, if it's react do that. None of this worrying about "bloat" matters, just get it done.
The two most successful chat apps in the world today are slack and discord and they use react and electron on the desktop.
An app can be successful on many metrics, profitability is not the only one. Slack is successful in that it has 10 million daus, 85000 paid users, and it managed to have the company valued at 12.4 billion dollars.
Ignoring the valuation of the company I would consider any program with 10 million daus to be successful.
And funny enough 10 million people choose to use slack and 14 million choose to use discord over irc every day despite the supposed "bloat" of the software.
If you are a developer building an mvp and the thing you are worrying about is "bloat" I will put money on you not being successful.
Regardless of your quibbling, if the creators of slack and discord decided to not use modern web frameworks to build their software they wouldn't exist.
I don't agree with this, really in any sense at all. Firstly, you could argue that using battle-tested projects with thousands of hours behind them can yield you better performance, as well as reducing training time because more new employees will already have the necessary skills. It also tends to be better for accessibility than roll-your-own.
Secondly, the article completely forgets to mention what really causes slow down: loading sources from multiple third party domains, especially bulky ads, tracking, and popover scripts.
The reality is we (web and other developers) tend to waste end-users time way before raw performance is perceieved as an issue. Take for instance medium.com where you are expected accept complicated terms and conditions, and then give away your facebook account or google account, after which you are prompted with some kind of survey and then there a good chance you will be asked for money ;) all of this is the norm for the web.
Comes down to incentives. Why would the agency or SME dev care about the end user? Will they get rewarded if they do? Nope.
Dev salarymen are concerned, rightly, with their careers. This is why they do stuff like make a brochureware website that should be dead-simple into some demented chimera of 5 different "best practice" frameworks, submerged in 10 feet of technical debt to boot.
They do so because they can put that stuff on their resume, which will (for management and recruiting incompetency reasons) get them into a better job next year or month.
To hell with the devs who follow them, and to hell with the client, customer, or end users in general - they ain't me.
But the solution is to modify incentives, not to indulge in the sperg-outs our profession is infamous for, since those are only "I'm cleverer than you all" rants, which are again, "me first".
I understand the pressure on js frameworks and the like. Even Microsoft attacked the same problem with Blazor. But the original goal of these frameworks is and still is portable code. I might be the rare engineer whose work flow is accelerated by these frameworks, but I also carry an approach to creating well patterned interchangeable components. And by and far I believe that is the real issue in the industry.
However if we are talking about speed. I do agree. But that is because to me it is madness to have these frameworks sitting on the main thread. And should be concurrently offloaded to a worker. Reactor's concurrent mode is also a great stab at this problem. Howver I believe the point is missed.
Being the only bindings a framework should have on the main thread is it's interactions with the dom. Everything else, including the virtual dom should be on a different thread.
So while I understand the push back, I believe people are missing the point. These frameworks have been implemented in the easiest fashion and have matured. But now that we can rely on multiple cores and ht. There should be a response.
Not to mention Web Apps vs Web Sites. We need to make that distinction, especially in line with wasm now being matured.
Edit: As for serverside rendering. If your backend engineer can't figure out how to cache this. I question the hire.
The reason frameworks usually don't run in a worker thread is because it is difficult to efficiently cross the barrier between workers and the main thread. Either you need a shared array buffer or the contents of your messages have to be copied on write. Even web assembly has similar issues as it runs in the same thread as any JavaScript you have.
I do agree about making the distinction between sites and apps though. A lot of the contortion frameworks do is to avoid triggering layout excessively. You can't even get the position of a DOM element without layout rerunning to figure out where it should be. I suspect a lot of these quirks are legacy web behaviors more applicable to sites than applications.
I've done some experiments in regards to a message service. And though a lot of this work isn't ready for production I have seen a lot of success. Long story short SSR to rebind via webworker. Unfortunately it's just one of many experiments that are way back in my todo list now.
Just better point out where dev's haven't been trained and are just doing their best. It's a large topic and not every company can keep a high standard.
But most complaints I hear on the topic is the same criticism of js in general. So much rope you can hang yourself with.
What most JS frameworks like React and Vue got and get wrong is their runtimes, meaning that a good designer/developer experience scales with the amount of code that is shipped, an anti pattern because that it can be done better as demonstrated by Svelte, which by being a "web compiler" basically decouples the DX and production code. It's the real deal for webdev, going back to React or Vue feels awkward after using Svelte.
From the article's detractors I learned that while things are bad, they get the job done and we get paid, no problem. Yet faster loading does increase conversion and profit. Not to mention users will love a product that feels good. A good work organization is more beneficial than finding your way around someone else's organization (the mega frameworks). Can any manager who also loves quality chime in? Thanks.
The counterpoint is, who are we to say that "performance" matters. Certainly for things like search, yes. But much of the time, features matter more. Frameworks happened because they allowed engineers to iterate more quickly, which allowed PMs to find the set of features that work for users. We are, after all, still using JIRA.
Building online blog for the millionth time is boring and using a new framework makes it less boring - that’s the main reason there is a new cool JS framework every six months
A blog post talking about performance but showing no numbers to prove the point? Questionable.
HTML, CSS and DOM manipulation all by itself is already a performance trainwreck. CSS layouting is ridiculously expensive.
The actual framework overhead is usually negligible, especially when considering that writing "optimal" vanilla code is not something that people actually do, or when they do it is a security risk (setting innerHTML without sanitation).
The point about 2-3MB bundle sizes isn't valid either, no framework that is any good has more than a few dozen of kilobytes extra payload.
While I completely agree with most of this article. I think some of it is untrue. A lot of the new functionality is needed for a increasing amount of apps.
For example, I work on an app which wouldn't be possible on the web 5-10 years ago. It's a single page app because it needs to be. It uses a lot of javascript making many requests because we have to and the customers requires it. We could probably make it a lot faster, the issue is that the amount of functionality that we are trying to include in a short amount of time leaves us no other choice than to include yet another library etc.
I know this case maybe isn't the kind of app the article is targeting. But I think even "simple" apps today often include some part of complexity that would be hard(er) to do in a "old style" multi page app.
That being said, I use a lot of old style apps. I use the old reddit instead of the horrible new one. I use HN, I use fastmail so I do think speed is very important.
> A lot of the new functionality is needed for a increasing amount of apps.
Could you make a few examples?
> It uses a lot of javascript making many requests because we have to and the customers requires it.
Why couldn't the requests be done by the back-end?
> But I think even "simple" apps today often include some part of complexity that would be hard(er) to do in a "old style" multi page app.
Absolutely, but isn't that exactly the point of the article? Working with a framework can make development massively easier - however, the benefits of this only go to developers, while users have to bear the costs.
Sure, not in any particular order (and there's a lot more)
1. Users can use drag and drop functionality on areas, making updates to the backend as they are moving stuff around. To have the webpage reload would not be an acceptable experience.
2. File management. Users can upload files and create folders, refreshing the page after every update wouldn't be nice.
3. Users can retrieve data on many objects. Open specific objects and see it's data in popups. Edit the data, add comments, upload images etc. Wouldn't work very well with a refresh.
> Why couldn't the requests be done by the back-end?
When the backend can do the requests, it does. I meant doing requests to our backend and to static resources.
> Absolutely, but isn't that exactly the point of the article? Working with a framework can make development massively easier - however, the benefits of this only go to developers, while users have to bear the costs.
Not really. I am saying that many new apps aren't simple crud apps anymore.
It’s not that it wasn’t possible, but it was really fiddly keeping the HTML up to date with all state changes, and having the rendered template match up with what the JavaScript wanted to do.
I ended up having to cut a lot of features to make projects happen on time, and adding a new complex feature to an existing site coded with unobstrusive JavaScript was always felt like a full rewrite.
Doing it with React though is like being back to working with desktop GUIs. Anything you want we can do.
In the older days, anything that had to be a complex webapp would be easier done as a java applet, or a flash app.
Well, 5 years may have been a stretch. Maybe more like 10+.
Doubt it as much as you want but we use several newer apis and phones wouldn't be powerful enough to run the damn thing 10 years ago since it's a web app.
I don't think you're making a good case for yourself. It would be extremely difficult to run Slack on a computer from the 1990s, but we sure as hell still had chat apps.
I don't think the majority of people had chat apps on their phones even in the late 2000s.
I remember a little of the pre smartphone days. Basically no one installed any apps that didn't come with the phone. I tried to download some apps on some symbian device but experience was shitty as hell and many times they didn't even work for some unknown reason.
> For example, I work on an app which wouldn't be possible on the web 5-10 years ago. It's a single page app because it needs to be.
No, it doesn't need to be. If you need to use hacks like SPAs to have the functionality you want, that is telling you that you're using the wrong tool for the job, and shouldn't be making a Web site.
What you and a lot of other Web developers have done is, when faced with a square peg and a round hole, break the peg and the hole. Worse yet, not just for you, but for everybody who has to use those pegs and holes. Now the Web is a terrible place even for the people who used it correctly. Now the desktop is a terrible place because Web people have infected it with Electron.
Web developers, if they can be called that, have set back the state of the art by several decades.
I've never had a business-person come to me and say "you are building a SPA", or "we are using React." Now, they have come to me with some brilliant and also ridiculous ideas, and I've done them all, but none of those dictated a particular engineering solution.
I won't claim that it's commonplace, but I have had business people specifically tell me that they wanted a SPA because they saw it as the trendy thing and wanted their web app to feel "modern".
Professionals in any field have a responsibility to do good and thoughtful work, and to treat their field with respect. Anyone who just builds whatever crap they're told is a bad professional.
Believe me when I say that I have had hundreds of meetings where I tried to tell them that what they want is crap. But in the end it's their decision not mine. And in the end I have to make money so I build what they want. This has nothing to with me being unprofessional.
This is all over the place and doesn't really present a coherent argument.
The author complains about developers who "want to show off" and then derides the use of frameworks. But showing off would mean not using off-the-shelf solutions, and instead trying to hand-craft everything.
The author complains about how frameworks bloat the page, but react + react-dom, as of version 16 (the most recent measurement I could quickly Google), weighed in at 109 kb (34.8 kb gzipped). Sure, client-side rendering means you wait for the JS to bootstrap before you get to see content, but React also has good support for doing initial renders server-side.
It feels like the author just spilled out his or her assumptions and prejudices without examining or researching them at all.
The author is right. It just sucks to read what's true. He's not entirely right but he's on the right track.
You'll find a lot of tiny companies with dev. blogs where they explain in-depth the scaling strategy of their unknown, sporadically-used product.
Yes, react and vue are a few hundred kb gzipped. But are we seriously going to pretend that projects built with react are in a few hundred kb range? You can't even predict how big a project will be. It's not react's or vue's fault, it's simply how it is - add assets, add css, add additional libraries for <insert reason here> and it's not unrealistic to get 2-3 MB that you need to download.
A lot of people are designing their products to show off to their peers or for google (SEO). Users get left out. And we (users) are starting to feel it. Heed the warning or turn the blind eye.
In the good old days, there were plenty of terrible user experiences built with traditional technology. All of those apps failed to make a mark in people’s memories and have been forgotten.
I do remember stuff built in Frontpage breaking terribly if you resized your browser. I remember Joomla outputting reams of html that the browser would choke on the nodes. I remember doing chat apps via iframes and long polling. It was all there.
Better technology has only lead to better outcomes on both the low and the high end, and it’s a lot easier to debug and fix the low quality outcomes.
It's usually an argument from business needs that leads to application bloat. For example, what PM on a startup would sign off on spending two weeks to implement a custom date library and date picker component when there are excellent, if sizable options available to install right now? What small- or medium-sized company is going to create an in-house application framework when React is very good, and there are thousands of people you can hire who already know how to use it? A major reason applications get bloated is because development time costs the company more than client bandwidth and CPU do.
So, in that sense, it's not a matter of convenience either: It's a selection made based on weighing the constraints and options and selecting the best one. If poor application performance started costing companies a lot of revenue, I'm sure the result of the calculation would change.