20 ms·

Putting Devs Before Users: How Frameworks Destroyed Web Performance

201 points by CM30 7y ago

exabrial 7y ago
Speed is the number one feature. SPOs are the antithesis of fast. https://twitter.com/gravislizard/status/927593460642615296 https://twitter.com/gravislizard/status/927593460642615296
- BoiledCabbage 7y ago
  Actually, features are the #1 feature, and the slow performance of the web proves it.
ecmascript 7y ago
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.
- xg15 7y ago
  > 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.
  - ecmascript 7y ago
    > Could you make a few examples? 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.
    - plorkyeran 7y ago
      What part of that do you think wasn't possible on the web 5-10 years ago? The term "ajax" is 15 years old now.
      - true_religion 7y ago
        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.
- meritt 7y ago
  > For example, I work on an app which wouldn't be possible on the web 5-10 years ago What is it? Because I highly doubt that statement. Ajax, DHTML, ActiveX, and Java Applets offered effectively the same solutions in the late 90s.
  - ecmascript 7y ago
    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.
    - meritt 7y ago
      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.
      - ecmascript 7y ago
        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.
- namewasmypw 7y ago
  > 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.
  - gdev20 7y ago
    I think that you don't understand that web developers build what they are told to, not what they want. And if the company want a SPA you build it.
    - namewasmypw 7y ago
      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.
      - Eikon 7y ago
        And the others are good professionals without a job then I guess.
        namewasmypw 7y ago
        Right, just like how civil engineers are starving so hard they'll build faulty bridges for a paycheck. The post you made tells us a lot about how software ended up in the hellhole it has, and shows us why "software engineering" is currently an oxymoron. If Web developers had consequences like actual engineers, they would be killing their users instead of merely abusing them.
xg15 7y ago
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.
- freehunter 7y ago
  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.
  - purerandomness 7y ago
    Turblinks, and/or https://intercoolerjs.org/ https://intercoolerjs.org/ with a very similar, but more generalized approach.
- speakwithalisp 7y ago
  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.
- peteforde 7y ago
  I know that it's gauche to post links to other parts of a thread, but I didn't want you to miss this: https://news.ycombinator.com/item?id=21933356 https://news.ycombinator.com/item?id=21933356
- mikekchar 7y ago
  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.
taurath 7y ago
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%.
- jblow 7y ago
  If this is true, then why does it take so many engineers to make web sites today? People keep claiming these things increase productivity, yet there seems to be very little evidence of productivity increase.
  - JimmyRuska 7y ago
    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.
    - ScottFree 7y ago
      > 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++?
Animats 7y ago
The page mentions the "re-imagining of Hacker News", which was actually built.[1] Were they serious? [1] https://interface.fh-potsdam.de/future-retro/HN/ https://interface.fh-potsdam.de/future-retro/HN/
- throwaway286 7y ago
  Do they have to be serious? To me, this is the playful sort of thing you would see on the "old internet" that people miss.
- overgard 7y ago
  It's kind of fun and interesting even if it's impractical. Probably just meant as a thought experiment.
- silvi9 7y ago
  It's futuristic, bold, and imaginative. What's not to love?
redis_mlc 7y ago
I wanted to call out Patreon for one of the slowest web applications today. Guys: click on developer tools and watch the paint dry.
connectsnk 7y ago
I have heard this rant too many times. Other comments in this thread are also just adding to the rant or trying to justify SPAs. Can someone please suggest some alternatives.
- OnlineGladiator 7y ago
  > 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.
- save_ferris 7y ago
  The alternative is deciding whether or not you actually need an SPA to build your app. 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.
- friedman23 7y ago
  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.
  - connectsnk 7y ago
    Thanks
  - scarface74 7y ago
    Slack is not “successful”. Slack is a for profit business bleeding money is slow and still not seeing adoption by many major corporations. How many Slack users are on the free plan?
lambdasquirrel 7y ago
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.
softwaredoug 7y ago
Is it just me, or has anyone else sensed a shift back from thick SPAs to Server-side rendering precisely because of performance?
- te_chris 7y ago
  We’re all in Phoenix LiveView because it truly does give the best of both worlds.
- ScottFree 7y ago
  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.
- systematical 7y ago
  I never got on the SPA bandwagon, unless the UX required it. But then, I'm old. Burn your JavaScript stickers.
- monoideism 7y ago
  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.
rellekio 7y ago
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.
- speakwithalisp 7y ago
  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.
  - rellekio 7y ago
    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.
systematical 7y ago
I'm glad I'm not alone. Burn your JavaScript stickers.
deleted 7y ago
[deleted]
jkoudys 7y ago
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.
- TheOtherHobbes 7y ago
  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." https://www.w3.org/Style/CSS/current-work https://www.w3.org/Style/CSS/current-work
  - jkoudys 7y ago
    Well... yeah. 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.
karaterobot 7y ago
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.
- flukus 7y ago
  > 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.
- flomo 7y ago
  > 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.
baron816 7y ago
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.
friedman23 7y ago
This article contradicts itself and it doesn't actually describe how frameworks destroy web performance. 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.
JDiculous 7y ago
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.
- abraham 7y ago
  The median desktop site is almost 2MB. https://httparchive.org/reports/page-weight https://httparchive.org/reports/page-weight
  - deleted 7y ago
    [deleted]
  - threeseed 7y ago
    That includes resources like images, videos etc. Javascript is 1/5 i.e. 420KB
    - Cyykratahk 7y ago
      The linked Medium article is over 3MB, almost 2MB of that being JS.
      - 7y ago
deleted 7y ago
[deleted]
rkagerer 7y ago
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!
peteforde 7y ago
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. http://expo.stimulusreflex.com/demos/tabular http://expo.stimulusreflex.com/demos/tabular
- eftokay83 7y ago
  Maybe it's because I'm at work, but wherever I click on the site, it won't work - neither on Firefox, nor on Chrome. (No TODO items are added, no sorting will be invoked, no chat message is submitted and no tabs can be changed).
  - peteforde 7y ago
    That is very strange. 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.
    - eftokay83 7y ago
      Yeah seems you are right. Can't connect via websockets. Console output: Firefox can’t establish a connection to the server at ws://expo.stimulusreflex.com/cable. action_cable.js:241:25
fyfy18 7y ago
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.
- candiodari 7y ago
  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.
hypfer 7y ago
This is just garbage.
_bxg1 7y ago
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.
- maxymajzr 7y ago
  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.
  - _bxg1 7y ago
    > But are we seriously going to pretend that projects built with react are in a few hundred kb range? 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.
  - 7y ago
seventhtiger 7y ago
As a developer I'm much less comfortable working with JS frameworks. It seems like each one tries to hijack the JS experience and create its own. Does anyone have experience writing SPA/PWA without frameworks? I'm interested in the idea of minimal JS even at the cost of productivity.
mamon 7y ago
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
thosakwe 7y ago
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.
rado 7y ago
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.
dagaci 7y ago
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.
deltron3030 7y ago
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.
gridlockd 7y ago
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.
epicgiga 7y ago
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".
luord 7y ago
Rule 0 should always be the one from Tron: Fight for the users. In this case, "if the user isn't gonna need it, don't bother."
testtest143 7y ago
test

201 points by CM30 7y ago

Speed is the number one feature. SPOs are the antithesis of fast. https://twitter.com/gravislizard/status/927593460642615296 https://twitter.com/gravislizard/status/927593460642615296

BoiledCabbage 7y ago
Actually, features are the #1 feature, and the slow performance of the web proves it.

ecmascript 7y ago

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.

xg15 7y ago
> 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.
- ecmascript 7y ago
  > Could you make a few examples? 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.
  - plorkyeran 7y ago
    What part of that do you think wasn't possible on the web 5-10 years ago? The term "ajax" is 15 years old now.
    - true_religion 7y ago
      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.
meritt 7y ago
> For example, I work on an app which wouldn't be possible on the web 5-10 years ago What is it? Because I highly doubt that statement. Ajax, DHTML, ActiveX, and Java Applets offered effectively the same solutions in the late 90s.
- ecmascript 7y ago
  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.
  - meritt 7y ago
    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.
    - ecmascript 7y ago
      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.
namewasmypw 7y ago
> 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.
- gdev20 7y ago
  I think that you don't understand that web developers build what they are told to, not what they want. And if the company want a SPA you build it.
  - namewasmypw 7y ago
    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.
    - Eikon 7y ago
      And the others are good professionals without a job then I guess.
      - namewasmypw 7y ago
        Right, just like how civil engineers are starving so hard they'll build faulty bridges for a paycheck. The post you made tells us a lot about how software ended up in the hellhole it has, and shows us why "software engineering" is currently an oxymoron. If Web developers had consequences like actual engineers, they would be killing their users instead of merely abusing them.

xg15 7y ago

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.

freehunter 7y ago
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.
- purerandomness 7y ago
  Turblinks, and/or https://intercoolerjs.org/ https://intercoolerjs.org/ with a very similar, but more generalized approach.
speakwithalisp 7y ago
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.
peteforde 7y ago
I know that it's gauche to post links to other parts of a thread, but I didn't want you to miss this: https://news.ycombinator.com/item?id=21933356 https://news.ycombinator.com/item?id=21933356
mikekchar 7y ago
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.

taurath 7y ago

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%.

jblow 7y ago
If this is true, then why does it take so many engineers to make web sites today? People keep claiming these things increase productivity, yet there seems to be very little evidence of productivity increase.
- JimmyRuska 7y ago
  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.
  - ScottFree 7y ago
    > 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++?

Animats 7y ago

The page mentions the "re-imagining of Hacker News", which was actually built.[1] Were they serious? [1] https://interface.fh-potsdam.de/future-retro/HN/ https://interface.fh-potsdam.de/future-retro/HN/

throwaway286 7y ago
Do they have to be serious? To me, this is the playful sort of thing you would see on the "old internet" that people miss.
overgard 7y ago
It's kind of fun and interesting even if it's impractical. Probably just meant as a thought experiment.
silvi9 7y ago
It's futuristic, bold, and imaginative. What's not to love?

redis_mlc 7y ago

I wanted to call out Patreon for one of the slowest web applications today. Guys: click on developer tools and watch the paint dry.

connectsnk 7y ago

I have heard this rant too many times. Other comments in this thread are also just adding to the rant or trying to justify SPAs. Can someone please suggest some alternatives.

OnlineGladiator 7y ago
> 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.
save_ferris 7y ago
The alternative is deciding whether or not you actually need an SPA to build your app. 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.
friedman23 7y ago
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.
- connectsnk 7y ago
  Thanks
- scarface74 7y ago
  Slack is not “successful”. Slack is a for profit business bleeding money is slow and still not seeing adoption by many major corporations. How many Slack users are on the free plan?

lambdasquirrel 7y ago

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.

softwaredoug 7y ago

Is it just me, or has anyone else sensed a shift back from thick SPAs to Server-side rendering precisely because of performance?

te_chris 7y ago
We’re all in Phoenix LiveView because it truly does give the best of both worlds.
ScottFree 7y ago
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.
systematical 7y ago
I never got on the SPA bandwagon, unless the UX required it. But then, I'm old. Burn your JavaScript stickers.
monoideism 7y ago
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.

rellekio 7y ago

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.

speakwithalisp 7y ago
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.
- rellekio 7y ago
  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.

systematical 7y ago

I'm glad I'm not alone. Burn your JavaScript stickers.

deleted 7y ago

[deleted]

jkoudys 7y ago

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.

TheOtherHobbes 7y ago
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." https://www.w3.org/Style/CSS/current-work https://www.w3.org/Style/CSS/current-work
- jkoudys 7y ago
  Well... yeah. 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.

karaterobot 7y ago

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.

flukus 7y ago
> 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.
flomo 7y ago
> 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.

baron816 7y ago

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.

friedman23 7y ago

This article contradicts itself and it doesn't actually describe how frameworks destroy web performance. 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.

JDiculous 7y ago

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.

abraham 7y ago
The median desktop site is almost 2MB. https://httparchive.org/reports/page-weight https://httparchive.org/reports/page-weight
- deleted 7y ago
  [deleted]
- threeseed 7y ago
  That includes resources like images, videos etc. Javascript is 1/5 i.e. 420KB
  - Cyykratahk 7y ago
    The linked Medium article is over 3MB, almost 2MB of that being JS.
    - 7y ago

deleted 7y ago

[deleted]

rkagerer 7y ago

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!

peteforde 7y ago

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. http://expo.stimulusreflex.com/demos/tabular http://expo.stimulusreflex.com/demos/tabular

eftokay83 7y ago
Maybe it's because I'm at work, but wherever I click on the site, it won't work - neither on Firefox, nor on Chrome. (No TODO items are added, no sorting will be invoked, no chat message is submitted and no tabs can be changed).
- peteforde 7y ago
  That is very strange. 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.
  - eftokay83 7y ago
    Yeah seems you are right. Can't connect via websockets. Console output: Firefox can’t establish a connection to the server at ws://expo.stimulusreflex.com/cable. action_cable.js:241:25

fyfy18 7y ago

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.

candiodari 7y ago
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.

hypfer 7y ago

This is just garbage.

_bxg1 7y ago

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.

maxymajzr 7y ago
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.
- _bxg1 7y ago
  > But are we seriously going to pretend that projects built with react are in a few hundred kb range? 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.
- 7y ago

seventhtiger 7y ago

As a developer I'm much less comfortable working with JS frameworks. It seems like each one tries to hijack the JS experience and create its own. Does anyone have experience writing SPA/PWA without frameworks? I'm interested in the idea of minimal JS even at the cost of productivity.

mamon 7y ago

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

thosakwe 7y ago

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.

rado 7y ago

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.

dagaci 7y ago

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.

deltron3030 7y ago

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.

gridlockd 7y ago

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.

epicgiga 7y ago

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".

luord 7y ago

Rule 0 should always be the one from Tron: Fight for the users. In this case, "if the user isn't gonna need it, don't bother."

testtest143 7y ago

test