<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>JMTQp8lwXL</author><text>Doing the work on the client can sometimes be the right choice, but I&amp;#x27;ll share a converse point. I was tasked with implementing a bulk record upload feature. The UI was to accept up a CSV file with up to 1 million records. The API provided by the backend team accept max 1,000 records in JSON.&lt;p&gt;So now I have to convert CSV, for which there&amp;#x27;s no official specification, to JSON, and then make (up to) 1,000 HTTP requests via HTTP 1.1 -- and a different back end team owns rate limiting for all ingress. I end up using a package called &amp;#x27;promise-limit&amp;#x27; to ensure only N number of requests are open at a time; firing 1,000 simultaneous XMLHttpRequests is a bad idea. I end up fielding bug reports concerning the translation to JSON for edge cases. And collating the 1,000 network responses for any individual record that failed to persist was something we didn&amp;#x27;t get to building. So users were uploading 1M records, had some proportion fail, and had 0 visibility into what data the system had, and what data didn&amp;#x27;t make it.&lt;p&gt;Eventually, we gutted all of that and the backend team added a file upload endpoint. But explaining why this shouldn&amp;#x27;t be a front end feature, to folks who primarily or exclusively do backend work, it&amp;#x27;s tough to communicate (1) all the pain points of dealing with the complexity in the front end and (2) the scalability issues. &amp;quot;Can&amp;#x27;t you just do it on the front end&amp;quot; is such a frequent retort I receive, for things we truthfully should do on the backend.</text><parent_chain><item><author>jefftk</author><text>Doing most of the work on the client instead of the server can often make scaling much easier.&lt;p&gt;I read your comment as assuming that the division between the server&amp;#x27;s job and the client&amp;#x27;s job is fixed, but as the browser has become more powerful many things have moved to the client.</text></item><item><author>ocimbote</author><text>&amp;gt; build apps that scale easily to hundreds of thousands of users&lt;p&gt;I don&amp;#x27;t understand this.&lt;p&gt;Frontend dev is about writing a portable software to run on as many runtimes as there are users. There is literally nothing to prevent any frontend software, good or bad, to &amp;quot;scale&amp;quot;, because scaling in terms of users is nonsical for frontend dev (unless you consider browser compatibility as scaling, to which statement I&amp;#x27;m orthogonal).&lt;p&gt;Note: meanwhile, back end dev is about writing a program that accepts as many users as possible, which make front and back nicely yin-yang together. But maybe I&amp;#x27;m overstating things here :shrug:</text></item><item><author>j-krieger</author><text>I love modern frontend development. I can build apps that scale easily to hundreds of thousands of users. They are fast where they need to be fast, and building components means complexity lives only where it&amp;#x27;s needed. Static parts are rendered statically, dynamic parts are rendered dynamically. I can write all code for the entire stack in Javascript. The entire workflow is streamlined in a simple way (webpack really isn&amp;#x27;t that hard to grok). There are templates for every project imaginable. I don&amp;#x27;t need an entire VPS for my web-apps, just a simple static hosting service. My apps run on every system and any browser back to IE9 without any issues whatsoever. No complex build tools or linking process or debugging weird architectures needed. Compatibility issues are solved automatically in any modern build pipeline by adding vendor prefixes. New code is transpiled to old code for older browsers. Debugging modern front-end code is a breeze, there are an infinite amount of tools both for styling and the code itself. My modern frontend app takes seconds to build; QT apps I built in the past needed up to twenty minutes, just to check a simple change. No need for that with hot reloading. My users are happy too: They don&amp;#x27;t have to download an app which might not work on their specific system. Linux, Windows and Mac users alike can use it on their computers, laptops, tablets and phones without any issue. They can use the default environment a browser provides for an even better user experience (zooming, Screenreaders, upscaling fonts, copying images and text, preferences for dark mode, theming their browsers, saving credentials and auto filling them, sharing stuff, etc.). Integrating stuff from other companies has never been easier: Paypal, Stripe, Apple Products all provide a well tested and documented library for every framework out there. There are open source packages for anything, it&amp;#x27;s a FOSS dream. Building prototypes for anything is insanely fast, thanks to modern debugging tools in Chrome and FireFox.&lt;p&gt;It&amp;#x27;s much better than people make it out to be.</text></item><item><author>caseymarquis</author><text>I&amp;#x27;d like to add a bit more nuance. Modern frontend development provides many opportunities for failure. These failures often make their way into production. I, personally, get great results with modern FE development. My users are happy. I am happy. It&amp;#x27;s all very successful. All the defenders of modern FE development will likely chime in with the same sentiment. I also get great results with C, which arguably provides even more catastrophic opportunities for failure. I wouldn&amp;#x27;t say &amp;quot;C is a failure&amp;quot;, but I absolutely hate working in C, and I&amp;#x27;m glad we&amp;#x27;ve made improvements to systems programming. I think the point I&amp;#x27;m moving toward is that we absolutely should strive to make better tools for delivering web content, but the reasons for failure are far more complex than the tooling itself. So, let&amp;#x27;s not frame things in black and white and call something that&amp;#x27;s been used with large amounts of success a failure. That&amp;#x27;s not very productive and is just flame bait. The real question is, &amp;quot;What&amp;#x27;s next?&amp;quot;, how are we going to improve the current situation?</text></item></parent_chain></comment><story><title>I can only think that modern front end development has failed</title><url>https://twitter.com/antirez/status/1378272801522597888</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>u801e</author><text>&amp;gt; Doing most of the work on the client instead of the server can often make scaling much easier.&lt;p&gt;I&amp;#x27;ve also found that it results in a non responsive webpage.  For instance, text taking multiple seconds to render in an input box (Slack, Facebook, amongst others) and times where the browser tab process ends up allocating a signficant percentage of system resident memory and&amp;#x2F;or CPU resources, which makes the computer itself slow to respond.</text><parent_chain><item><author>jefftk</author><text>Doing most of the work on the client instead of the server can often make scaling much easier.&lt;p&gt;I read your comment as assuming that the division between the server&amp;#x27;s job and the client&amp;#x27;s job is fixed, but as the browser has become more powerful many things have moved to the client.</text></item><item><author>ocimbote</author><text>&amp;gt; build apps that scale easily to hundreds of thousands of users&lt;p&gt;I don&amp;#x27;t understand this.&lt;p&gt;Frontend dev is about writing a portable software to run on as many runtimes as there are users. There is literally nothing to prevent any frontend software, good or bad, to &amp;quot;scale&amp;quot;, because scaling in terms of users is nonsical for frontend dev (unless you consider browser compatibility as scaling, to which statement I&amp;#x27;m orthogonal).&lt;p&gt;Note: meanwhile, back end dev is about writing a program that accepts as many users as possible, which make front and back nicely yin-yang together. But maybe I&amp;#x27;m overstating things here :shrug:</text></item><item><author>j-krieger</author><text>I love modern frontend development. I can build apps that scale easily to hundreds of thousands of users. They are fast where they need to be fast, and building components means complexity lives only where it&amp;#x27;s needed. Static parts are rendered statically, dynamic parts are rendered dynamically. I can write all code for the entire stack in Javascript. The entire workflow is streamlined in a simple way (webpack really isn&amp;#x27;t that hard to grok). There are templates for every project imaginable. I don&amp;#x27;t need an entire VPS for my web-apps, just a simple static hosting service. My apps run on every system and any browser back to IE9 without any issues whatsoever. No complex build tools or linking process or debugging weird architectures needed. Compatibility issues are solved automatically in any modern build pipeline by adding vendor prefixes. New code is transpiled to old code for older browsers. Debugging modern front-end code is a breeze, there are an infinite amount of tools both for styling and the code itself. My modern frontend app takes seconds to build; QT apps I built in the past needed up to twenty minutes, just to check a simple change. No need for that with hot reloading. My users are happy too: They don&amp;#x27;t have to download an app which might not work on their specific system. Linux, Windows and Mac users alike can use it on their computers, laptops, tablets and phones without any issue. They can use the default environment a browser provides for an even better user experience (zooming, Screenreaders, upscaling fonts, copying images and text, preferences for dark mode, theming their browsers, saving credentials and auto filling them, sharing stuff, etc.). Integrating stuff from other companies has never been easier: Paypal, Stripe, Apple Products all provide a well tested and documented library for every framework out there. There are open source packages for anything, it&amp;#x27;s a FOSS dream. Building prototypes for anything is insanely fast, thanks to modern debugging tools in Chrome and FireFox.&lt;p&gt;It&amp;#x27;s much better than people make it out to be.</text></item><item><author>caseymarquis</author><text>I&amp;#x27;d like to add a bit more nuance. Modern frontend development provides many opportunities for failure. These failures often make their way into production. I, personally, get great results with modern FE development. My users are happy. I am happy. It&amp;#x27;s all very successful. All the defenders of modern FE development will likely chime in with the same sentiment. I also get great results with C, which arguably provides even more catastrophic opportunities for failure. I wouldn&amp;#x27;t say &amp;quot;C is a failure&amp;quot;, but I absolutely hate working in C, and I&amp;#x27;m glad we&amp;#x27;ve made improvements to systems programming. I think the point I&amp;#x27;m moving toward is that we absolutely should strive to make better tools for delivering web content, but the reasons for failure are far more complex than the tooling itself. So, let&amp;#x27;s not frame things in black and white and call something that&amp;#x27;s been used with large amounts of success a failure. That&amp;#x27;s not very productive and is just flame bait. The real question is, &amp;quot;What&amp;#x27;s next?&amp;quot;, how are we going to improve the current situation?</text></item></parent_chain></comment><story><title>I can only think that modern front end development has failed</title><url>https://twitter.com/antirez/status/1378272801522597888</url></story>