31 ms·

Second-Guessing the Modern Web

• paulryanrogers 6y ago
  Good points that seem to boil down to choose simplest tool for the job, even if it's not trendy.
  • K0SM0S 6y ago
    It's my personal philosophy in many things, but I like to insist that it's far from being the end-all be-all of good engineering in general. Perhap so I don't fall prey to the usual weaknesses of a hacker.
• wrnr 6y ago
  > If Wikipedia were started today, it’d be React. Maybe? No, I'm building a hard fork of wikipedia and I'm using Go to render the pages on the server side and a vanilla JS for a user friendly the rich text editor. I don't know why not more people use WebComponents as a light weight alternative to React/Vue/Angular. It was natural choice in my case because it grew out of the desire to keep the tech stack small. For now I haven't find a reason to regret it, two way databinding is nice to have, but when the js is reloaded with every page, the global state is easier to reason about and less of a problem.
  • K0SM0S 6y ago
    Probably because "more people" are not trained to "use WebComponents as a light weight alternative to React/Vue/Angular", let alone lead a team in that direction (and assume responsibility for a thing that has no market value on their resume... it's the situation 80% of tech workers find themselves in). Momentum is a b#%~~ I mean, momentum is hard to ignore. The sad reality is that trendy will always be driving behaviors for as long as recruiters attach value to buzz-words and -names. Meanwhile, I guess a few will take the risk to do good engineering and damn the name of techs used, hopefully to rise to decision-making positions. Hopefully. Oh who am I kidding.
  • compressedgas 6y ago
    Is that a replacement for mediawiki or an actual a fork of wikipedia?
    • wrnr 6y ago
      Both, its 2020 wikipedia should have had a WYSIWYG editor a long time ago. They keep making excuses why this can't/should't be the case, so I want to migrate over the content to a new system.
• forgotmypw17 6y ago
  Wikipedia has been taking some strides in this direction. For example, on the "mobile" site, if you follow a link from an expanded page section and then go back, the section is no longer expanded, and you lose your place. (Then it re-expands, but you're in a completely different place on the page now.) This type of stuff is one of the reasons why I choose to support older browsers like Netscape, IE, and Lynx. I think that a website which would have been usable 25 years ago has a much better chance of being usable by some random person using an old device I've never heard of and a browser I've never tested with.
  • saagarjha 6y ago
    It turns out that aside from HTTPS, most older browsers can do quite well with HTML websites! If you do it right, all old browsers will be able to render it because it'll work in WorldWideWeb.app.
    • forgotmypw17 6y ago
      This is true to an extent, as I have discovered. However, if you want universal html (no changing the html for individual browsers) and some half-decent web-app functionality and no-js compatibility and accessibility and for it to look pretty, be prepared to spend many hours tweaking it. Here's a video of some testing I did recently. Here, I discover that IE doesn't play nice with being forwarded to a URL which has an anchor at the end. https://www.youtube.com/watch?v=M5tGkDgpq7w https://www.youtube.com/watch?v=M5tGkDgpq7w
• echelon 6y ago
  HTML should never have grown into the mutated application runtime it is today. The presentational concerns for documents are different from application rendering. The javascript stack should have been something entirely separate. I strongly feel we should create a lightweight HTML fork that is again document-centric and doesn't allow for all of this javascript nonsense. Something that doesn't allow for stupid custom UI or behavioural tracking. Just text, images, videos, and links. The painting algorithm would be dead simple, documents would load lightning fast, and we'd be confident there would be no ad malware.
  • frank2 6y ago
    Creating it is the easy part, IMO. The hard part is to get people to publish on it. I fear that most authors (and most creators of images and links) are not knowledgeable enough to see the web's shortcomings and that it will be very hard to explain the shortcoming to them -- with the result that most authors will continue to consider their job to be done once they have put their writings (and images and links) on the web.
    • compressedgas 6y ago
      It already exists and it is called HTML. It is how JS is used to load page contents that can not be tolerated. Follow progressive enhancement. No JS should be required to load the contents of a page. If JS is included it should be to replace what would otherwise require a full page reload. If it is not possible to load the contents of a page without JS or the JS fails to complete, then the page should show its alternative contents. The page shall under no case be left blank. This is graceful degradation.
      • frank2 6y ago
        >Follow progressive enhancement. . . . This is advice for a web site owner, and I don't see giving advice to web site owners to be an effective way to help internet users who are very annoyed with the web like I am. Web site owners are embedded in an ecosystem controlled by entities such as Google and Mozilla who either don't know or don't care about the dissatisfaction I and people like me have with the web. I have come to believe that the best way to help internet users who are sufficiently like me is not to try to improve or change the web, but rather to start a new internet service outside of the control of Google, Mozilla, etc. Great grandparent seems to have come to a similar conclusion. Modern web browsers are designed to satisfy goals X, Y Z, U and W. You are pointing out that browsers can be used to do X. I (along with great grandparent IIUC) are replying, yes, it can, but a new service designed to do X alone will probably do it better with fewer bugs and glitches. And all the web site owners with goals Y, Z, U and W are really getting in our way when we pursue X; our moving to the new service would give us a way to separate ourselves a little from those site owners, saving us a lot of time and annoyance.
• userbinator 6y ago
  Either you omit some interactive elements on load, or you try really hard to make sure that the JavaScript loads faster than users will click, or you make some elements not require JavaScript to work - like making them normal links or forms. Or some combination of those. I realise I'm in the minority, but I use JS whitelisting, which means that any SPAs I come across in my web searches (a disturbingly large number, and unfortunately increasing) will quickly make me go back since I can often find what I'm looking for somewhere else, on a site which doesn't require running arbitrary code just to render what usually turns out to be static content anyway. The state of web development has always seemed a bit odd to me, largely driven by fashion and a desire for developers to "outdo" one another in complexity. There's a ton of churn and ADHD as people jump around from one trend to the next; instead of settling down and focusing on getting the most out of a platform, they're eternally in search of the next one. Reinventing/reimplementing in JS what basic HTML and CSS can do is just one example of this behaviour. The massive overuse of the "modern" adjective is another, and quite frankly all this really irritates me, as someone who just wants to use the Web as a hypertext document system to find some information.
  • tiborsaas 6y ago
    > instead of settling down and focusing on getting the most out of a platform How do you know when to settle? Should we have stopped at jQuery? We are doing exactly what you are asking for, but not in the way you like. Web developers are getting the most of the web platform. The result is that new frameworks and libraries are keep popping up. Most will sink, a few will float and it's okay, this is how evolution should happen. I don't like all tech solutions that I encounter just because they are new. I simply just don't use them in my projects, simple as that. I'm sorry, but the web not just a hypertext document system to find some information, it has outgrown this idea probably 20 years ago.
    • austincheney 6y ago
      > Web developers are getting the most of the web platform. I disagree, as so many (perhaps most) web developers have no idea what to do with web technologies aside from building SPAs in their pet framework.
• rebelnz 6y ago
  IMO React and it's ilk are amazing in some applications but the problem is trying to make 'everything' a React/Angular/Vue app without considering scaling or how it would benefit a user. I have been tasked with building complex UX'x which would've been far simpler and performant as a multi-page type app with some plain JS sugar.I agree with wrnr - I too am leaning more towards WebComponents where some dynamic functionality is required. It provides us the ability to not only keep the tech stack small and also avoid all the dependency and version pitfalls.
• acemarke 6y ago
  Dan Abramov put up a tweet thread agreeing with this piece, and talking about how the React team is now looking at trying to come up with some server integration capabilities to enable a hybrid model for the rest of the community: https://twitter.com/dan_abramov/status/1259614150386425858 https://twitter.com/dan_abramov/status/1259614150386425858
  • fenwick67 6y ago
    This is some spin mastery. "yes you're right, React is bad, we're continuing to work on it and make it even better"
    • saagarjha 6y ago
      I mean, what did you think he was going to say? React is bad, we're dropping it?
      • cosmojg 6y ago
        That's exactly what we wanted him to say. Use heavy tooling only where necessary and nowhere else. React is rarely necessary.
      • mellow2020 6y ago
        "React is bad in your case, drop it." I know it's far out idea in tech, to flat out tell someone "you don't need this, you just save time and money and get a better result of you don't use what we made", but it shouldn't be. React is fine per se, the problem is throwing these "simple, magic" solutions onto everything, without even caring what mountains of code end up running as a result. The minimum for a Discourse installation is 10 GB, for example, but PHP is the weird ecosystem, because reasons. I don't mean to pick on Discourse, but that's still crazy to me.
        • fastball 6y ago
          I personally liked how easy it was to install Discourse thanks to Dockerization, and don't care one whit about requiring 10GB of space (cheapest DigitalOcean droplet comes with 25GB).
• theonething 6y ago
  > There’s no category winner like React as an alternative I'm really rooting for frameworks like Phoenix LiveView, Rails Turbolinks, Laravel Livewire to fill this void. SPA like interactivity by just rendering HTML templates and sending them to the client via Ajax or websockets sounds great to me. I wouldn't miss JavaScript one bit.
  • correlator 6y ago
    Rails turbolinks is magic!
    • snazz 6y ago
      I quite like Turbolinks too, but it can have some unintended interactions with other JS code. If you're looking to make your non-SPA site faster another way, you can try https://instant.page/ https://instant.page/ as well. It preloads pages as you hover over them, which makes links feel like they load instantaneously. It's a pretty cool trick! You can try it out on their project website or on https://www.snazz.xyz https://www.snazz.xyz.
      • pier25 6y ago
        Cool trick! Sapper (the Svelte framework) does the same if I'm not mistaken.
        • alessioalex 6y ago
          Indeed: https://hn.svelte.dev/ https://hn.svelte.dev/
    • theonething 6y ago
      Curious if you (or anyone else) have used the ios and/or Android adapter for mobile? Seems like the repos are getting stale. Getting SPAness on web and mobile apps for free would be the holy grail. Basecamp claims it works great for their mobile app.
• Normal_gaussian 6y ago
  I've been freelancing whilst working on some of my own projects, and have helped a devent number of clients get their front end approach cleaned up enough to work for their end-user and use case. So when I read an article like this (which I like by the way), I make comment/response style notes to make me think through it; its long but I've dropped it in here in case anyone cares: The issue with bundle splitting for SPA's that he mentions is a real thorn in many peoples side. A not amazing, but workable solution is to structure the site as follows: * Split your "entry" bundle down to nothing, so it is only the map of other things that can load and a bootstrapper that looks at the URL and loads the right one. * On the server generate html files for all your main endpoints (or hot routes for dynamic paths), ideally these are Server Side Rendered, but at a minimum they must include a script tag for both the normal entry bundle and the correct primary bundle for that page (ie, you eliminate the round trip for requesting the bundle). The issue of running an "out of date" app is a present one. I can often restructure it to gracefully cache the state and refresh at an appropriate time without the user noticing, but it is often a far cry from simplicity. His attack on SSR is largely correct for the way people currently deploy it, but there is nothing stopping you doing it a lot better. It is perfectly possible to generate correct HTML that works without needing to have a hydration step - its just most people aren't willing to, or knowledgeable enough to, do the work to make only the parts that need rehydration be hydrated (or, allow everything to be rehydrated but with no effect to the majority of the page). To be clear, you don't need to hydrate links, buttons, or even basic forms. Of course, anything that genuinely requires your app js to be around to do anything reasonable needs to be there; but if you aren't looking for a drag/drop stay on page interaction you can normally just add a traditional route to allow it as well (more work of course). He is right about API's. Though I'd hardly count it as a web or an SPA problem. Software is all about abstractions and how they are very leaky (likely "unfixably" so). I was surprised about the data fetching comment. I've taken a look at the React docs and done some searches around the web, and he's right. Unless you know what terms to search to get the useful patterns its just a mess of amateur/broken Medium posts. SPA's are built on top of browsers that are trying to predict where we are going and react to where we were yesterday at the same time. I'm with the author that most things don't need react, and that the things that do are mostly SPA's that have to be SPA's. I have worked with other frameworks before, but my hammer is a nodeJS & React stack I've cobbled together; thankfully its very good at SSR generating static sites, so most people don't know I'm using such a big hammer. And we finish with a wishy washy maybe its right maybe its wrong, do we need this, maybe we do, maybe we don't. Here is something concrete. I'm writing a small web application for my sisters business that I'm going to be doing all the legwork to see if it can grow into something. It isn't a SPA, it has some highly complex interactions, and it only uses React as a static site templating language because of my exisiting well-tooled stack (hammers make things nails).
• austincheney 6y ago
  The only important question is whether this is a technology problem or a business problem. Fundamentally the problem is this: Web developers don't know what they are doing and oversell their capabilities. To be more clear though, this isn't a new problem, just that the symptoms of the problem have changed as the tools have evolved. I remember starting at Travelocity in 2007 and they sure as shit didn't know what they were doing either. All the JavaScript developers there, except for 1 (so about 6 of them) were spun off onto a special project that never made it to production. There was 1 guy left to write JavaScript for the rest of the site in a company who only real product was a website and employed 3500 people. All the other developers were Java people. Most of those guys were scared shitless of web technologies. There were a few Java developers who had a solid working knowledge of CSS and JavaScript but worked extraordinarily hard to keep that a secret. That was a big WTF, but then I discovered it was also the same at both Expedia, Orbitz, and Southwest. Now people really, and I am not being figurative, expect Angular and React to do their jobs for them from solving technical problems to telling them exact what products to build. Worse still is when you point out the incompetence that so clear to everybody else the developers doing the work get angry. I mean hostile out to stab in you the back angry. The non-developers see the dysfunction and have absolutely no idea how to manage it or solve for it. Sometimes the dysfunction is so pronounced that it leads to inter-department warfare within the company, as was the case in one of those previously named travel companies (not Travelocity). Here I am 13 years later working on the web that is now a 30 year old platform (20 years old if you count the modern standard web), and its still the same shit show. How have businesses allowed such cancer to prosper?
  • pnako 6y ago
    What you describe as "broken" is what I imagine to be the ideal situation. I expect travel agencies and similar websites to have a rock-solid back-end, and I don't care at all for any Javascript fanciness. In fact I would expect their websites to work with JS disabled. The fact they canned whatever special project the JS developers were working on might have been the right decision (and I just checked, Travelocity is still in business).
    • austincheney 6y ago
• burlesona 6y ago
  This is an absolutely perfect take on what’s wrong with front-end web right now. I've been trying, and failing, to explain this at work for several years now. Indeed, swimming against the cultural tide is hard. React is built on two fundamental ideas that are both extremely valuable. The first and most transformative is that the web is mostly made of _components_, and specifically that organizing the markup, javascript, and CSS makes many thing easier. The second idea is that _declarative programming_ is better than imperative. The thing is, HTML and CSS are already declarative. So React is not inventing this, nor bringing it to the web, but rather providing a pretty solid idea for how to make Javascript (or more generally, complex interactivity in the browser) declarative as well. Thus, as MacWright argues, there is a sweet spot for React (or similar libraries) where you have highly interactive, complex UI elements on the screen. But the rest of the web really, really doesn't need it, and when you try to apply "React Everywhere" things get very bloated, slow, and complicated, very fast. This is _especially_ true if you didn't start from scratch with Next.js or create-react-app, but are incrementally converting an established application. It's just painful. I think more and more people are realizing this, and the fact that Dan Abramov himself agrees is pretty indicative that the tide is going to turn. But the question is, what next? One major problem that the author didn't go into is the special pain of bundling front-ends these days. The actual work of setting up and integrating a "modern" javascript asset pipeline with a server side framework is not trivial, and I've yet to see a framework nail this. In the ones I've used there's always some gotcha - if you don't roll your own web pack (and understand what every bit of it is doing), you will eventually run into some library you want to use that just won't play nice with the rest of your bundle, and then you have a problem. And on the JS side, even simplicity-focued tools like Parcel are SPA oriented, thus gluing them together with your server-rendered app is non-trivial. I think that will remain an issue for a while. But it also means there's an opportunity for the "old school" frameworks to keep working at this and, if they really nail the bundling and server-rendered / reactive component handoff, to thrive in the next decade of web development.
• MattGaiser 6y ago
  The problem with not using a JS framework is that eventually, the investors/business person/design team/frontend enjoying devs wants this highly animated site with all sorts of little toggles, confirmation boxes, popup models, toasts, etc. It is far nicer doing that in React where you can just casually npm in some online component that does that rather than in vanilla JS or jQuery. React is basically a compromise between nice interactive websites and keeping it as programming. Nothing stays simple and when it stops being simple, you want React. Developers like simple sites like Hacker News. Nobody else does.
  • Frost1x 6y ago
    >Developers like simple sites like Hacker News. Nobody else does. I'm not entirely sure about that. Pretty sure most people just want some program to accomplish the function they're using it for so they can move on with their day, not chase around an overly complex and forever changing UI they have to keep up with, ontop of their actual work.
  • coffeefirst 6y ago
    Except for the user, who never asked for vanity animations and hate the popups.
    • seangrogg 6y ago
      Well, when I am considered a developer AND a stakeholder I may be able to address that AND not be told that I'm going to implement the carousel because "market research" anyways.
    • MattGaiser 6y ago
      The focus groups seem to love those things.
    • askafriend 6y ago
      Wrong. I ask for it as a consumer. I expect it, and I demand it. We're in 2020, I don't want to click around on hyperlinks - I'm sorry. I grew up in a world of interactivity and the iPhone. My bar is very high for consumer services. Animations and smooth transitions are table-stakes.
• grizzles 6y ago
  For me next.js fixes all the problems with react. The only thing it's imo missing is a sync feature. Like pouchdb or sharedb for files & sqlite rows. If it's of interest I wrote a feature request for a first step towards this: https://github.com/zeit/next.js/discussions/12374 https://github.com/zeit/next.js/discussions/12374
• buboard 6y ago
  > But the cultural tides are strong. Building a company on Django in 2020 seems like the equivalent of driving a PT Cruiser and blasting Faith Hill’s “Breathe” on a CD while your friends are listening to The Weeknd in their Teslas. Swimming against this current isn’t easy, and not in a trendy contrarian way. more like, your friends are listening to Weeknd on vinyl and gramophones because their friends do. The more i read about JS frameworks the more i want to start doing everything in Perl again, or C, because its the work that matters and not the tools.
• daguar 6y ago
  > But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are optimizations to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology. I think this is at the root of it — most web devs today don't see that some plurality or small majority of web app use cases these days just don't require the tradeoffs of SPAs. But there's a generation of devs who've come up exclusively on JS tooling (Node, Express, React/Redux or Angular) and the crowding effect has therefore made those the default choices, if only because the labor pool is big. My honest belief is you can more quickly build most functionality needed for most businesses with a plain-old full stack framework like Rails or Django these days. But the real value of those frameworks doesn't show in the initial speed to build (though it's there!) — it really shows up in how much common functionality (logins, file uploads, etc.) you get for free 6-12 months in, and how low your cost of change stays over time as a comparable SPA app becomes a pain in the butt to add new features to.
  • theonething 6y ago
    I agree with this. In my experience, adding React or friends doubles the size and complexity of your application and in a lot of cases, the benefits accrued are not worth it. You essentially end up having two applications to maintain and therefore two places to manage state and make sure they sync correctly. I commented below that I hope frameworks like Phoenix LiveView will be the future. Seems like the best of both worlds, the simplicity of server side html rendering with SPAlike interactivity. Of course not perfectly. There are tradeoffs no matter what decisions you make.
  • kace91 6y ago
    Speaking as a young(ish) dev, I think the issue with SPAs is that it's that its use has been conflated with separation of concerns and agnostic backend dev. What I mean by that is that the way we learned is that the old/wrong way (php style templates) mix front end and backend development, and data with formatting. It's better to have data available through rest APIs and then consume it from something. Which is mostly true if you plan on being available in a reasonable way from smartphone apps, etc. but of course that means that your website should also be a client capable of working as similarly as possible to a mobile app - there you go, SPAs. We need to find a way to keep those benefits without the bulk of current SPAs. But SPAs appeared for a reason, and it would be wrong to ignore why it happened. Being able to have front and backend devs working in parallel is a benefit, being able to server your content to several frontends is a benefit, etc. (And if you're thinking "these people don't need apps anyway", the reality is that clients demand to have them - even if it's only so they can bother users with push notifications or collect data, they do ask for them).
• baron816 6y ago
  The first big project I had as a professional SWE was to rebuild a checkout page to use React. Seems like overkill for a single checkout page to be its own React app? It wasn’t. There was a lot of edge cases. It needed to handle different countries (some have states, some have zip codes, Brazil has a crazy tax scheme), different SKUs, different payment methods (including resellers), free trials, etc. The original template + jQuery rendered version was nearly impossible to work with. Any sort of change would take forever and would lead to bugs whose patch would only increase complexity. React substantially simplified the page, and it actually looked and performed much better since there wasn’t any jankiness from HTML rendering before JS could correctly format the page. We were then able to experiment on the page to optimize the experience and drive conversions. TL;DR, more often than you would expect, the tiny performance costs you face from using a SPA is more than made up for by being able to develop quickly and more confidently.
• amw-zero 6y ago
  We should create a better division in web standards between the "document web" and the "application web." I think there are valid use cases to both, and we shouldn't rule out either. Wikipedia has to be the greatest realization of the initial spirit of the web: an endless interconnected network of articles of varying topics. That's a real use case, but it's not the use case of _every_ application. Some applications really want to make use of a richer UX, one that doesn't need to re-render the entire page from scratch on every button click. Maybe Gmail is the best example of using the SPA experience to drive a rich UX. The web browser was not meant to build such applications, that's something we don't acknowledge enough. The web browser was designed, since day one, to render and link between text documents. We've been trying to play UX catch-up for 20 years at this point, and it's finally converged with lots of support for treating the web as an application platform as well (React, Angular, etc.) So we've taken years to arrive at SPA's, but I think they're completely justified. They absolutely have tradeoffs, but they're not pointless tradeoffs. That doesn't mean that all applications should be SPA's, but I also think it's completely wrong to say that all applications should be simple documents too.
  • asalahli 6y ago
    > Maybe Gmail is the best example of using the SPA experience to drive a rich UX. My experience is quite the opposite. I still use Gmail's "Basic HTML" UI, and it takes less time for me to click a link and load a new page on that UI than any interaction on the default UI.
    • atroche 6y ago
      I'm skeptical of that. Have you timed it in Chrome DevTools? E.g. when I hit 'c' on the keyboard to compose an email, it's effectively instantaneous.
    • redwall_hp 6y ago
      I use a regular mail client on my computers and phone, and don't touch webmail with a ten foot pole. Google did it best, but it's still junk.
    • amw-zero 6y ago
• bit_logic 6y ago
  What I dislike the most about the modern web and the unnecessary use of SPA technologies is how unreliable and error-prone it has made sites that really need to be simple and reliable. For example, banking websites, utility websites, government websites (like DMV, unemployment, and others), anything where failure or mistakes have a high cost. These sites should stick to reliable, tried and true, pre-SPA technologies. But now that's "boring" and "not-modern" so they rebuild using React (or whatever is the popular SPA framework this month) and the result is often a huge degradation in site quality.
  • Yhippa 6y ago
    Because of the cargo culting, you see all sorts of Fortune 500 companies using this for fairly critical end-user tasks and failing at it. Air Canada did a redesign a while ago and I still can't book a flight on there. You look at the console and it's barfing all sorts of client-side errors and 500's. I would rather have a static, slow, reloading app that is reliable. There are good uses for SPA's like ticket sites that have virtual queues and office applications. I just don't see the advantage SPA's give me for a lot of critical things I need to do in my life.
• luxphl 6y ago
  I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G. web technologies, and it worries me that they create a sort of gatekeeping effect on the industry, but I think it's disingenuous to outright claim React & co. are bad from a development perspective. I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general. I've done lots of native development on Desktop and Mobile and I can sort of see how you get there if that's your point of reference, but if you work on web apps daily it's clear why the popular technologies are popular, and it's not hype.
  • Dowwie 6y ago
    You are contradicting yourself by opening with a claim of time savings and ease of use followed by admitting that the solution is largely more complex. More complex work does not save time in aggregate and is not easier to use.
    • networkimprov 6y ago
      The solution is not more complex to the developer or user, it's more complex to the browser, which hardly ever complains when you make it work harder :-)
      • owl57 6y ago
        Users could complain when someone makes their browsers work harder. Looking around the net, they mostly don't. I don't know. The only time I developed a serious full SPA, I intended to use it myself on a $50 phone, so I actually kept complaining to myself until it started loading in reasonable time and working instantly after that.
• azangru 6y ago
  > But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. If "React" is used loosely here to mean a modern frontend framework, then at least one concrete benefit is the ease of splitting web pages into components, and the ease of co-locating CSS with these components. I have tried Eleventy with nunjucks, but compared to the way React (Vue, Svelte, whatever) allow you to organize your code, it felt really awkward. Even Google dev rels, such as Jake Archibald, admit that they love the developer experience of something like Next.js [0] [0] https://developers.google.com/web/shows/http203/podcast/social-distance-ssr-patterns-and-bedtime-routines https://developers.google.com/web/shows/http203/podcast/soci...
  • s-km 6y ago
    This is pretty much it, tbh. Every time one of these types of threads pop up you get a bunch of people commenting about how broken the web is and how it sucks because front end devs aren't real devs or something, and it's immediately clear to me that none of them have done any serious work on a modern website. The problem is a business/orgnanizational problem - it's not like developers are incapable of mimicking their own websites with pure html+css+js (especially with all the improvements to JS and the browser apis over the years), it's that doing that and then maintaining and growing it with a team of people is basically impossible at any useful scale. Frameworks provide a common language for teams to build their site with. The fact that they also currently introduce a lot of extra complexity that require developers to handle previously "free" things (ex. performance, bundle splitting) isn't some fundamental flaw with the idea of frameworks, it's just a result of people still trying to figure out exactly how the hell you can provide a nice, interactive site with all the bells and whistles that'll make like 5 different groups of stake holders happy.
• okareaman 6y ago
  React is a great example of YAGNI and premature optimization. I'm sure Facebook benefits from it, but most websites don't need it. JSX is an abstraction encouraging deeply nested components, which makes state handling hard, necessitating the invention of React Hooks. "Controlling complexity is the essence of computer programming" -- Brian Kernighan. I see a celebration of complexity in modern website development and it makes me sad (I'm retired, I don't get that sad about it.)
  • deleted 6y ago
    [deleted]
  • ng12 6y ago
    That's not why hooks were invented. Hooks are by definition component local.
    • okareaman 6y ago
      I'm not a React expert, but I wonder how do you interpret this by Dan Abramov? This is where I got my information about hooks before trying them out: React doesn’t offer a way to “attach” reusable behavior to a component (for example, connecting it to a store). If you’ve worked with React for a while, you may be familiar with patterns like render props and higher-order components that try to solve this. But these patterns require you to restructure your components when you use them, which can be cumbersome and make code harder to follow. If you look at a typical React application in React DevTools, you will likely find a “wrapper hell” of components surrounded by layers of providers, consumers, higher-order components, render props, and other abstractions. While we could filter them out in DevTools, this points to a deeper underlying problem: React needs a better primitive for sharing stateful logic. https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-intro.html
      • ng12 6y ago
        Right, it's not that managing state was hard it's that sharing the logic to manage it was hard. Hooks are additive in that way -- it's offering you the ability to re-use your stateful React logic in the same way you can re-use your declarative JSX.
• cageface 6y ago
  Use the right tool for the job. Why is this so controversial? Yes SPA frameworks are overused but a lot of modern web "apps" are actually real applications and can't be built on a reload-the-world on a mouse click paradigm of the old web.
  • shockinglytrue 6y ago
    What constitutes a real application? There is some obsession with preserving client-side state as if the user could not live without it, and yet in almost every case where significant engineering has been put in to (essentially) reimplementing a web browser within a web browser, the result is either on a par or slower, and almost always vastly more cumbersome than just shipping a brand new page. There are so many things the majority of applications never even try to get right, like progressive loading or history management, that have been solved problems for browsers since the dawn of time. Separately, avoidance of client JS eliminates multiple classes of potential bugs, because eliminating (or minimizing) active behaviour on the client prunes vast chunks of the overall application state space. I hire contractors quite regularly, and the amount of time I waste almost weekly having to explain "no Javascript, rip it back out, you're making a mess", because so few people seem to understand this. Our market is somewhat unique, in that most clients are high latency low bandwidth, but even if that were not true I expect my direction would still be the same. "The page content is smaller as JSON" .. "you introduced a round-trip, game over" "We only need 200KB of JS what's the problem" .. "the page didn't even start to render until the last byte of JS was loaded" "We can implement mixed rendering and fix this on the server" .. "or you could just send HTML and rip out the JS, which is what we're doing"
    • cageface 6y ago
      This is an overly broad statement. In the last year, for example, I've built an in-browser SVG vector drawing tool and a very detailed dashboard with a lot of nested charts and data visualizations. Neither of these would have been possible without a heavy client-side JS component. My current project is an e-commerce app that's almost entirely server rendered. I avoid JS where it's not needed but also avoid irrational biases against it when it is needed.
• pier25 6y ago
  You guys should give Svelte a try. It's a breath of fresh air for modern JavaScript. Your codebase becomes much simpler. It's much faster and lighter than React. It doesn't give you absolute flexibility like React + JSX does, but it solves your most common problems much more pragmatically.
  • cageface 6y ago
    There are a lot of really interesting ideas in Svelte. I'm waiting for Typescript support to jump in.
  • tomaszs 6y ago
    Swelte has exactly the same problems author mentions about React.
    • pier25 6y ago
      Obviously Svelte can't do nothing about the misuse of Svelte (which is one the major points of the article) but: > The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too high for any company to include it as part of an SDK. Svelte is just a simple way for you to write vanilla instructions. There is no runtime and practically no framework. Other than React he is criticising problems which have better solutions than the ones he is proposing. For example the bundle splitting problem can be solved by a smart browser refresh at the appropriate time. The SSR problems he mentions are non existent with Svelte as the JS needed for an SSRd page is probably less than 5kB and since those are so small you can preload all JS files on the first user visit. He also mentions authentication problems which are non existent if your SSR app talks to the database and uses some KV cache for sessions. It's also certainly possible to cache the HTML, not only in the server but in the browser too using service workers. As for his critique of APIs I don't agree. He also states that "GraphQL application will suffer under the N+1 query problem" which is true on the most simplistic implementations. Hasura, Fauna DB, and other GraphQL servers don't suffer from this problem at all.
      • lhorie 6y ago
• komali2 6y ago
  I see this sentiment a lot, and sympathize with it because I value accessibility and access to content by people with less powerful devices and connections. But full time I'm employed to build web apps that I can't conceive of building without Vue or React or some other AJAX tool at least. For example, a node management system, displaying up to twenty disparate nodes at once. Client expectations are that any edited node is immediately persisted to the server. If I refresh the page, I've got to rerender each of those elements. If I'm not using tech that has things like v-for, I'm building out 20n wonk ass custom event handlers from scratch... I'd love to find ways to build this vanilla, I do that for my personal projects, but I don't see a path.
• what-the-grump 6y ago
  Reeks of obscurity engineering. Simple crud is being rewritten into react, things that could be done 300-400 lines are being written into 2 month long projects. The vast majority of tooling, pages, functionality is so simple that I want to puke every time someone drops in node,react,Vue to replicate something that could be done in 100 lines of python or perl.
• root_axis 6y ago
  My subjective counter-take: "modern web" is fine and where it lacks it is improving over time. React/Vue/Angular/Webpack are clear improvements over what came before despite the learning curve, which is obviously much overblown considering all the hand-wringing over n00bs using React for their blog. React is not to blame because someone used it to build a blog, but it's also ok not to make an SPA. It's also ok to filter JavaScript out of your job search so you never have to build an SPA ever again. Lastly, the best part about "the Modern Web" is that the 20 year old approach to building web pages still works just fine, fire up NotePad++ and have it.
• AzzieElbab 6y ago
  I am not a web dev, but what exactly is an alternative to fat spa if you are building a truly interactive front end? How does server rendering work when you lose connection to the server?
• giantrobot 6y ago
  I think deep down people writing SPAs really just Flash apps or Applets would come back. They want to ignore everything about the web except the ability to deliver content over a network. I'd go so far as to say they hate the web as a concept. Most problems stem from that disdain for the web. Many of those problems are then exacerbated by "opinionated" frameworks being en vogue. None of them are helped by the shit platform that is JavaScript. I've seen the justification for SPAs front end JavaScript frameworks being a desire to separate data and presentation. A back end API serves data that's displayed by the app. We had that fifteen years ago with XSL! There were these things called "browsers" and they could parse and display HTML and even XML. They supported stylesheets that could arbitrarily style those documents for display. They could even decide to use different styling depending on the display device! If they sound amazing they were. I mentioned XML parsing. An XML document could be used to represent all kinds of arbitrary data. While a browser might consume XML, a native application or service could also consume it. But arbitrary XML in a browser wasn't super useful since a browser didn't have rules to display every different XML document that could be made. The people that developed XML also came up with a way to transform data in XML to different formats. Browsers, being able to handle XML already, added support for this transforming. An XML document could include a link to this stylesheet and the browser could transform it into something (XHTML) that it did have rules for displaying, including CSS to further style elements and JavaScript to make everything terrible. A native app or service consuming an XML doc could and often would ignore the stylesheet so to them it was just data. Even JavaScript asynchronously loading XML data would ignore stylesheets. Usually it was only browsers that cared about linked stylesheets. But this let a single API serve browsers and native apps and even JavaScript. Presentation and data were separate concerns. Browsers would also cache all the display resources for a document so when a new document was viewed all of those resources would be cached locally. But then for whatever dumb set of reasons web developers ignored these "browsers" and and their cool abilities. They insisted on ingesting XML to their JavaScript and then manipulating the DOM of an HTML page causing hundreds or thousands of repaints. Then they knew better still and replaced XML with JSON. By making the data serialization format require JavaScript they could obviate the browser even more. Now browsers are relegated JavaScript runtimes and even web servers are just load balancing proxies for JavaScript runtimes running on servers.
  • 6y ago
• runawaybottle 6y ago
  I’m tempted to step back and evaluate this on another level. Our industry is very big, and any industry that gets that big will be able to house a lot of people just for the sake of it. If you think we have a large amount of fresh frontend people, understand they are hired almost with a one to one correspondence with fresh product/business people. Modern product development is essentially a polishing job on every component that Twitter Bootstrap or Jquery UI ever invented. Over and over, we dress up a modal, with a slider, with a ‘user flow’, with some tooltips, and so on, and allow the process to masquerade around as real design/engineering. There’s so much money in this industry that we can hire entire teams to basically take a Bootstrap component, and theme it. This gets passed on as product development, and from the developer side, it gets passed on as engineering. If this is the level of masquerading occurring, why would a frontend developer ever go ‘what’s the right solution here?’. Something similar is happening on the backend and infrastructure. It too will take on a mask behind devops and data science and start pumping out what are probably straight up SQL queries and cron jobs. This will get passed off as design and engineering as well. We’re too big.
  • ngold 6y ago
    And yet, unlike newspapers with an in house advertising staff. All web adverts are 3rd party. That are easily blocked. Google laughs to the bank everyday it killed old advertising.
  • PaulDavisThe1st 6y ago
    What do you consider "our industry" to be ? Software development? Web development? What used to be called "Application Development" back in the 1980s and early 1990s? I'm asking because there's a lot of software developers/engineers whose jobs don't feature any of the keywords in your comment ("Frontend", "Backend", "SQL queries", "modal" etc. etc.)
    • aryehof 6y ago
      If all one has been exposed is a development world of web-based consumer-facing front-ends (CFUI), it is hard to imagine that the majority of software lies elsewhere. Hard to imagine that anything else is important. It leads to a viewpoint that modern programming is mainly about UI interacting with a database.
• itsthecourier 6y ago
  I'm an old dog, almost 20 years programming now. 30 years old. Started with basic, actionscript, java, c# and back to java. Some guys had an app locally made, European big company acquires them laughed at them and force them to move to a 2019 new entreprisy platform of theirs. I saw a portal these guys have to manage everything via SSO, they used like 30 different third party apps. Don't get me wrong we use planning stuff, wikis, analytics, but this was excessive. Anyway, their super app was react-graphql-microservices (40 of them)-redis-elastic search-many dbs-aws services Performance was horrible, data leaks everywhere, no trottling, google speed complaining. 15 engineers on charge of it. A team of 1 backend engineer, 1 ux designer and 1 mobile engineer replace THE WHOLE THING in 1 month with: xamarin, rails, postgres with jsonb and fulltext search, s3 and some heroku. Oh about web js, we used some vue.js and I believe some jquery We were surprised too. As a Java old dog I have seen this before with RIA apps in flex. Fear of missing out makes do stupid things. Warren buffet called them institutional impedance if I remember correctly. Monolithic with modules is good until you crash with a hyper growth barrier, meanwhile simple is better
• scarmig 6y ago
  The core issue is that the web was intended as a document delivery platform, not an application delivery platform. That mismatch means one of two things: you either have to pervert your application to expose a document-centric UX, or you pervert the document platform to look like an application platform. I would say in 95%+ of cases, perverting your application is the better choice: my core issues with the web now are surprising/malign UX patterns and terrible performance, not cross compatibility or lack of features offered by browser APIs. That doesn't mean you should forgo JavaScript entirely, but the construction of the UI and UI interactivity should not be its primary responsibility.
• pier25 6y ago
  I think one of the big reasons a lot of people are moving to SPA or SSR + hydration is latency of dynamic content (static content can be cached at the edge with little effort). The problem with traditional PHP/Rails/Django apps is that those cannot easily run on multiple locations. Even if you somehow find an easy way to redirect the user to a server near them you still have to solve the problem of replicating the database. Big companies with cash and talent can solve all that but for small dev teams this is much harder to solve with a traditional web dev approach. With an SPA your user will click and the UI will refresh instantly, even if it's just to show a spinner or some mock data, but that will be enough to distract the user for the time it will take for the API to respond. With SSR you can run your html rendering code in serverless functions at the edge. Your latency will be sub 100ms, even sub 50ms when you hit the DB cache. I'm doing this with Cloudflare Workers and Workers KV as a cache and using Fauna DB which is also ditributed and running close to the edge. If it wasn't because the local dev experience of workers is still in alpha I'd say I've hit the jackpot of performance and DX. Scaling is another matter but I don't think it's such a common problem for the vast majority of projects as latency which happens on every request.
• _bxg1 6y ago
  I've barely used Next.js, so take this with a grain of salt, but to me the whole "hybrid" approach where you statically-render-and-hydrate has always felt like one big heaping pile of hack. The amount of grotesque complexity that's required to achieve this "best of both worlds" solution, and the number of asterisks that have to be added to that title, have never sat right with me. I'm a believer that you simply need to decide from the outset: "Is this a web app that people are going to dwell on? Are they going to stay here and use it or are they simply going to visit it?" And if yes, go all-in on treating it as a capital-a App whose "binary" consists of minified JavaScript, and if no, just stick with server-rendering. Most things fit neatly into one or the other. There's no need to shoot for the moon. I do have to disagree with this part, though: > The high performance parts aren’t React...The level of abstraction that React works on is too high In my experience it's perfectly possible to write your complex, screaming-performance app in React or the like and spot-optimize it as needed. I've done that sort of thing myself. Now, something like Mapbox probably lives mostly in WebGL, which is not concerned with the DOM, so that portion isn't really relevant to React. And the question does get more complicated when it comes to shipping an embeddable widget. But at a base level, I think React and its abstractions are perfectly well-suited to high-performance apps.
  • granshaw 6y ago
    The good thing about starting with just server rendering is that you can sprinkle in react if you just have one section with heavy interactivity and build from there, whereas it’s harder to go the other way around
• enahs-sf 6y ago
  I strongly support this sentiment. I’ve recently come to the conclusion (after building a non-trivial react app from scratch) that the optimal use case is in a rails/django/go/whatever app that only uses react to handle front end state for the hairy components while the lion’s share is handled by the server.
  • retreatguru 6y ago
    What would that look like in practice. Would you write 95% of the basic crud stuff as server side rendered then just have the React or Vue component for the really complex UI stuff? Would there be downsides having the mix of languages (assuming your backend language is not JavaScript) ?
    • enahs-sf 6y ago
      most of the page is server rendered. The hairy bits (eg. complex forms, super interactive components) are react and they maintain their own state. There might be downsides but they're probably not worse than writing a bunch of jQuery.
• pcr910303 6y ago
  People use React not because because it's shiny (guess what, it's not, React was first launched 2013 - six years ago, and it's more aged than jQuery's age when React was born), nor because they want everything to be an SPA (contrary to common HN belief), the use it because it gives a battle-tested, excellent solution for components and reactivity. That's really the only reason why React is prospering, and why other libraries are trying to get inspired from React and tries to copy it's API surface. (Preact, Crank.js, etc...) For the pages to not use React, we really only need one thing: Built in reactivity to web components (custom elements). That's really the only reason why React is used. If you want to see static pages without JS, you could also need a method to define custom elements declaratively (in HTML). That two things is the solution to this problem. Not saying that web developers just want shiny things and everything is bloated.
• zelly 6y ago
  SPAs are a product of the mobile app frenzy of the early 2010s. Web devs felt left out and tried to mimic the shiny UX of mobile apps. Also SPAs allowed the web app to be just another frontend client, like a third mobile OS, sharing the same server API that the mobile apps consume. Generally trends that are based on delusion (that the web is just another app platform) tend to run out of steam at some point. Use the right tool for the job. You're not Facebook or Twitter. I can finish a Django hello-blog while you're still trying to get WebPack to transpile TypeScript(TM).
• Ericson2314 6y ago
  Reading stuff like this gets me hopeful that https://github.com/obsidiansystems/obelisk/ https://github.com/obsidiansystems/obelisk/ (from where I work) will be able to reach a wider audience. The author is right that the React ecosystem doesn't deliver what it claims to, but I think is overly pessimistic that the use-cases he describes are too diverse to be solved by a single solution.
• cryptonector 6y ago
  ISTM you need to strike the right balance. The ideal is that you have a static site and fetch data using JS -- this is good because it's simple. Most pages don't have a lot of data, and if there is data and its dynamic, then JS is needed to make the app responsive. On the other hand, if you have content that you could be fetching using JS but it's desirable to have it rendered every time you land on the page, then yeah, you want to render it server-side.
• robot 6y ago
  precisely the reason I went back to Jquery/HTML/CSS/ExpressJS server rendered pages.
• ttty 6y ago
  Just one thing. How do you reuse components on client and server side and at the same time keep the component encapsulated. For example I don't want my component to have a bit of php, a bit of JavaScript and then couple my JavaScript to the class that php gives me. This is a huge hack. If you have 2 states, they have to be both on JavaScript and php land... Not a waste? React solves this huge problem.
• ollerac 6y ago
  A lot of the comments here are missing two key points: 1. Google and Facebook have created really high-standards for what's considered a usable web application 2. HTML is still a language highly optimized for creating static documents, not building the reactive applications most devs want to build I think experienced developers might even deliberately ignore how much of a moat these two facts create for big companies (because it serves their interest as well). Think about it: if styling/designing/building a web app like Google Docs was easy, do you really think Google would be able to maintain its lead in every vertical in that market for so long? Sure, maybe for some use cases it's the best solution — but what about lawyers or doctors: they could certainly use a custom version of a real-time document-editing app. But, by keeping web development hard (i.e. split into a million different technologies that have trouble connecting with each other), Google and Facebook have enough breathing room to be able to create THE real-time work platform and THE social network, without worrying too much about competition sneaking up behind them. And, if some small startup does manage to get off the ground despite the incredible engineering effort required, Google can just copy or acquire them with some of the billions they've made from their technology moat — and voila, as an extra bonus — all the devs who work at that acquired startup are already trained in the specific framework that Google and Facebook uses (oh yeah... that's why they open sourced it in the first place...). By creating this huge moat between what's a "good enough" real-time web application in the eyes of most users (who expect instant updates, smooth transitions, collaborative features, and interoperability by default) and what most developers can pull off in a few months, these big companies can ensure they stay on top and not too many competitors arise. And why don't developers fight back against this? Because this moat benefits us as well. It artificially inflates our salaries by making web development a super complex field. Not only do you have to know a lot of technologies and all of their secrets settings, you also need to know how everything fits together behind the scenes. Can you imagine if web development was as simple as learning a single language? We'd all be making far less money by tomorrow. All these moving pieces and arcane knowledge gives us pride in knowing something other people done, while making it extra hard to be a new developer. It also protects our employers from being disrupted every 2 weeks, giving some economic stability to the tech market at large. Another benefit it provides to those already in power is an easy way to control who the next breakthrough success: if you're running a startup that's competing (even tangentially) with Google or Facebook or the thousands of other entrenched players, you'll need a million dollars just to catch up to them in terms of creating a usable product. People aren't going to be impressed with your photo sharing app if its interface isn't as sleek as Facebook's or Instagram's. What's the solution to all this? The no-code movement? Perhaps low code? Nah — those are patches in a sinking ship. The fundamental fact is: the web wasn't made for building dynamic web applications (and web components aren't actually simplifying the process). Think about this: your browser doesn't even know what a "user" is or how to connect to a database or what a SPA is. And how long have we been building these things over and over again? It's absurd there aren't standard APIs for all of it... But that would destroy the moat. I think the true solution is a next gen version of HTML that abstracts away and standardizes everything difficult about building a web app. Devs need to be able to focus on just building awesome products that serve a need — not configuring Webpack and getting a 5 year degree in CSS before even getting started. It's too bad Google owns the most popular web browser (that could actually make a difference in this fight) and Facebook has convinced every developer I know that they've solved web development. It'll be their self-created competitive advantage until all developers simultaneously go crazy from having to re-implement the same damn architecture again for the thousandth time.
• axguscbklp 6y ago
  React, Redux, Webpack, 90% line coverage testing requirements... I understand intellectually, sort of, kind of, often not really..., why those things came to be... but for fuck's sake, they have really sucked the joy out of my web development. It feels so much more free and fun to just sit down and hack some vanilla HTML/CSS/JS. The modern web development stack has attained "bondage and discipline" levels rivaling those old Java enterprise edition stereotypes.
• brailsafe 6y ago
  I've found that using things like React, for things as mundane as a blog or marketing site, just makes me sad. If my pursuit was to spend my time thinking about tricky issues — which it is — I get sad when to output doesn't necessitate the complexity I navigated to get there. Whatever I end up doing next, I hope it's something more interesting than webpages re-invented. Even working on purely design is way more challenging and interesting, and necessarily so, than frontend web "engineering". Things that do fall outside of this reduction are fully interactive applications like Mapbox studio that really weren't feasible before.
• 29athrowaway 6y ago
  The modern web should be rebooted: - Browsers are a privacy mess. Users are left exposed to blatant fingerprinting, tracking across websites, etc. - Instead of JavaScript as first class language, use WebAssembly or a similar language as a first class language. Developers may continue to use JavaScript if they prefer, but the code they deploy should be WebAssembly. - Instead of HTML and CSS, browsers should use a binary representation of a document. Developers may continue to use HTML and CSS, but what they deploy is this new binary format, not HTML and CSS. That would make documents more compact and render faster. And, this makes it possible to replace HTML and CSS with something else.
• danschumann 6y ago
  Better bundle splitting would solve most of his gripes, no?
• TheCabin 6y ago
  "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction."
• kostarelo 6y ago
  > I can, for example, guarantee that this blog is faster than any Gatsby blog (and much love to the Gatsby team) because there is nothing that a React static site can do that will make it faster than a non-React static site. Gatsby produces static HTML which I guess is the same with the authors' website. How can we compare two static HTML websites and conclude on what's faster? Just by saying so is not the answer.
• nyanpasu64 6y ago
  I generally agree with this article, but: > And then there’s the authentication story. If you do SSR on any pages that are custom to the user, then you need to forward any cookies or authentication-relevant information to your API backend and make sure that you never cache the server-rendered result. Isn't this also a problem in conventional server-side-rendering (eg. PHP) websites? And Steam once had a caching bug and accidentally showed people others' profiles?
• nojvek 6y ago
  I get the SPA movement. I’m a big proponent of it. If a user is navigating between many similar pages or wants high interactivity without a page load then you want to cache the views as js scripts via cdn and only download the data via REST calls to an api. It works well with mobile apps too. Both web app and mobile app talk to the same api. What I don’t get is the server hydration kungfu. If you’re rendering the template on the server then don’t do the same thing again with js and download the data twice. Just render html serverside and call it a day. Either app or a site. A tiny bit of jquery like JS snippets for banners and image galleries make sense but that shouldn’t be render blocking nor be in megabytes. I’m a big proponent of Preact over React. Same API but much smaller library. The difference is noticeable when browsing on 3G networks and low powered devices.
• marcthe12 6y ago
  In fact SPA in general are suppose to work around a single issue, sending a request will lose all your state and reload the whole page(If different content, downlaod whole html). Since most website have multiple routes this is an actual issue. You need to sync state with server for example. I think the solution will be able to say "all this route are the same site" to the browser and now browser can be able to allow delta update or store some variables. This will be perfect with html imports.
• eximius 6y ago
  There was a recent article on having your website be entirely statically regenerated except for a select few components that require interactivity: shopping carts, comments, etc. That way, your entire site is basically live just on a CDN, infinitely scalable. Even if your API server goes down, only the small subset actively engaging with interactive content would know! With client side persisting technology like service workers, you can pair down which interactive content matters for that. Really seems like the direction I'd want for my next project. And, again, Svelte and Sapper support exporting static sites... Really I'm continually impressed by their position I'm supporting great patterns out of the box.
• dnprock 6y ago
  This discussion reminds me of Java and C/C++. In those days, we used to write messy programs in C. The language works well if you want to write some targeted libraries. It becomes really difficult to write complex software. I think Microsoft Windows has thousands of engineers to maintain their C codebase. Java appeared on the market. It's a big change. It really brought out the goodness in Object Oriented paradigm. It made software engineering more rigorous. Most enterprise software made the switch to Java. They need the reusability of Java. Microsoft came out with C# to counter the rise of Java. We have the same situation here with JavaScript and TypeScript/React. React brings structure to the messy world of JavaScript. But it also incurs the cost of traditional enterprise software engineering on the web development. I expect performant libraries to continue in plain JavaScript. Reusable web components will move to TypeScript/React. It's exciting to have better technologies to use for our projects. I don't think one will diminish the other. They'll both co-exist.
• petejames 6y ago
  This raises good points. SPA are certainly not the right solution for all projects. Static pages (such as AMP) are great for document type projects where speed is important and vanilla is often needed for high performance apps. It's a great reminder not to jump into create-react-app without first considering the right approach.
• masoudd 6y ago
  I wanted to add that this sentiment is not new. Here it is from 2016: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f https://hackernoon.com/how-it-feels-to-learn-javascript-in-2... Web development clearly has a problem. I don't know enough to say what we have to do about it but I look at the current state and my face curls up in disgust
• EXO1 6y ago
  jordens sander
• luord 6y ago
  While I largely agree with most of the points made, I strongly disagree with the objections made about APIs. In general, that section seems to have been written with the assumption that the web application is the only client an API can have. This ignores mobile applications, desktop applications, third party services, webhooks, SDKs and maybe even command line interfaces. The more standardized the API, the easier it is to create multiple clients for it; it's one of the principles of the clean architecture even.
• jackleslie 6y ago
  > If Wikipedia were started today, it’d be React. Maybe? Interestingly, MediaWiki actually discussed using React for future web projects recently, but opted to use Vue.js instead: https://phabricator.wikimedia.org/T241180 https://phabricator.wikimedia.org/T241180