27 ms·

I fell in love with low-JS

• vips7L 4y ago
  I’ve found similar happiness in JTE server rendered pages with alpine.js to do the interactivity on the front end. I cannot recommended it enough.
• jaredcwhite 4y ago
  It's breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG/SSR-first solutions—to the degree that even the JS-framework-hotness-du-jour braintrust is going all-in on SSG/SSR. I'm still a bit steamed from being gaslit all throughout the mid-2010s years when we were told <div id="root"></div> + SPA was The One True Way of building web applications. Even now, I run into this mindset _in the Rails community_ of all places. But thankfully we know now how this story will end, because the advantages of wildly simpler stacks which work better with modern web specs AND offer improved performance in many cases are undeniable.
  • x3haloed 4y ago
    Ugh. Even reading this article. There’s always a The One True Way, even though there never really was. The right way always depends on the desired result.
    • djbusby 4y ago
      Too pragmatic, you'll never get clicks that way
      • cyanydeez 4y ago
        >1 Simple Trick To Adjust Your Attitude to the Task
      • coldtea 4y ago
        Pragmatic? I'd call it too generic. It's about as good as "a man's got to do what a man's got to do" as life advice. Yes, there's no "one size fits all" and there are exotic needs, but there are certain good ways to build web pages that fit a vast majority of the use cases, and on the other hand, there are fads and hype.
  • nick_ 4y ago
    > being gaslit throughout the mid-2010s This is exactly how it felt to me.
  • dvt 4y ago
    > I'm still a bit steamed from being gaslit all throughout the mid-2010s I get downvoted into oblivion every time I criticize React on HN (I mean, for one, Vue is like 10x better imo, but that's neither here nor there). Just too much money is poured into getting people trained on React and too many folks' livelihoods is directly tied to React for a serious critique of the monstrosity it turned into. Facebook really did take over the world.
    • antihero 4y ago
      Other than being owned by Facebook, I’m not sure how exactly React is a monstrosity. I think people downvote vue fans because it seems they can’t help but tirelessly bring it up any time there’s anything any React and a lot of people clearly don’t feel that vue is “better”, so it gets extremely irritating.
      • funstuff007 4y ago
        At this point, though, aren't React and Vue more similar than different?
        • steve_adams_86 4y ago
          I set out to figure out the answer to this question by writing about it and comparing various performance issues, ease of composition of components, debugging, etc. I didn’t find any particularly interesting or meaningful differences. At the template level, JSX exposes more plain old JavaScript than Vue’s templates do. I find defining and using types in JSX land more intuitive. Otherwise they’re fundamentally both excellent and very capable and neither is doing any one thing glaringly wrong. I ended up scrapping it because the deeper I went, the less interesting it got. I think it really does come down to ergonomics and preferences
          • mmcnl 4y ago
            Vue supports JSX as well, and has been doing so for years.
  • CharlesW 4y ago
    > It's breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG/SSR-first solutions… Has it, for you? The pendulum has not begun to swing back from where I sit, and I don't see any indications that it ever will.
  • dgb23 4y ago
    No pendulums are swinging here. What's happening is refinement and variation between two extremes.
    • jonwinstanley 4y ago
      Yes. I remember reading that this latest approach is only really viable because of the use of HTTP2 for the requests and the adoption of that technology. The swing towards frontend made sense before this step change in latency.
      • brimble 4y ago
        AJAX was originally about speed, but as soon as it changed from fetching and injecting HTML fragments, to fetching data (usually JSON) and performing a bunch of transformations and interpretations of it before finally modifying the DOM, it's been in practice slow as hell compared with traditional server-side rendering.
        • jonwinstanley 4y ago
          Totally agree. Doing everything on the frontend is great for making the UI feel responsive, but once you start grabbing large amounts of data from an API, manipulating it on the frontend while keeping it in sync with the server, you run into some major headaches very fast.
    • kevinmgranger 4y ago
      Isn't that how pendulums swing?
  • tomatowurst 4y ago
    I'm still a bit steamed from being gaslit all throughout the mid-2010s years when we were told <div id="root"></div> + SPA was The One True Way of building web applications. omg. tell me about it. One CTO I remember flat out getting angry that his reason for using React was because Facebook was doing it. that's it We are going to see more reversion to '05 days, with financials of SaaS as interest rates rise. I remember one CFO getting mad because spending $2 to make $1 doesn't make sense as an enterprise company and that his reason was because we are in a new economy. Perhaps I'm extrapolating but it seems that the boring, predictable and old is that way because it's been through market manias, both financially and technologically during periods of novelty recycling.
    • cmroanirgo 4y ago
      > One CTO I remember flat out getting angry that his reason for using React was because Facebook was doing it Lol. I find it ironic that from a developer standpoint, we're quick to jump with the latest FAANG libraries/cult thinking paradigms, but especially here on HN, we're equally quick to show the hate for those very same companies. Personally, I've found that all FAANG software is generally a good reason to not use it! (My solutions are all bricks and mortar sized, rather than oligarchal/massive advertising globalist farms)
    • colonelpopcorn 4y ago
      I love the smell of ASP.NET and Telerik in the morning...
      • La_Beffa 4y ago
        that's unfair :=) asp.net core is completely different beast compared to asp.net
  • madeofpalk 4y ago
    I think this is a bit disingenuous and misstating (or not understanding) the evolution frontend-focused web development has been through over the past 10 years. There’s no pendulum swing back to server-rendering, but rather new frameworks and techniques that involve both in unison.
    • MatthiasPortzel 4y ago
      Yep. It's very convient to pretend that we jumped from Apache template-includes to React, but there was a messy time in between where client-side rendering with jQuery was extremely popular.
    • woojoo666 4y ago
      Yeah I feel like every day there's an article on HN about how we're moving back to the old days without client-side frameworks. Except that's not true at all. People are still writing in React/Vue/Svelte, but now there's tooling that allows it to run on the server as well (SSR). Client-side frameworks are playing a bigger role than ever before. And there was no gas-lighting in the 2010's, SPAs are still here and many still use <div id=root>, even with SSR. We are seeing a bit of reduction in client-side bloat due to bundlers and compilers like Webpack or Svelte, but the value of client-side frameworks was never to add bloat to the client anyways. It was always about making it easier to write complex user features. So they provided things like better composability, better state management, etc. So when tools come along that provide the same benefits, while reducing client-side bloat, then of course the industry starts moving. I think there's also a slight sampling bias in HN because 90% of the posts here are articles and blog posts, both of which can be written in static html. So of course there's going to be blogs boasting about how they got away without a javascript framework. But the majority of internet users aren't browsing blogs, they're spending time on big web apps like Facebook and Youtube. And those web apps benefit greatly from these frameworks.
  • WesleyJohnson 4y ago
    This is admittedly off topic, but how did the term "gaslight/lit" become so common in recent years? I had never heard of it until several years ago when someone close was going through therapy regarding a loved one. Now, it's like I'm shopping for a mattress and I'm being inundated with mattress ads. That's not to take way from your experience or suggest it's not the appropriate word, I'm quite sure it is. I'm just curious if I was really oblivious of concept before my own exposure to it, or if it was called something else?
    • jffry 4y ago
      I don't know but Google Trends [1][2] bears out that it's very recently common. My best guess is that it has come up as part of the Amber Heard / Johnny Depp trial and that has spurred a lot of people searching for it. [1] Past 5 years, March & earlier - https://trends.google.com/trends/explore?date=2017-03-01%202022-03-01&geo=US&q=gaslit https://trends.google.com/trends/explore?date=2017-03-01%202... [2] Past 90 days including giant spike - https://trends.google.com/trends/explore?date=today%203-m&geo=US&q=gaslit https://trends.google.com/trends/explore?date=today%203-m&ge... (if you go to past year you can see the spike)
      • andai 4y ago
        "gaslighting" has a steady upward curve the last 10 years. My personal guess is that it has to do with psychology and mental health awareness going mainstream due to social media and psychology channels on YouTube. https://trends.google.com/trends/explore?date=all&geo=US&q=gaslit,gaslighting https://trends.google.com/trends/explore?date=all&geo=US&q=g...
    • yourad_io 4y ago
      The term "gaslighting" derives from the 1944 film Gaslight, in which a husband uses trickery to convince his wife that she is mentally unwell so he can steal from her. Gaslighting was largely an obscure or esoteric term until the mid-2010s, when it broadly seeped into English lexicon. https://en.wikipedia.org/wiki/Gaslighting https://en.wikipedia.org/wiki/Gaslighting
    • 4y ago
  • girvo 4y ago
    Now that the Web Platform as a whole has gained so many amazing features and quality-of-developer-life improvements, I think the pendulum was always going to swing back. <div id="root" /> was the "one true way" in the early-mid 2010s for a reason. But now we're all thinking in terms of components already, so whole-pages-only is not needed -- serve up partials only, and have your thin JS layer combine them all. Use the platforms features for as much interactivity as it can get you, for UX/UI reasons, and then use small amounts of JS for those things where you can't. It's quite nice! Though I still make my bread and butter with the <div id="root" /> as it currently stands. We'll see if that changes. Hilariously, in 2016 I tried to push a "front-end web server that consumes the API and gives up HTML/HTML partials" idea that was this exact pattern, but could not get enough buy-in at the place I was at. The tools weren't quite there, so we'd have to build a lot of them ourselves. Now, the tools are built (or being built)!
  • grishka 4y ago
    > The One True Way of building web applications To which I usually answer: I'm building a website. If I want an actual application, I don't consider hypertext with macros as a viable option.
  • qudat 4y ago
    “wildly simpler stacks” [citation needed]. With a framework like rails you still have a front-end and you still have to solve for interactivity — unless you’re building a rudimentary CRUD app. There are modern alternatives that attempt to hide the interactivity by baking it into html attributes via a DSL, but JS is still there. I would argue that a client-side only SPA is very simple from the lens of how it is deployed: drop the files in an S3 bucket. There’s no need for a server and from that perspective, an SPA is actually a simpler stack.
    • w-ll 4y ago
      Most of the web is just CRUD apps, be it php, rails, cgi calls, <your favorite language>. And no one is saying get rid of JS front end stuff, it should be used to enrich and not hinder. > drop the files in an S3 bucket If you have a completely static site you still shouldn't host of s3, that's a big no no. S3 isn't a CDN; you want a CloudFront or something else in front of that. But as soon as you need something more your gonna get lost or locked in.
      • arvinsim 4y ago
        > And no one is saying get rid of JS front end stuff, it should be used to enrich and not hinder. Having separation between the HTML on the server side and the JS on the frontend side is exactly why React become popular. Personally, I don't want to go back to the PHP+jQuery days. I want one language and one framework to handle both HTML and JS interactivity.
        • w-ll 4y ago
          > Having separation between the HTML on the server side and the JS on the frontend side is exactly why React become popular. But did they really. Cuz now i see .jsx files with sql calls, adding in static js and css, and logic with mixed html in... Its honestly blowing my mind how we got to this point. We all agreed biz logic, and view should be separated. and that html, css, js should also be in sperate files. and then .jsx or the like came along and merged them all back together in some of the ugliest code ive seen in years.
  • kitsunesoba 4y ago
    I've always felt that it was a bit of an odd decision to put all of one's eggs in a basket that you don't own or meaningfully control (the client). The client's basket will need to hold some of your eggs sometimes, that's unavoidable in some cases, but it makes perfect sense to put as many of your eggs in the basket you do control (your back end).
    • spion 4y ago
      I always felt the opposite was odd. Server side rendering felt like an odd hack due to the limitations of the platform. Imagine all you had was a PDF reader - then it would make sense to construct an application by building PDF files which contain links to other PDF files. But otherwise, why not write an actual client program that maintains its own UI state and have the server take care of what it does best - provide the data? Would you build a CLI (ncurses style or otherwise) application by fetching the TTY codes to render the current screen from a server for most user interactions?
      • kitsunesoba 4y ago
        That makes sense when the client is always a known quantity, but such is not the case with the web. While you can get an idea of what the majority of your target audience is running, there's always going to be some percentage that will be left out when writing client code for the majority browser only. There's always going to be client situations that you can't predict much less write for, and in those cases more server-heavy solutions tend to do better.
        • lolinder 4y ago
          Is a traditional desktop client really a better-known quantity than a web browser these days?
    • jmbwell 4y ago
      The more your app can run client-side, the lower your bills server-side.
  • fallous 4y ago
    The One True Way will always rise up and claim its victims, especially the inexperienced and/or naive amongst us. I sometimes think TOTW is actually an ancient one that thinks Cthulhu is an infant.
  • ay 4y ago
    I have an app which was built 10-ish years ago using C# and which I rewrote using rust - in almost no-JS, fully server-side style. (I somewhat factored out the web framework that I ended up with - https://github.com/ayourtch/rsp10 https://github.com/ayourtch/rsp10) After reading this article I sent it to a coworker “hey if I wait for another couple years the style this app is written in will be all the rage again :-)
  • quickthrower2 4y ago
    The SPA is definitely what you want i building an app like Google Sheets. The grey area where the pendulum might apply is in more line of businessy kind of apps: email client or online banking are examples. I think there is no pendulum though, there has just been a lot of choice in the last 10 years on all sides
    • batmansmk 4y ago
      Email client: Whether or not you wanted JS, your competitor works offline, retries better when connection is not good, persists emails without having to save, live refreshes emails when received, sends notifications, allows drag and drop to organize emails, autocomplete email addresses, works in SSO, have a nice text editor with spellchecking, autocomplete, bold and italic text. You lost. Banking: your competitor handles nicely dynamic forms, with helpful field validation, asking users just the right amount of questions based on what you entered previously, without changing page, with a go back button just working great. They also live refresh transactions, provide some nice clickable spending graphs, have a nice live dynamic wire confirmation system provide in-website live chat with your advisor. Their session doesn't expire every 15min for security reasons. You lost.
      • quickthrower2 4y ago
        Actually I really love the old fashioned cubemail type interface. Faster to load, more predictable interface where opening in another tab is a thing. I am rarely in a offline situation and if I am I connect a traditional email client that apple provides on my iphone anyway. Banking - again same kind of argument. Non JS infused apps have a certain solidness about them. I think it is the predictability. An interactive site will have whatever original UX innovations that team came up with. Case in point in HN you can paste arbitrary text into a comment without it fucking up. Impossible on Reddit! If I paste there the comment box is now forever fucked until I reload. I need to do the old notepad middleman trick. Your you lost comments are odd, it is horses for courses always.
        • batmansmk 4y ago
  • deepstack 4y ago
    >It's breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG/SSR-first solutions—to the degree that even the JS-framework-hotness-du-jour braintrust is going all-in on SSG/SSR. The pendulum swings large due to under-educated (and I don't only mean CS degree in school) developers, now days the industry is fill with developer wanna be jumping on the band wagon, many if not most are not really interested in software development. SPA was created to split up front-end/back-end development to cater to these new bee 'front-end' developers. That way the only thing they can screw up is the front end. The way how these Reactive app does thing, makes it easier to split that up. Front end is client/browser, backend API. It make sense from management point of view. It is stupid from a true software developer point of view. SPA also allow to control what user can and can not do. e.g: Link that doesn't allow user to open link in another page. SPA became so popular that w3 even made what so called web components to try to be like React. However, it is stupid to recreate browser rendering functionality in JS, and try to build desktop like apps in a document based system, even if V8 really made that fast by JIT compiling the JS. I do like the 2 way binding the vars. And if I'm going to us a reactive app, I would use Solid/Vue/Mithilral before I event touch React/Angular with 10 feet pole.
    • robertlagrant 4y ago
      It's not just that. Making one API that can be consumed by web and mobile was also a big part of it.
  • bigpeopleareold 4y ago
    I used to work on an single page application that was pretty complicated with heavy DOM updates. In the team, we wanted to investigate at the time if React could help us with some performance bottlenecks. However, I remember very much with that buy-in with JSX didn't appeal much to me. As we started to write more code against it, it was okay. On reflection though, I don't think React would have helped to solve the problems we thought we had. I only tried to see it as a solution to a problem, not seeking to use it to be part of a sub-industry around this library. But, even as I write this, I get a recruiter email asking for React experience. I have not followed it much for a few years, but using React now doesn't seem to fit the exact problem it tried to originally solve anymore (if that problem even matters now) but is a completely separate thing. But I really don't care anymore, because I don't work in any focused frontend web development now. I wrote something in plain JS a couple of weeks ago, up to a point where it was generally useful for myself for my work. It was wonderful - no crazy complex toolchain, no React to deal with, just html and some JS to do stuff. Doing the simplest thing in a new project (no extraneous toolchains if you can help it specifically) should be the first thing to do. This is not a fad, it's just taking stock in the time you have to make usable programs.
    • robertlagrant 4y ago
      I love that some of us are all having a similar experience at the same time. I'm writing something small and I just include an htmx script tag at the top of the file and get going. It's amazing how fast something is when it's just selecting exactly what it needs from the DB and sending prerendered html to the browser.
  • theplumber 4y ago
    SPA has been web's response to native mobile apps.
  • lkxijlewlf 4y ago
    > I'm still a bit steamed from being gaslit all throughout the mid-2010s years when we were told <div id="root"></div> + SPA was The One True Way of building web applications. Cult-like behavior with a healthy dash of resume driven development. All it is. They tend to be the loudest people in the room and so then management says, okay, do this.
  • ehnto 4y ago
    I think what can make some of the rhetoric around it all seem so surprising and frustrating, is because many of the proponents started their careers with the paradigm already shifted toward frontend SPAs. I started my career with the paradigm shifted toward backend templating frameworks, and when SPAs came around I remember seeing some of the old-hats with the same surprise articles like this exhibit, as we had never experienced GUI frameworks before, where they had.
• nasmorn 4y ago
  The worst offenders are shitty SPAs that have less UI responsiveness than a good old school app. They are simply built because the new devs don’t know anything else. My favorite is Circle CI where they don’t even rate Limit the run button and the response from the server takes 5s. It’s the worst of all worlds
  • latchkey 4y ago
    Not sure if it is still the case, but Circle used Clojure/Om [1]... when I heard them say they did that so many years ago, I knew right away it would end up being something nobody wanted to work on. Sure enough, just checked, Om was abandoned [2] and the person blogging about how great everything was is long gone [3]. This is the absolute definition of tech debt. [1] https://circleci.com/blog/how-circleci-processes-4-5-million-builds-per-month/ https://circleci.com/blog/how-circleci-processes-4-5-million... [2] https://github.com/omcljs/om https://github.com/omcljs/om [3] https://circleci.com/blog/why-we-use-om-and-why-were-excited-for-om-next/ https://circleci.com/blog/why-we-use-om-and-why-were-excited...
    • valbaca 4y ago
      If the project is completely abandoned, sounds more like tech bankruptcy rather than tech debt.
    • yawaramin 4y ago
      > and the person blogging about how great everything was is long gone Umm, she left CircleCI last year after a 6-year stint. That's not exactly 'long gone'.
    • didibus 4y ago
      I'm not sure what's the point you're making? It seems like their UI is using next.js now and apparently it still has issues as per OP complaining about the run button behavior. Frontend frameworks often get abandoned: jQuery, backbone, ember, angular, etc. Seems to just be how things goes on the front end. This plagues not only the web, desktop and mobile frontend frameworks also all seem to come and go.
    • 4y ago
• andrewstuart 4y ago
  Scott Hanselman says "use the technology that makes you happy".
  • Syonyk 4y ago
    I'm not sure I agree with that in the slightest, given the way the tech industry has gone with software sizes/complexity/etc. I fundamentally use computers to do the same things I did in the late 90s - IRC, chat, some web browsing, development, etc. And due to things like Electron, a quad or hex core system with 4GB RAM struggles with a lot of these things now. The result of that is an awful lot of ewaste, as machines that were perfectly able to do things when they were released lose that ability as the complexity of software goes up - for not that many new features, really. AIM back in the 90s fit on a floppy, Element is a bloated pig that mostly does the same thing - chat with people. At least there are some native clients. I think we should require developers to use gutless wonders once a week, instead of "Well, it works fine on my 16 core Xeon with 48GB RAM!"
    • astrange 4y ago
      The weight of Electron apps is an interesting contrast with any thread about garbage collection/PL theory, where by far the common opinion is that GC languages are the most performant language, only way to go and the only reason to do anything else is that you're a cowboy who hates memory safety.
  • deleted 4y ago
    [deleted]
• Syonyk 4y ago
  > For starters: a lot can be done natively nowadays I learned this recently on my personal site when I was going through and de-javascripting stuff. I more and more frequently run without scripting enabled, and it felt very wrong that my personal site had some JS requirements. The worst being that it wouldn't render without JS due to a slick little fade-in effect in the template... One of the things I do quite like (living on a low bandwidth connection a lot of the time) is lazy loading - and it turns out that you can do that without JS too, now, at least in modern browsers. img loading="{lazy,eager}" will do this without needing JS. Combine it with picturesets for smaller images (you let the browser pick an image it supports and a size relevant to the display), and life is good without any JS. At this point, as far as I know, the only things on my site that require JS are the "Make the image bigger when you click on it" feature, and then a JS based search function (which sucks down an awful lot of JSON, but it's fine, and beats an active server backend for a personal blog). It's also impressive just how responsive a browser on a gutless wonder ARM SBC is when all it's having to do is render content, not run a bunch of JS!
  • zzo38computer 4y ago
    Lazy loading could also be made as a user option in a web browser, too. (An implementation could also have an option to only use lazy loading if the dimensions of the picture are known.) "Make the image bigger when you click on it" also can be done without JavaScripts, in a few ways: One way is to just use a ordinary hyperlink directly to the image (and optionally you can override it if JavaScripts are enabled), another way is to just to use features that the web browser might have (if the user has them, they can be used; if not, then not), and a third way might be to use CSS (although I generally want to avoid CSS requirements, too). Fade-in effects can also be done using CSS, but may be undesirable (I am one who would prefer to reduce animation as much as possible, and other users too). For JS based search functions with JSON, you could do something that I mentioned before which is <link rel="data"> and the user can make their own search functions if wanted (maybe a browser or extension might have a JSON searching function with many options (that the web page might not necessarily implement; I do often find wanted to make queries that the web page does not implement)), but if JavaScripts are enabled then it will use that one. Even if the data is rendered into HTML in server-side scripts or generated static pages, you can still have <link rel="data"> or <a rel="data"> to allow to access the raw data, too, since it will sometimes be useful. But in any case, you should almost always ensure that it works properly with JavaScripts disabled, and usually should work with CSS disabled too. Use <noscript> blocks if needed, and include API documentation or download links or whatever, not simply "This requires JavaScripts to work". For some types of web apps (e.g. interactive games), it might require JavaScripts but even then you can include links to documentation, and if it is open-source also source codes, even if scripts are disabled. In general, in my opinion, most web pages should need neither JavaScripts nor CSS (and often does not need pictures either).
• krono 4y ago
  http://vanilla-js.com/ http://vanilla-js.com/ Criminally underrated, bit of a hidden gem I suppose!
  • russtrotter 4y ago
    haha! glad somebody linked this! i love how the site presents itself just as any "framework" would :-) well-played vanilla-js
    • krono 4y ago
      The 0 bytes download no matter what extra's you check in is also a nice touch heh
• gigel82 4y ago
  Oh, I thought this was going to talk about low.js (https://github.com/neonious/lowjs https://github.com/neonious/lowjs), the "node.js" runtime for micro-controllers and tiny embedded systems.
• Ocha 4y ago
  I tried to solve this problem for last two projects I worked on. Ended up using Rails that rendered Vue components with data already passed in the generated html. It works really well: adding new components or iterating over existing ones is super easy, nothing is brittle, UI/UX fidelity is great and very easy to implement, minimal to no API calls (depending on what components I have on the page). Rails views are smaller and much easier to refactor too.
  • hu3 4y ago
    Do you have any example? Even a minimal non-working PoC would make my day. I've been dying to implement Vue component responses for my projects ever since I first heard about it because I believe that this is a way to keep things mostly on the backend while still preventing JS spaghetti on the frontend. I read about https://inertiajs.com/ https://inertiajs.com/ but it seems too overkill. I'd prefer to keep things simpler.
    • benblue 4y ago
      For a greenfield project I'd probably reach for Inertia.js though I don't have any experience with it aside from reading the docs. If you just want to use Vue for your rendering layer, you can can do that using a very minimal partial that renders the root element and loads the JS to mount the component. This example should get you started (Vue 2 syntax): https://gist.github.com/yourboyblue/834aac9c427a97037dd49694a25f8199 https://gist.github.com/yourboyblue/834aac9c427a97037dd49694...
    • Ocha 4y ago
      You can see working version on app.mailsnag.com. I will try to make a sample project out of it and put on GitHub tomorrow and share the link.
      • dane-pgp 4y ago
        Any progress you can share on that sample project?
  • theomega3 4y ago
• LAC-Tech 4y ago
  Is there a standalone way of preventing the white flash of a full page load when you navigate to another URL in an SSR app? Or are they all tied to pretty big backend frameworks like RoR?
  • kall 4y ago
    What browser does that? Don't they usually stay on the same page while it loads and then switch right to the nw one?
  • marginalia_nu 4y ago
    White flashes are usually a loading issue, like too much crap in the <head>-tag, or some critical resources aren't loading as early as they should.
  • robgibbons 4y ago
    You could use something like Hotwired Turbo. Personally I'm not a huge fan, but it easily turns "traditional" web apps into SPA-like experiences. Under the hood, it does full page requests, but then calculates a diff and only renders parts of the page that have changed.
  • jon_n 4y ago
    https://web.dev/app-shell-ux-with-service-workers/ https://web.dev/app-shell-ux-with-service-workers/
  • tqkxzugoaupvwqr 4y ago
    Navigated on a dark website in Safari, Firefox and Chrome and couldn’t reproduce the issue. When I click on a link, the browser loads the page and when it’s ready the displayed page switches to the newly loaded one without a white flash. Should you encounter white flashes, try preloading likely next clicks (e.g. next page, or first search result, or where the mouse cursor hovers 200 ms over a link) with `<link rel="prefetch" href="theurl">`[1]. Make sure your HTTP response headers contain caching instructions, otherwise prefetched pages are requested immediately again by some browsers. [1] https://developer.mozilla.org/en-US/docs/Glossary/Prefetch https://developer.mozilla.org/en-US/docs/Glossary/Prefetch
• tgb 4y ago
  So how embarrassed should I be for using Vue for small, static websites? I made a results page for some data my colleagues and I processed and there’sa bunch of categories. So there’s a selector and you pick one and Vue updates the page to show the data for that. It’s deployed to GitHub pages and the data is static so no server needed. I could have made it server side rendered and done all 500 different pages ahead of time and gotten faster load times and supported JS disabled browsing. But Vue is what I knew so I didn’t. I’m not a web developer, I just wanted to make a site. So have I sold my soul?
  • CharlesW 4y ago
    > So how embarrassed should I be for using Vue for small, static websites? Not at all, and don't let anyone tell you differently.
  • MaxBarraclough 4y ago
    Using Vue is a long way from selling your soul -- if you want to make a bloated monstrosity of a website, you have to do far more than just use Vue. That said I think it's a pity if a static website doesn't work at all without JavaScript.
  • dgb23 4y ago
    That seems like a fantastic use case for DIHYW (do it however you want).
  • grayrest 4y ago
    If you solved your problem then it's not a big deal. The web isn't that old and has been in constant churn. The signal for a shift in what's popular starts with articles like this one or the two dozen others I've seen with this same take. Over the next two years or so the zeitgeist will move into competing solutions, one will "win" and that'll propagate to later adopters as the new norm. At least that's how it's worked for *SP, Rails, jQuery, Backbone, and React. The current era has been unusually long/stable so it's likely that younger developers haven't run into the situation. If you do want to jump on the trend while keeping your Vue knowledge, check out Astro [1]. I'm provisionally in the Marko [2] camp, not so much for the current Marko but because Marko 6 is looking good. [1] https://astro.build/ https://astro.build/ [2] https://markojs.com/ https://markojs.com/
• true_religion 4y ago
  I was anti-SPAs until I started living permanently on a 2G connection. Now I love the few that I use. They cache a lot of data, lazy load almost everything, and renders are much faster. Also, best of all, the experience when my internet goes down—which is often—is at least a partially functional page, instead of a total blank screen which is what HN and other sites that deliver full HTML or nothing gives me. I cannot count the number of times I have lost a long well-typed comment on HN, because my internet went down while sending it and my browser apparently considers that to not be situation that it can reload the page on using the data it was going to send. I think SPA's work better on low-data lines because they are apps and work just like other phone apps.
  • hu3 4y ago
    The problem is that is doing SPA right is hard. This is the SPA frontpage of my newest client: https://i.imgur.com/7fbE4BH.png https://i.imgur.com/7fbE4BH.png And their frontend devs are proud of their achievement. Apparently it used to be worse.
    • madeofpalk 4y ago
      This is Gatsby, no? Gatsby is a static site generator?
      • hu3 4y ago
        It's Gatsby yes. For a static frontpage. I just started consulting for them on another project so I'm light on details.
      • andrei_says_ 4y ago
        Gatsby… The static site generator which uses React to … render the static site? I was thinking of trying it out but when I read about its architecture could not believe that such a thing may be real. Middleman and 11ty for me.
    • robertoandred 4y ago
      Nothing in your screenshot suggests that the site being an SPA is responsible for the download size.
• dgb23 4y ago
  Great article! It clearly shows the tradeoffs and isn't afraid of stating personal preferences where applicable. IMO there are a bunch of rules of thumb and use cases for choosing something like htmx (great library, I've been using it more and more) as opposed to something like React or a React based library or web components and so on (much more powerful but comes with a cost). - Progressive enhancement of a mostly static site. - Most interactions need to query the backend (or hit a cache) - typical for DB heavy sites. (Seems to be the case here.) - You have a fast backend and/or it doesn't make too much sense to offload computation to the client. - You don't have the expertise/willingness/requirements to implement advanced and/or bespoke interactive UI features AKA your UI is KISS. (Like the ones mentioned in the article.) - Your template/component library you use on the server is similarly productive and composable (was _not_ the case 10-8y ago IMO). - You don't need integration with something like Storybook or Workspaces to develop and test components in isolation. - You don't know if some of the above are true, but the way you develop your UI can be more or less easily extended or ported to a more frontend heavy solution without creating a JS spaghetti mess and spreading frontend logic across client and server. There are probably few more? But the general point is: Use the right tool for the job.
  • nawgz 4y ago
    > - You don't need integration with something like Storybook or Workspaces to develop and test components in isolation. You never needed this. Those things are pure bloat. If you're building React components... build a static CRA app out of those components. Voila, you have real-world React examples, no Storybook garbage creeping in, no 3minute compile times just to find you didn't configure their stupid webpack setup to actually catch your TS errors, just the literal environment you'll use them in perfectly ready to go Otherwise, I don't strongly disagree, I think that this point is the real key to all these non-framework libraries though: > - You don't have the expertise/willingness/requirements to implement advanced and/or bespoke interactive UI features AKA your UI is KISS. (Like the ones mentioned in the article.) I can promise you people like optimistic app behavior when you write it well. And that's not possible with backend rendering.
    • presentation 4y ago
• jacobsenscott 4y ago
  This is great. I really hope using the architectures, tools and frameworks sh*t out by the FAANG companies will become generally recognized as an "anti-pattern", rather than the "3133t new way to build apps!". It happened before, with the move from the j2ee nightmare to rails. It appears to be happening again from the js nightmare to ... rails.
• tomatowurst 4y ago
  Absolutely refreshing to read and I feel that many of us are fed up with the 2015 approach, two codebases, with much of the woes coming from the frontend. I'm super relieved to see that many of us are beginning to see the emperor without clothes.
• bufferoverflow 4y ago
  Serving HTML doesn't make sense. Serving data and rendering it client side is the reasonable solution. Author makes a mistake of mentioning dealing with GraphQL and getting and serving a bunch of unnecessary data. And then he completely ignores this, and keeps blaming single-page apps for his failure.
  • oblak 4y ago
    Look, we all need to vent sometimes. I can certainly agree with this for "apps" but there's a lot on the web that should be accessible without js because it's just static content. If you haven't noticed, HN is working perfectly fine without js, which is how I've been using it.
    • bufferoverflow 4y ago
      Why should a lot of the web be accessible without JS? You're basing your view of the industry on some very rare exceptions, and most of them voluntary, not due to the limitations of their software or hardware. Why should I cater to luddites? > HN is working perfectly fine without js I guess we have different definitions of fine.
      • Delk 4y ago
        > Why should I cater to luddites? Why should a particular way of doing things be automatically considered better just because it's new, to the point of calling people names if they don't agree? Why should superfluous or more complex tooling be advocated for cases where simpler ones would do? SPAs and large amounts of interactivity are completely fine for applications or highly interactive pages. But when I check my local weather website, most of the time I just want to see the weather forecast or perhaps the latest observation. I don't need an application. Yet the site insists on first loading the page and then loading the forecast with a script, and then lazy-loading the observation data only if I scroll down to it. Getting the forecast takes a second or two from starting to load the page, and getting the observation data visible takes several, even on a fast connection. If it were a simple web page, with some scripting to replace content if I click for a different day's forecast, the entire data would probably be visible in less than a second. There are other examples I've seen where the contents are entirely static but which are nevertheless implemented as literal SPAs despite there being little benefit from interactivity. Some of those sites aren't heavyweight or slow, but some of them require you to click through to information that you used to be able to access directly with a bookmark or link because what used to be a separate static page is now dynamically loaded when you click yourself through to the information in the "application" instead. (A sports club I go to does that for its training schedule.) Those are design or implementation issues that can be solved, of course. It's possible to make script-heavy pages non-glacial. It's possible to make specific content in a SPA linkable. It's possible to not have browser history behave in some kind of a weird way. But those can take some effort to implement whereas simple static pages would have those mostly as a given. I don't disable js but I see little point in using complex or tools for cases where simple ones would do. There are clear benefits from heavy use of javascript for application-style sites, of course, but not all sites are like that.
• hunterb123 4y ago
  So mo lo. No, we're lo so mo. No no wait, lo mo so.
• rascul 4y ago
  > most of it (read requests) is safe to preload on mouse down and then navigate as usual on mouse up. Since the click takes 100ms+ this makes navigation feel instant. This is an interesting idea I had not thought of or (knowingly) seen. Is it widely implemented? What are the pros and cons?
• deleted 4y ago
  [deleted]
• donatj 4y ago
  This is still in a lot of the PHP community builds essentially. PHP + A little bit of enhancement with JavaScript is in my opinion almost unbeatable in productivity and raw speed.
  • girvo 4y ago
    In fact, you can do some quite neat things with V8js, like rendering a React component server-side with already-loaded data and embed the resulting HTML into your response (which still booted a regular React component on top of it afterwards for interactivity/enhancement once its in the browser)
  • deleted 4y ago
    [deleted]
• ttflee 4y ago
  There is nothing could not be solved by adding another layer of abstraction, except for too many layers of abstraction.
• snowl 4y ago
  So the original issue essentially stemmed from you requesting a lot of data that you didn't need, causing requests to be very slow, and then switching to rails caused your requests to be fast? Wow, I'm really sure that's react's fault!
  • maxloh 4y ago
    Replace GraphQL with a hand written RESTful API should solve most of their issues.
• dimgl 4y ago
  Here am I just using React with no issues :shrug:
  • progx 4y ago
    And did you finish your todo-app?
    • dimgl 4y ago
      I didn't realize the UI I designed for Gremlin was a TODO app. https://www.gremlin.com/ https://www.gremlin.com/ I made it in 2017 and it's still in use today.
• capn_duck 4y ago
  I for one am very excited to see what happens with the Hyperfiddle/Photon project that made the front page the other day. https://hyperfiddle.notion.site/Reactive-Clojure-You-don-t-need-a-web-framework-you-need-a-web-language-44b5bfa526be4af282863f34fa1cfffc https://hyperfiddle.notion.site/Reactive-Clojure-You-don-t-n... I am in the same boat as OP. Started doing web things right around the growth of rails, but spent plenty of time in my career doing Spring MVC apps. For the last 6 years or so I've been forced to build SPA's because its what's been mandated from on high, but it's to the point where I can't even explain to new devs coming in what they're missing. They can't understand how much easier it is to just make a query directly to a database while responding to a request than it is to concern yourself with explicit API calls onMount of some component. Rehydration, state management, blah. What are we even trying to solve anymore. I'm excited by the new trend in a sort of hybrid approach where you write your code as if it all runs on the server, and the framework figures out the websocket communications that need to take place. Phoenix Livewiew, PHP Livewire, even Microsoft Blazor server. This is all admirable, but I think the hyperfiddle/photon solution is finally the right level of abstraction. It's sort of like when you start programming and try to write a parser with a bunch of if statements and it becomes a mess, then you realize that mathematicians figured all this stuff out in a really elegant way that composes and provides just a solid bedrock. We need that level of formality to get us out of the SPA/SSR tarpit.
  • willlma 4y ago
    > then you realize that mathematicians figured all this stuff out in a really elegant way that composes and provides just a solid bedrock. Can you expand on what mathematicians discovered and how it can be applied to coding? Or does it require a certain programming language? I'm looking at the Hyperfiddle website and trying to understand how these concepts are connected. Thanks!
    • dustingetz 4y ago
      He's basically paraphrasing Greenspun's Tenth Rule: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Photon has, by construction, proven that it is possible to define fullstack web UIs as pure functional expressions despite crossing the client/server boundary, and this is done without adding in all that extra "React.js-era web framework stuff" (the travesty being discussed in this larger thread), instead using only the composition semantics of lambda that were established many decades ago. The best explanation of that is this 10 minute talk: https://news.ycombinator.com/item?id=31217448 https://news.ycombinator.com/item?id=31217448
• spion 4y ago
  I think we need a (semi-)realistic benchmark / example program to talk about these things. There are basic stuff that just plain don't work with most "low-JS" solutions. Like for example, building a complex form with interdependent validation and state (depending on the value of a dropdown, different parts of the form will appear, at multiple levels). I'm not sure why we keep insisting that we can build rich client applications with what is essentially a configuration language. Now Phoenix live view (with a sprinkle of web components) on the other hand... that's a different story.
• synergy20 4y ago
  it really depends on your application, for a site like Rails, Django yes htmx makes sense. One of the key complaints from the blog is GraphQL (too may requests wasted), in that case, SSR might make sense as well. Other cases, e.g. a normal RESTful backend, or a JSON-RPC backend, or the API-based services, SPA fits well IMO. Sometimes you don't do full-stack, i.e. you don't control the backend and all you have is the API, sometimes you want to make backend simple(just spit out data), a lot of low-end devices can not even do heavy duty SSR(embedded devices), all these cases a SPA makes sense to me. For me React and Angular are harder to learn than Vue, and I don't do enterprise complex SPA anyways, my choice is Vue when SPA is the right choice.
• sunfmin 4y ago
  https://docs.goplaid.dev https://docs.goplaid.dev completely embrace low-JS in the Go world, you can write pretty complex UI interactions without write a single line of JavaScript, but only Go code. It also integrate heavy duty UI component library like Vuetify, So you can use it easily in Go code. It even go further to have presets that help you easily build Admin UI with much flexibility. https://docs.goplaid.dev/samples/presets-detail-page-cards/customers https://docs.goplaid.dev/samples/presets-detail-page-cards/c...
• kgbcia 4y ago
  htmx hits a sweet spot of being unintrusive. react creates a virtual dom and managing state. my database manages state, i just want ajax so the whole page doesn't refresh. maybe the best solution is if the browser does the diff and only updates what is required across response
• peanut_worm 4y ago
  I never really thought the benefits of SPA apps were worth the trouble they cause. Hypothetically, you can account for all the inherent issues of a SPA app but you have to pretty much reinvent the wheel to achieve it. Modern HTML and vanilla JavaScript are pretty good. I really think the optimal website is plain HTML and bits of JS sprinkled in as modules to add interactivity where needed. I think that the front end web dev community needs to just agree on a good pattern to use that doesn't involve a convoluted library or framework.
• rntksi 4y ago
  I agree with everything the author wrote.
• steve_taylor 4y ago
  From htmx.org: > htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML That sounds a lot like AngularJS (i.e. v1). It got its name from HTML tags being angular, implying that things previously done in JavaScript could now be done with something resembling HTML. We all know how that worked out.
  • robertlagrant 4y ago
    It's not really like that at all. I'd look a little deeper than that.
  • recursivedoubts 4y ago
    htmx is an extension of HTML as a hypermedia completely different model and in line with the original model of the original REST-ful web architecture in a way that angular was not: https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/
• atoav 4y ago
  In my eyes there is a whole class of pages that can easily pull off a static-page-with-sprinkles-of-js approach. And for any page within that class it is probably the best way to do it by far. It is blazingly fast, it has as few moving parts as needed, while the moving parts are highly standard, need few to no updates and will very likely work in 10 years time. It is safe as heck, because there is no web facing backend anybody could hack. With the right static site generator you have a propper backend-editor as well, so comfort is not needlessly suffering. Anything more complex, with accounts, logins etc is of course a different class of pages.
• aaronbrethorst 4y ago
  Ssh, don’t spill the beans! I love competing against companies building these rickety SPA boat anchors. These SPAs almost always end up feeling slower, buggier, and just plain weirder than a Rails app using SSR and Turbo.
  • crowdyriver 4y ago
    Some of my competitors use React, and frankly, couldn't be happier. Easier to outcompete them!
• CraigJPerry 4y ago
  I’m test driving HTMX just for fun right now. I like: 1. No js build tooling stack needed (although since vite came along, i’m less annoyed with the typical js dev pipeline) 2. The documentation site is very usable Things i don’t know about yet: 1. How do you test htmx behaviours and components i’ve made without going full e2e (easy to make slow and brittle) - ideally I don’t really want to spin up my whole web app stack just to build out a dynamic table component 1. Can you get linting or intellisense setup? I just want some warnings in my editor for bad usage 1. How do you make sure you’re not leaving cruft behind in the DOM? Right now i’m manually checking I haven’t accidentally left dom nodes behind through my mistaken use of hx-swap 1. It’s not clear to me how to update other hx- decorated items on the page. E.g. if i need to update the id field in a link, how would i do that without resorting to a bunch of js? 1. Hyperscript looks neat but i can’t help balk at 100kb-ish dependency just to give up access to convenient js dev tooling like the chrome debugger etc.
  • robertlagrant 4y ago
    > how would i do that without resorting to a bunch of js I think you probably would have to. Updating a bit of the DOM directly - if you really need to do this - sounds like a job for something like alpine.js, which apparently pairs nicely with HTMX. I'm trying to make a site that's just pure HTMX though, to see how it turns out.
    • CraigJPerry 4y ago
      >> I'm trying to make a site that's just pure HTMX though, to see how it turns out I’m in exactly the same boat, i’m (maybe unrealistically) trying to avoid using anything but htmx https://github.com/craigjperry2/mingo https://github.com/craigjperry2/mingo
• rkangel 4y ago
  This is exactly the thinking behind Phoenix LiveView, except that I'd argue that it's even easier in that case. You write an app the looks like a normal server-rendered HTML page, but having served the page it then opens a websocket connection to the server, down which UI events are sent and HTML updates come back the other way. Add in a little AlpineJS to do basic client side interactivity (show/hide something, flick between tabs etc.) and you have a rich interactive app, that works responsively and requires almost no JS. It's also much easier to test the whole system. The main downside to SPA is that it's not quite as well set up to do major UI stuff without going via the server. It's not the right tool for offline apps, or things like that. But for UI updates where the SPA has to query data from the server it's exactly the same and often sends less data because it only sends what it needs to (the HTML diffing and compression is very efficient).
• jmartin2683 4y ago
  I’m glad that I pretty much skipped the entire SPA era and now no longer have to write front end code very often.
• winwiz 4y ago
  The supposed complexity of SPA can be addressed by splitting a monolithic React app into multiple SPAs each rendered by its own and smaller script bundle. It helps with SPA loading performance as well. E.g. an app can have Login SPA, Main SPA, Reporting SPA, Audit SPA etc. Additionally prerender the index/loading page of SPA at build-time to improve loading performance even further. For many (but not all) websites the resulting performance would be the best it can ever get. Crisp React facilitates both splitting and prerendering.
• rglover 4y ago
  This is exactly why I’m building Joystick (full-stack, UI framework + Node backend, full SSR out of the box—think Meteor w/o data bottlenecks and dependency traps). JavaScript doesn’t have to be a nightmare: https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick.
• cutler 4y ago
  It's not hip on HN to praise Facebook but React revolutionised front-end dev with salaries now on a par with back-end Java/C# and often higher. I also really love how Facebook was born in a student dorm whilst giving the finger to the overprivileged Winklevoss twins. Priceless.
• kiawe_fire 4y ago
  As someone who feels liberated when using {reactive framework}, and very much constrained when using {low-js-dom-manipulation framework}, there’s one aspect I keep seeing repeated that is a great misdiagnosis, IMO. Which is this notion that somehow the backend has to be extra complicated or slow or somehow worse off when using a fancy reactive framework. Indeed, one of the selling points of tools in the Laravel / PHP space is that “you don’t need to build an API” and can “just have normal controllers returning views”. But this mindset takes several disparate things (the backend’s complexity, the amount of data it returns, the data format returned by the back end, and how the frontend works) and basically combines them into some mutually exclusive set of decisions. But they aren’t. At least not the way most people talk about them. Whether your server returns a blob of JSON or a blob of HTML should have absolutely no bearing on the complexities or capabilities of your back end. If it does, then you’re probably coupling your back end work too tightly to its presentation, which will cause you pain eventually, no matter how your front end works. But people have this notion that if you use a reactive framework that calls the back end, the back end not only has to return JSON, but it also needs to be this ideologically pure REST API that returns all the things you will ever need for the given objects being requested. Or that you need to build some complicated GraphQL model abstractions. You don’t. If you previously had a route that returned the user’s full profile including their long Naruto fan fiction they posted when they were 13 years old when you only really needed the user’s name and profile pic, then you don’t have to switch to a full HTML page render to fix this. Just return what you need, but in JSON form. And by doing this, you gain flexibility on the front end to use whatever framework you want, the ability to re-use these same routes for multiple clients like mobile apps (because if a page on the web only needs the user’s name and profile pic, then that’s probably all that the app needs when loading that route too!) People seem to think that having a reactive framework calling an API means that you have to have a pure REST API, and that a REST API necessitates a crappy back end experience that returns the monkey, banana and entire jungle at once. And then when they go back to {html-render with lite JS framework} they get to throw caution to the wind, write single use queries and page specific routes and suddenly anything and everything goes on the backend. Either way, you need discipline and discretion on the back end. If you go straight HTML renders, you still want to have proper separation of concerns and reusable queries and lightweight controllers that don’t really care whether they are returning HTML or JSON or Bob’s Bit-flipped Binary Blobs. And if you go for a reactive framework, you STILL want all of the above on your back end, but you also still need thoughtful route design that returns what you need for the thing you’re doing, and not much more. It’s not all or nothing either way, but if you approach it like that, you will feel pain. Yes, even with plain old HTML.
• psandor 4y ago
  This is exactly how most web applications were written 15 years ago. Server side rendering with PHP, ASP, JSP, and then Javascript for the interactive bits.