TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

I fell in love with low-JS

429 pointsby im_darioabout 3 years ago

39 comments

jaredcwhiteabout 3 years ago
It&#x27;s breathtaking to see the pendulum swing so obviously and definitively back in favor towards HTML-first and SSG&#x2F;SSR-first solutions—to the degree that even the JS-framework-hotness-du-jour braintrust is going all-in on SSG&#x2F;SSR.<p>I&#x27;m still a bit steamed from being gaslit all throughout the mid-2010s years when we were told &lt;div id=&quot;root&quot;&gt;&lt;&#x2F;div&gt; + 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.
评论 #31266171 未加载
评论 #31266490 未加载
评论 #31266644 未加载
评论 #31266448 未加载
评论 #31255985 未加载
评论 #31266404 未加载
评论 #31270698 未加载
评论 #31270649 未加载
评论 #31267363 未加载
评论 #31271147 未加载
评论 #31265784 未加载
评论 #31268410 未加载
评论 #31268043 未加载
评论 #31268563 未加载
评论 #31273914 未加载
评论 #31270565 未加载
评论 #31273029 未加载
评论 #31270323 未加载
评论 #31271482 未加载
评论 #31268118 未加载
true_religionabout 3 years ago
I was anti-SPAs until I started living permanently on a 2G connection. Now I love the few that I use.<p>They cache <i>a lot</i> 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.<p>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.<p>I think SPA&#x27;s work better on low-data lines because they are apps and work just like other phone apps.
评论 #31270174 未加载
评论 #31266803 未加载
评论 #31271524 未加载
评论 #31268143 未加载
评论 #31272771 未加载
评论 #31271981 未加载
评论 #31268490 未加载
Syonykabout 3 years ago
&gt; <i>For starters: a lot can be done natively nowadays</i><p>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&#x27;t render without JS due to a slick little fade-in effect in the template...<p>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 <i>that</i> without JS too, now, at least in modern browsers.<p>img loading=&quot;{lazy,eager}&quot; 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.<p>At this point, as far as I know, the only things on my site that <i>require</i> JS are the &quot;Make the image bigger when you click on it&quot; feature, and then a JS based search function (which sucks down an awful lot of JSON, but it&#x27;s fine, and beats an active server backend for a personal blog).<p>It&#x27;s also impressive just how responsive a browser on a gutless wonder ARM SBC is when all it&#x27;s having to do is render content, not run a bunch of JS!
评论 #31266001 未加载
评论 #31265808 未加载
评论 #31269530 未加载
评论 #31268399 未加载
评论 #31274778 未加载
评论 #31266532 未加载
dgb23about 3 years ago
Great article! It clearly shows the tradeoffs and isn&#x27;t afraid of stating personal preferences where applicable.<p>IMO there are a bunch of rules of thumb and use cases for choosing something like htmx (great library, I&#x27;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).<p>- Progressive enhancement of a mostly static site.<p>- Most interactions need to query the backend (or hit a cache) - typical for DB heavy sites. (Seems to be the case here.)<p>- You have a fast backend and&#x2F;or it doesn&#x27;t make too much sense to offload computation to the client.<p>- You don&#x27;t have the expertise&#x2F;willingness&#x2F;requirements to implement advanced and&#x2F;or bespoke interactive UI features AKA your UI is KISS. (Like the ones mentioned in the article.)<p>- Your template&#x2F;component library you use on the server is similarly productive and composable (was _not_ the case 10-8y ago IMO).<p>- You don&#x27;t need integration with something like Storybook or Workspaces to develop and test components in isolation.<p>- You don&#x27;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.<p>There are probably few more? But the general point is: Use the right tool for the job.
评论 #31266783 未加载
评论 #31272873 未加载
nasmornabout 3 years 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
评论 #31265696 未加载
capn_duckabout 3 years ago
I for one am very excited to see what happens with the Hyperfiddle&#x2F;Photon project that made the front page the other day.<p><a href="https:&#x2F;&#x2F;hyperfiddle.notion.site&#x2F;Reactive-Clojure-You-don-t-need-a-web-framework-you-need-a-web-language-44b5bfa526be4af282863f34fa1cfffc" rel="nofollow">https:&#x2F;&#x2F;hyperfiddle.notion.site&#x2F;Reactive-Clojure-You-don-t-n...</a><p>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&#x27;ve been forced to build SPA&#x27;s because its what&#x27;s been mandated from on high, but it&#x27;s to the point where I can&#x27;t even explain to new devs coming in what they&#x27;re missing. They can&#x27;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.<p>I&#x27;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&#x2F;photon solution is finally the right level of abstraction. It&#x27;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&#x2F;SSR tarpit.
评论 #31277091 未加载
spionabout 3 years ago
I think we need a (semi-)realistic benchmark &#x2F; example program to talk about these things.<p>There are basic stuff that just plain don&#x27;t work with most &quot;low-JS&quot; 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).<p>I&#x27;m not sure why we keep insisting that we can build rich client applications with what is essentially a configuration language.<p>Now Phoenix live view (with a sprinkle of web components) on the other hand... that&#x27;s a different story.
snowlabout 3 years ago
So the original issue essentially stemmed from you requesting a lot of data that you didn&#x27;t need, causing requests to be very slow, and then switching to rails caused your requests to be fast? Wow, I&#x27;m really sure that&#x27;s react&#x27;s fault!
评论 #31269900 未加载
Ochaabout 3 years 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.<p>It works really well: adding new components or iterating over existing ones is super easy, nothing is brittle, UI&#x2F;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.
评论 #31266142 未加载
评论 #31267002 未加载
评论 #31268656 未加载
评论 #31268102 未加载
评论 #31266499 未加载
评论 #31266265 未加载
kronoabout 3 years ago
<a href="http:&#x2F;&#x2F;vanilla-js.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;vanilla-js.com&#x2F;</a><p>Criminally underrated, bit of a hidden gem I suppose!
评论 #31266599 未加载
rkangelabout 3 years ago
This is exactly the thinking behind Phoenix LiveView, except that I&#x27;d argue that it&#x27;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.<p>Add in a little AlpineJS to do basic client side interactivity (show&#x2F;hide something, flick between tabs etc.) and you have a rich interactive app, that works responsively and requires almost no JS. It&#x27;s also much easier to test the whole system.<p>The main downside to SPA is that it&#x27;s not quite as well set up to do major UI stuff without going via the server. It&#x27;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&#x27;s exactly the same and often sends <i>less</i> data because it only sends what it needs to (the HTML diffing and compression is very efficient).
tgbabout 3 years 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?
评论 #31266528 未加载
评论 #31266443 未加载
评论 #31266488 未加载
评论 #31277353 未加载
jacobsenscottabout 3 years 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 &quot;anti-pattern&quot;, rather than the &quot;3133t new way to build apps!&quot;. It happened before, with the move from the j2ee nightmare to rails. It appears to be happening again from the js nightmare to ... rails.
sunfminabout 3 years ago
<a href="https:&#x2F;&#x2F;docs.goplaid.dev" rel="nofollow">https:&#x2F;&#x2F;docs.goplaid.dev</a> 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.<p>It also integrate heavy duty UI component library like Vuetify, So you can use it easily in Go code.<p>It even go further to have presets that help you easily build Admin UI with much flexibility. <a href="https:&#x2F;&#x2F;docs.goplaid.dev&#x2F;samples&#x2F;presets-detail-page-cards&#x2F;customers" rel="nofollow">https:&#x2F;&#x2F;docs.goplaid.dev&#x2F;samples&#x2F;presets-detail-page-cards&#x2F;c...</a>
tomatowurstabout 3 years 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.<p>I&#x27;m super relieved to see that many of us are beginning to see the emperor without clothes.
andrewstuartabout 3 years ago
Scott Hanselman says &quot;use the technology that makes you happy&quot;.
评论 #31265988 未加载
评论 #31273902 未加载
donatjabout 3 years 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.
评论 #31268119 未加载
评论 #31268237 未加载
aaronbrethorstabout 3 years 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.
评论 #31273151 未加载
dimglabout 3 years ago
Here am I just using React with no issues :shrug:
评论 #31270926 未加载
ttfleeabout 3 years ago
There is nothing could not be solved by adding another layer of abstraction, except for too many layers of abstraction.
peanut_wormabout 3 years 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.<p>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.<p>I think that the front end web dev community needs to just agree on a good pattern to use that doesn&#x27;t involve a convoluted library or framework.
LAC-Techabout 3 years 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?
评论 #31268049 未加载
评论 #31266181 未加载
评论 #31267159 未加载
评论 #31266306 未加载
评论 #31266065 未加载
评论 #31266434 未加载
CraigJPerryabout 3 years ago
I’m test driving HTMX just for fun right now.<p>I like:<p><pre><code> 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 </code></pre> Things i don’t know about yet:<p><pre><code> 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.</code></pre>
评论 #31270925 未加载
kgbciaabout 3 years 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&#x27;t refresh. maybe the best solution is if the browser does the diff and only updates what is required across response
synergy20about 3 years ago
it really depends on your application, for a site like Rails, Django yes htmx makes sense.<p>One of the key complaints from the blog is GraphQL (too may requests wasted), in that case, SSR might make sense as well.<p>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&#x27;t do full-stack, i.e. you don&#x27;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.<p>For me React and Angular are harder to learn than Vue, and I don&#x27;t do enterprise complex SPA anyways, my choice is Vue when SPA is the right choice.
atoavabout 3 years 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.<p>With the right static site generator you have a propper backend-editor as well, so comfort is not needlessly suffering.<p>Anything more complex, with accounts, logins etc is of course a different class of pages.
winwizabout 3 years 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.<p>Additionally prerender the index&#x2F;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.<p>Crisp React facilitates both splitting and prerendering.
rgloverabout 3 years ago
This is exactly why I’m building Joystick (full-stack, UI framework + Node backend, full SSR out of the box—think Meteor w&#x2F;o data bottlenecks and dependency traps). JavaScript doesn’t have to be a nightmare: <a href="https:&#x2F;&#x2F;github.com&#x2F;cheatcode&#x2F;joystick" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cheatcode&#x2F;joystick</a>.
jmartin2683about 3 years 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.
steve_taylorabout 3 years ago
From htmx.org:<p>&gt; htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML<p>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.
评论 #31272970 未加载
评论 #31270988 未加载
cutlerabout 3 years ago
It&#x27;s not hip on HN to praise Facebook but React revolutionised front-end dev with salaries now on a par with back-end Java&#x2F;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.
rasculabout 3 years ago
&gt; 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.<p>This is an interesting idea I had not thought of or (knowingly) seen. Is it widely implemented? What are the pros and cons?
gigel82about 3 years ago
Oh, I thought this was going to talk about low.js (<a href="https:&#x2F;&#x2F;github.com&#x2F;neonious&#x2F;lowjs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;neonious&#x2F;lowjs</a>), the &quot;node.js&quot; runtime for micro-controllers and tiny embedded systems.
psandorabout 3 years 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.
vips7Labout 3 years 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.
rntksiabout 3 years ago
I agree with everything the author wrote.
kiawe_fireabout 3 years 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.<p>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.<p>Indeed, one of the selling points of tools in the Laravel &#x2F; PHP space is that “you don’t need to build an API” and can “just have normal controllers returning views”.<p>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.<p>But they aren’t. At least not the way most people talk about them.<p>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.<p>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.<p>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.<p>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.<p>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!)<p>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.<p>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.<p>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.<p>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.<p>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.
hunterb123about 3 years ago
So mo lo. No, we&#x27;re lo so mo. No no wait, lo mo so.
bufferoverflowabout 3 years ago
Serving HTML doesn&#x27;t make sense. Serving data and rendering it client side is the reasonable solution.<p>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.
评论 #31266997 未加载
评论 #31268015 未加载