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 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.
> 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.
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%.
>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.
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."
> 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.
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.
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!
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.
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.
[+] [-] karaterobot|6 years ago|reply
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.
[+] [-] flomo|6 years ago|reply
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.
[+] [-] stef25|6 years ago|reply
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.
[+] [-] flukus|6 years ago|reply
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.
[+] [-] tracer4201|6 years ago|reply
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.
[+] [-] JohnFen|6 years ago|reply
They don't. They use frameworks because it reduces the cost of production. Unfortunately, they accomplish this at the cost of the user experience.
[+] [-] taurath|6 years ago|reply
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%.
[+] [-] jblow|6 years ago|reply
People keep claiming these things increase productivity, yet there seems to be very little evidence of productivity increase.
[+] [-] collyw|6 years ago|reply
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.
[+] [-] loco5niner|6 years ago|reply
I'm sure everyone wishes these things were faster.
[+] [-] goatinaboat|6 years ago|reply
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!
[+] [-] xg15|6 years ago|reply
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.
[+] [-] freehunter|6 years ago|reply
[+] [-] speakwithalisp|6 years ago|reply
[+] [-] peteforde|6 years ago|reply
https://news.ycombinator.com/item?id=21933356
[+] [-] mikekchar|6 years ago|reply
[+] [-] fyfy18|6 years ago|reply
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.
[+] [-] candiodari|6 years ago|reply
Or to put it directly: craigslist is faster than amazon.com. And, frankly, more fun to use.
[+] [-] jkoudys|6 years ago|reply
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.
[+] [-] TheOtherHobbes|6 years ago|reply
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."
https://www.w3.org/Style/CSS/current-work
[+] [-] ericb|6 years ago|reply
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.
[+] [-] JDiculous|6 years ago|reply
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.
[+] [-] abraham|6 years ago|reply
[+] [-] peteforde|6 years ago|reply
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.
http://expo.stimulusreflex.com/demos/tabular
[+] [-] eftokay83|6 years ago|reply
(No TODO items are added, no sorting will be invoked, no chat message is submitted and no tabs can be changed).
[+] [-] keithnoizu|6 years ago|reply
[+] [-] softwaredoug|6 years ago|reply
[+] [-] monoideism|6 years ago|reply
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.
[+] [-] ScottFree|6 years ago|reply
[+] [-] systematical|6 years ago|reply
[+] [-] te_chris|6 years ago|reply
[+] [-] Animats|6 years ago|reply
[1] https://interface.fh-potsdam.de/future-retro/HN/
[+] [-] throwaway286|6 years ago|reply
[+] [-] overgard|6 years ago|reply
[+] [-] silvi9|6 years ago|reply
[+] [-] baron816|6 years ago|reply
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.
[+] [-] rkagerer|6 years ago|reply
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!
[+] [-] connectsnk|6 years ago|reply
Can someone please suggest some alternatives.
[+] [-] thosakwe|6 years ago|reply
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.
[+] [-] dagaci|6 years ago|reply
[+] [-] epicgiga|6 years ago|reply
[+] [-] rellekio|6 years ago|reply
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.
[+] [-] systematical|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] deltron3030|6 years ago|reply