Putting Devs Before Users: How Frameworks Destroyed Web Performance
medium.com
medium.com
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.
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.
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 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 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.
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.
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.
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.
Jokes aside, I cant seem to find data on the age distribution of interneted computers.
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.
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.
I sure can!
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.
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.
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.
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).
They don't. They use frameworks because it reduces the cost of production. Unfortunately, they accomplish this at the cost of the user experience.
Everything is a trade-off.
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.
This doesn't follow. At business startup frameworks provide a huge boost in user experience through code re-use.
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%.
People keep claiming these things increase productivity, yet there seems to be very little evidence of productivity increase.
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.
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.
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.
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.
EDIT: OMG it is you! xD
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.
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.
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.
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!
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.
I'm sure everyone wishes these things were faster.
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'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.
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.
Or to put it directly: craigslist is faster than amazon.com. And, frankly, more fun to use.
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.
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.
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.
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.
Javascript is 1/5 i.e. 420KB
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.
(No TODO items are added, no sorting will be invoked, no chat message is submitted and no tabs can be changed).
Do you have websockets disabled at the firewall level or something? Do you see any errors in the console?
I am strongly invested in helping you get this working, so consider me willing to help and highly appreciative.
Firefox can’t establish a connection to the server at ws://expo.stimulusreflex.com/cable. action_cable.js:241:25
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.
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.
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 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!
Can someone please suggest some alternatives.
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.
So many apps don’t need a react front end to be usable and accessible, and the cost of maintaining a rich front end can be quite high.
The two most successful chat apps in the world today are slack and discord and they use react and electron on the desktop.
How many Slack users are on the free plan?
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.
And as far valuation, Uber and Lyft both have multi billion dollar valuations and are both losing billions a quarter.
Companies have been producing both native Mac and Windows software for over 35 years.
Except the reality is that option has always been on the table. There's a meta problem here about why that option isn't the preferred one.
Actually optmizing and/or caching DB requests so your backend returns a response within 150-200ms max.
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.
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.
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.
Why? What problem does it solve?
But most complaints I hear on the topic is the same criticism of js in general. So much rope you can hang yourself with.
In this case, "if the user isn't gonna need it, don't bother."
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.
Does anyone have experience writing SPA/PWA without frameworks? I'm interested in the idea of minimal JS even at the cost of productivity.
I can easily make websites that will rank 100 on google pagespeed insights using React.
The bloat and slowness of modern websites is not from javascript and any frameworks.
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.
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.
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.
What is it? Because I highly doubt that statement. Ajax, DHTML, ActiveX, and Java Applets offered effectively the same solutions in the late 90s.
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 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.
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.
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.
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.
The author said frameworks == bloat. But the above suggests frameworks != bloat. So I don't know what point you're still trying to make.
> A lot of people are designing their products to show off to their peers
Again, I'm not sure how using new frameworks is "showing off for your peers".
> or for google (SEO)
Client-side rendering only makes SEO harder. Again, I'm not sure what argument you're trying to make.
Present clear reasoning and evidence instead of vague, preconceived assumptions.
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.