TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

You Shouldn't Start with an SPA

46 点作者 simonhamp超过 1 年前

20 条评论

kgeist超过 1 年前
&gt;Your back-end and front-end are always coupled. So trying to split them in anything but the most extreme circumstances is an exercise in futility.<p>&gt;If your back-end team want to move in one direction, they&#x27;ve got to align with the front-end team.<p>We have different backend and frontend teams and I can&#x27;t agree that it&#x27;s futile or hard to decouple etc. The only &quot;coupling&quot; which we have is the public API of the backend. Before a product or a feature is started, the teams design and agree on the API between the backend and the frontend, as part of our overall architecture design process (doesn&#x27;t take more than a couple of days of 1-2 senior engineers if it&#x27;s a big feature). After that, the two teams work completely in parallel. The frontend team has a framework which allows them to test the UI without the backend ready (using mock API). The backend team checks their API implementation using end-to-end tests. When the both teams are ready, we have the integration phase to see if it works together. Sure, often some edge cases are found and the API has to be changed a bit, but overall for me it has been quite a pleasant experience.
评论 #39230143 未加载
评论 #39230833 未加载
评论 #39231781 未加载
ebiester超过 1 年前
I believe this is a cultural argument mascaraing as a technical one.<p>The honest truth is that we have had front end and back end developers for as long as the web has been around, and before that. Your &quot;full stack&quot; developers are most often back end developers who begrudgingly can put together a less complex front ends with very little understanding of what makes a front end good to work with. Your &quot;full stack&quot; front-end preferring developers get drummed out because the back end developers conflate being good at back end concepts with being good at programming in general.<p>There is a definite back-end bias with developers who do not specialize in web or mobile front ends.<p>For some applications, that&#x27;s fine. However, back end developers build the back end frameworks and do not think about what makes a great experience for developing more complicated user experiences.<p>In many ways, the reason front end developers moved to SPAs was that they could better control their own tooling in ways that are difficult in the traditional web application frameworks.
评论 #39232849 未加载
评论 #39237384 未加载
评论 #39231796 未加载
camhart超过 1 年前
If you have multiple frontends seperating frontend logic from backend makes a lot of sense.<p>I&#x27;ve been building&#x2F;maintaining a SPA for the past 8 years and have no regrets and am unconvinced by this article (or the one it mentions).
评论 #39230440 未加载
ivan_gammel超过 1 年前
Client-side rendering has a lot of benefits not mentioned in the article.<p>1. Adaptive design: it’s easier to adjust user experience to the client device capabilities. SPA frameworks take the job of ensuring browser compatibility, but it’s not just it.<p>2. Less traffic in data-rich apps (even taking into account compression, HTML is heavier than JSON and not just due to syntax overhead - consider all those page headers, footers and other common parts).<p>3. Better UX for slow networks: even in countries with 5G coverage there are still a lot of corners where your device will struggle to connect. SPA can auto-retry, just showing the spinning wheel longer. Browser will show the timeout page, and who knows if the backend can correctly recover on refresh.
评论 #39230083 未加载
评论 #39230193 未加载
评论 #39230000 未加载
评论 #39232663 未加载
评论 #39232868 未加载
评论 #39232644 未加载
评论 #39229943 未加载
评论 #39231840 未加载
xutopia超过 1 年前
I think he&#x27;s fundamentally right even if he&#x27;s wrong about certain details.<p>SPA create a polarization between devs whereby they&#x27;re either front end or backend. Full stack devs are slowed down compared to tools like Hotwire&#x2F;Turbo, Liveview, HTMX, etc.. Furthermore you need a huge stack of tooling to make pages work and lots of javascript code needs to be downloaded to make most standard SPAs work today. Not to mention having to render html on the backend in a slower and more complicated manner than using any of the more recent enhancements of HTML that provide caching, high speed download out of the box.
评论 #39229880 未加载
lelanthran超过 1 年前
I <i>think</i> that this all boils down to <i>&quot;The tooling sucks&quot;</i>.<p>The specific SPA problems mentioned <i>are due to</i> the bundling, the packing, the dependencies, etc.<p>None of the SPA problems mentioned are specific to SPA, they&#x27;re specific to current toolsets.
评论 #39229637 未加载
评论 #39229648 未加载
评论 #39230198 未加载
pjerem超过 1 年前
For what it’s worth, I started my current project with the good old Django framework. I haven’t touched it for mostly a decade and my god it’s just a pleasure. You just write your domain code and the framework handles everything else. But more importantly, Django don’t try to be original or to force you into a paradigm, it just solves and abstract away the real life problems of websites. There is basically 0 boilerplate.<p>Add some htmx for the few things you want dynamic and you’re done.<p>Now, I prefer typed languages but why haven’t we something like Django (or Rails) in typescript ?
评论 #39231603 未加载
klysm超过 1 年前
You should start with an SPA if it makes sense for what you are building.
评论 #39231903 未加载
superkuh超过 1 年前
It reads like this article&#x27;s unstated premise is that it&#x27;s about what you should do in situations where you aren&#x27;t in control, are being paid to do the things, and working with other people in the same situation. But why write articles about what we&#x27;re forced to do for money? That situation is always borked and we wouldn&#x27;t be there unless we were being paid. Who wants to think about and do work during non-work free time? Yuck.<p>Lets see some articles about what human people, not people hired to do corporate person&#x27;s bidding, should do. In this context the case for SPA is even more diffuse. In fact, all the arguments about synching frontend and backend don&#x27;t even makes sense: that kind of thing is cargo culting.<p>Human persons when operating of their own free will working on their own projects should definitely not start with SPAs. They shouldn&#x27;t even start with javascript dependent frameworks. Just put an HTML file in a directory.
评论 #39232108 未加载
davidsergey超过 1 年前
The article talks a lot about technology choice, but not about given product. I do tend to agree – that SPAs are not necessary, but I would not use this article as an argument.<p>And if somebody would present this article to me – I would not take it seriously. The fact that author is using very interesting language when refering to React and Angular does not help. I&#x27;d love to hear customer-centric or product-centric reasoning. * Don&#x27;t use SPA because customers hate it when you change entire app on them. * Don&#x27;t use SPA, because customers of our particular product require faster turn-around. * Don&#x27;t use SPA, because they are harder to test in our organisation.
评论 #39231915 未加载
cpursley超过 1 年前
Post mentions Livewire &amp; Hotwire but totally misses the real star (and OG) of this type of architecture: Phoenix LiveView<p>^ Elixir is an order of magnitude more scaleable, easier to operate and cheaper than any of these other solutions.
评论 #39230336 未加载
评论 #39242321 未加载
paxys超过 1 年前
This article (and all others like it) always ignore the fact that mobile exists. Nowadays &quot;front end&quot; isn&#x27;t just HTML pages being rended on some browser but also entire iOS and Android apps and maybe several others. Those APIs you think are an overhead are actually necessary regardless, and after that it&#x27;s your server rendered HTML that instead becomes an additional burden to maintain. A SPA with dedicated front end engineers using the same APIs as the mobile ones is the most sensible approach for most apps.
评论 #39232024 未加载
from-nibly超过 1 年前
In my experience spas have a much better ux. Have you guys used Jira before? It&#x27;s actively painful and there even is some local interactivity. But whenever you need a page wide rerender it makes me twitch. Same thing with aws when navigating between accounts&#x2F;products.<p>Also having a spa doesn&#x27;t mean you need to have separate frontend and backend engineers.<p>But it does allow various value streams to leverage each other&#x27;s APIs in their own front ends.
azangru超过 1 年前
&gt; When does an SPA make sense?<p>I didn&#x27;t quite get the answer — if it is that an SPA makes sense when you have front-end and back-end specialists on your team, then it is surely the wrong answer. Perhaps I misunderstood.<p>I like Alex Russell&#x27;s answer: an SPA makes sense when data about users&#x27; session depth demonstrates deep sessions. Or Jason Miller&#x27;s answer: an SPA makes sense when the thing that&#x27;s being built fits certain known app holotypes.
评论 #39232257 未加载
douglee650超过 1 年前
Modern frontend frameworks smear technical concepts into the presentation layer; for example, understanding of hydration becomes integral to semantic presentation of content and therefore an overriding concern; &quot;developers aren&#x27;t cheap!&quot;.<p>Then we are reduced to two outcomes — developers become more design-aware, or designers become more dev-aware. Both are unicorn hunts, what do?
评论 #39232050 未加载
BinRoo超过 1 年前
I wonder, what the best practices for supporting offline mode when the backend drives the frontend?
评论 #39231405 未加载
评论 #39229598 未加载
评论 #39232059 未加载
endisneigh超过 1 年前
It’s always amusing how people compare crappy spa vs great traditional site.<p>A well done spa is far superior. Offline support, caching, adaptive layout, etc. it’s not even close.<p>That being said, barring things like offline support the two are equivalent functionally. Use what you know.
评论 #39232290 未加载
simonhamp超过 1 年前
I feel like a lot of the commenters here have missed the point... in the title it says you shouldn&#x27;t <i>start</i> with an SPA.<p>I never say &quot;don&#x27;t ever use an SPA,&quot; just that I feel—more strongly than ever—that the kinds of environments that call for a true SPA are getting further and further towards the extreme.<p>You <i>should</i> do whatever you like. As always, there are trade-offs. <i>For me</i> it&#x27;s becoming clearer that the trade-offs are heavily stacked towards keeping my front-end and back-end more tightly coupled.
评论 #39232112 未加载
redcobra762超过 1 年前
Two thoughts:<p>Firstly, when you provide a normative assertion, at least couch it in positive terms.<p>“<i>If</i> you want X, <i>then</i> you should do Y.”<p>That way people at least know the tradeoffs you’re opting them into. I really can’t tell what trade offs the author is proposing are better for me.<p>Secondly, if you can’t build a system that actually decouples the frontend and the backend, that’s a “you” problem, not a technology problem. I have successfully designed and implemented many APIs that operated completely independently of the UI, allowing both the UI and power users to interact with our platform through a shared service.<p>I do get so tired of people presuming their specific issues are everyone’s issues. I have zero problem with the tooling of an SPA, my ability to customize is <i>increased</i>, not decreased, when I use an SPA, and when I’m working with other people, they often prefer not having to think about the whole stack, which makes them happier.<p>This is one of those articles you read that shows up “unplugged” from the culture in which it originated. The author demonstrates the value of talking to others in a given field, and the pitfalls that one can get trapped in when one doesn’t socialize enough professionally.
评论 #39232137 未加载
评论 #39230082 未加载
jongjong超过 1 年前
I completely disagree with any attempt to merge the front end with the back end by obscuring the boundary. It&#x27;s a horrible idea and leads to security vulnerabilities.<p>The front end is a public resource, the back end is a private resource whose access needs to be controlled according to clear and consistent rules and with proper authentication checks.
评论 #39229632 未加载