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.

None of my projects want to be SPAs

367 pointsby thequailmanover 6 years ago

51 comments

rossdavidhover 6 years ago
This may be a mean thing to say, but basically I think SPA&#x27;s are massively overused, because developers want to demonstrate that they can do them. Why? Because big companies like Facebook and Google use them. Why? Because they actually are doing things that require them. 99% of the SPAs in production are things that should have been done the old Rails&#x2F;Django&#x2F;Laravel way, but that would not set you up as a developer who can do SPA&#x27;s.<p>I have also witnessed discussions where management admits that they want something done in an SPA so that they can show that work to their investors, as a means of getting funding to do other projects. So basically the same reason, except for managers to impress investors instead of developers to impress potential employers.<p>Not saying all SPAs are mistakes; some uses clearly are not. But most of them are.
评论 #19136737 未加载
评论 #19135597 未加载
评论 #19136051 未加载
评论 #19136130 未加载
评论 #19137462 未加载
评论 #19135854 未加载
评论 #19137038 未加载
评论 #19135699 未加载
评论 #19141404 未加载
评论 #19139082 未加载
评论 #19135946 未加载
评论 #19137209 未加载
评论 #19139067 未加载
评论 #19138451 未加载
评论 #19135745 未加载
评论 #19137117 未加载
评论 #19137183 未加载
评论 #19136050 未加载
评论 #19136531 未加载
kerkeslagerover 6 years ago
Back when I was doing React, what pulled me in was that it WASN&#x27;T a framework for SPAs. What I got from it was the ability to build UI widgets (components, in React terms) that worked within a page, and were composable with other UI widgets.<p>With that approach, you really wanted to keep every component self-contained. That meant a lot of bookkeeping with passing events back and forth between parent and child widgets, but while it was a lot of typing, it was all fairly easy, and if I wanted to change how an event was handled, it usually only involved a component and MAYBE the components immediately above or below it in the component tree. Data passed further than that was generally wrapped in objects and therefore didn&#x27;t require code changes.<p>Then introduce Redux and similar frameworks, and I totally lost interest. It&#x27;s as if the entire React community forgot all the lessons they learned writing Python and C programs in college and went back to creating global state. What in the actual hell? I wrote a good amount of code in Redux, too--I worked on teams that used it--so this wasn&#x27;t just pre-judgment. These frameworks add a huge amount of hidden global complexity just to avoid having to pass parameters to components, which is the simplest thing to do.<p>And once you&#x27;re doing that, you HAVE TO write an SPA, because any part of the page you want to be interactive gets pulled into Redux and your JS eventually eats the whole page. It&#x27;s an infection.<p>When writing JavaScript now, I sometimes end up rolling my own version of the component style. It&#x27;s an effective design pattern for UI widgets. But it hasn&#x27;t been worth it to use React for a while now because the tooling and tutorials are all too conflated with Redux and similarly awful tools. And on a team, there&#x27;s always the worry that someone on your team will infect your code with Redux and it will grow and consume your entire site. It&#x27;s a real shame.
评论 #19135353 未加载
评论 #19135727 未加载
评论 #19135749 未加载
评论 #19135286 未加载
评论 #19135260 未加载
评论 #19135268 未加载
评论 #19135284 未加载
lucidoneover 6 years ago
I went from MVC style all-in-one frameworks (Rails, Laravel) to application APIs fronted by single page applications and hope the developer mindshare tilts back to MVC frameworks. Something that&#x27;d take me an hour or two in Rails can take a week using these new tools, even after being reasonably experienced with them. Don&#x27;t even get me started on Apollo (not my thing at all, and from my experience most don&#x27;t know how to use it well, including myself).<p>Most apps are fine serving html, using plain old boring forms, and having the odd React or Vue component where necessary to do some heavy lifting for user interactions. Moreover, it&#x27;s a lot quicker as a small team to iterate.
评论 #19134747 未加载
评论 #19135605 未加载
评论 #19134891 未加载
b3b0pover 6 years ago
I feel as if many sites that used to be fine and work well have regressed in usability and features and introduced unexpected behaviors and bugs since the SPA paradigm seems to have taken over. This seems especially true for many corporate, bank, shopping brand sites, etc. An example is the Capital One 360, Chase, and AMEX sites and even Reddit.<p>Even JustWatch.com seems like it&#x27;s fairly polished, still has it&#x27;s quirks. So, I just end up using InstantWatcher.com instead. Hacker News works well as is too, except the search on the bottom can act up it seems once in a while.<p>Edit: How could I forget, Netflix. The UI, getting to the details of a show&#x2F;movie. Browsing, discovery, searching, it all feels broken and unintuitive. The DVD site last I checked was still decent. Netflix seems like the poster child for usability and regression issues moving to a SPA.
评论 #19135422 未加载
评论 #19135253 未加载
sharps_xpover 6 years ago
I don&#x27;t use Elixir&#x2F;Phoenix, but Phoenix&#x27;s LiveViews brings all the butter to the monolith bread. State remains on the server, only visual state is sent over websockets, and the HTML is transformed with morphDOM.<p><a href="https:&#x2F;&#x2F;dockyard.com&#x2F;blog&#x2F;2018&#x2F;12&#x2F;12&#x2F;phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript" rel="nofollow">https:&#x2F;&#x2F;dockyard.com&#x2F;blog&#x2F;2018&#x2F;12&#x2F;12&#x2F;phoenix-liveview-intera...</a><p>I hope to see this idea brought to Rails, but the its websocket story doesn&#x27;t seem there yet.
评论 #19135763 未加载
评论 #19135168 未加载
asattarmdover 6 years ago
For CRUD apps, using Rails etc. with Turbolinks[1] is the best way to go IMO. It gives you the SPA feel without the headache. In all SPAs, we load JSON, with Turbolinks, we load HTML of that page alone (without the CSS, JS etc).<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;turbolinks&#x2F;turbolinks" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;turbolinks&#x2F;turbolinks</a>
评论 #19134734 未加载
评论 #19134576 未加载
评论 #19134669 未加载
pgm8705over 6 years ago
We turned to React as the UI solution in our Rails app almost 2 years ago. It was the hot thing and I fell in love with the concept of components. While it did work well, I regret the decision. It convoluted our codebase and it seemed like simple tasks took way longer than I estimated. We&#x27;re now back to doing things the &quot;Rails way&quot; with erb templates, turboklinks, and Stimulus to give us that JS functionality we were looking for when we chose to start using React. It&#x27;s been a breath of fresh air.
评论 #19136016 未加载
wickoffover 6 years ago
Personally I was dumbfounded by complexity of doing async things in redux. Libraries like redux-thunk, redux-sage, redux-observable should not exist. The amount of boilerplate required was incredible and meaningful typescript support was very difficult to achieve.<p>Then I tried mobx, I was able to write a small app after 15 minutes of reading the docs and now I love react.
评论 #19135711 未加载
评论 #19134702 未加载
评论 #19134903 未加载
dkarlover 6 years ago
As a developer I agree that developers should prefer to get features out quickly and optimize the experience later. However, as a user, I think this section is <i>really</i> important:<p><i>I’d like to try and make it work offline. To do that, and do it well, you need a way to show the data in different ways even when you can’t call a server.</i><p>I often have &quot;What the hell is this thing doing&quot; moments as a web app hangs trying to complete a round trip over my mobile connection when I <i>know</i> it has already fetched the information on that page or I know it could be doing something useful despite not being able to connect.<p>The author is not proclaiming that SPAs are a bad idea. He&#x27;s just pointing out how much extra work they are, and that some types of apps are worse as SPAs, or simply much harder with nothing to show for it. He even points out that not all the badness of SPAs is intrinsic to being an SPA:<p><i>Why does a website that orders food from restaurants need a Megabyte of javascript?<p>I tried to figure that out by inspecting the API calls. It turned out they were tracking every mouse event.</i><p>In short: 1) horses for courses, and 2) SPA apps are a lot more work and you have to decide when the benefits are meaningful. Less contentious but maybe less fun than trying to argue which is the one to rule them all.
hathawshover 6 years ago
There is a place for SPAs. I just built a single page React app (using the create-react-app package) that mostly replaced a complex pile of spreadsheets. It came out fantastic, I think. The entire compressed Javascript is about 150 kilobytes, the scripts typically load in less than 500 milliseconds, and my co-workers are very happy. The code is easy to change and the interface between the client and server is clean. (Note: I disabled the built-in PWA features; they made versioning difficult due to excessive caching.)<p>On the other hand, I also maintain a public facing service that is mostly server-rendered with lots of JQuery snippets. I don&#x27;t see a need to convert it to a SPA. It works well as-is.<p>I conclude from my experience that public facing services probably shouldn&#x27;t be SPAs, while things that outgrow spreadsheets might be good candidates for SPAs. I wonder what other areas have been explored.
honkycatover 6 years ago
&gt; It beats being a Magpie Developer. I have more time time to pet my dog, read a lot of books, make fresh pasta by hand, and circle a more slowly evolving collection of powerful technologies that let’s me get stuff done without spending half my free time chasing shiny new things.<p>Saying stuff like this is sure to please the hacker-news hipsters. But... is this honestly anyone&#x27;s experiencing using new web technologies?<p>I tend to be on the bleeding edge of tech, and I very rarely regret learning a new technology. And I do not feel like I am wasting all of my time flitting from technology to technology.<p>I just think this is a smarmy attitude disguised as wisdom. People should like what they like. And as someone who has had to climb that hill before: Waiting around not expecting the world to change around you is a losing bet every time.<p>The fool doth think he is wise, but the wise man knows himself to be a fool.
评论 #19137249 未加载
mamcxover 6 years ago
Another angle is that &quot;SPAs&quot; are build on top of a fragile and anti-engineering tech stack: JS, CSS, HTML.<p>In the past a &#x27;SPAs&#x27; was build on top of more solid foundation like smalltalk or later Delphi. Most issues is that the browser stack, put it in real terms, is not the &quot;right tool for the job&quot; and will never will, without serious re-engineering.
评论 #19138164 未加载
drcongoover 6 years ago
I come across so many sites that have been needlessly built as SPAs, and so many of those are broken in ways that are really hard to understand even as a technically savvy user. For regular people, it&#x27;s a truly appalling experience - the sites my wife has to use for work are all like this, all broken and all slow - she blames her laptop. SPAs need to die.
评论 #19135158 未加载
评论 #19138194 未加载
DanielBMarkhamover 6 years ago
A SPA should be the emergent <i>result</i> of creating an application that does something people want, not a goal in itself. Your builder doesn&#x27;t show up at your house to put on a new deck and go &quot;Gee, I really hope I get to use this 20-pound sledgehammer on this job. I hear it makes great projects&quot;<p>If you start with how it&#x27;s going to end -- it&#x27;s not going to end well.<p>Having said that, what you&#x27;re most likely seeing is that a ton of tools and frameworks are built for no other reason than 1) Coders need something to create to show other coders how awesome they are, and 2) People want something that works like everything they know -- it just does these one or two new things<p>This is a great way to make a mess over a decade or two, and you&#x27;re right for waiting it out.<p>Make a SPA if you need a SPA. Key question: How do I know whether I need a SPA or not? (Or whether React makes sense, etc)
koblasover 6 years ago
There are lots of applications which don&#x27;t really benefit from being an SPA (blogs, books, etc.). As soon as you start thinking about meaningful interactions you quickly start having to pile enough JavaScript into the HTML that you quickly run into a mess - defining ways to marshal data back and forth with an ad-hoc structure.<p>While SPA tooling like React are incomplete since they don&#x27;t provide all of the client&#x2F;server data communications that comes for free with a server side application. That is starting to become more &quot;standard&quot; as GraphQL and Apollo start filling the gap of boilerplate. Though of course wrapping your head around GraphQL takes a bit of work for anybody who&#x27;s spent their life with REST.<p>Most applications should be SPAs to create the interactions that users expect.
评论 #19134615 未加载
aogailiover 6 years ago
SPA and react are not the same thing.<p>React is about components and you can use React in something like NextJS which is not a single page app but a server rendered pages.<p>Also, SPA itself is getting outdated concept, now most apps are hybrid of initial bundle followed by a dynamically imported modules. Finally, MVC is a pattern for web pages, the complexity in the client side because what is the being shipped to the browsers are a client side apps with their own router, render functions, state management and APIs.
morpheuskafkaover 6 years ago
We recently went in the opposite direction for a student project I&#x27;m working. We have a full SPA Angular frontend, and we use CouchDB as our datastore. There is a Node &quot;backend,&quot; but it only serves things like Slack integration, the browser has a local PouchDB instance that directly syncs with the server&#x27;s CouchDB. This way, we can deploy hotspots with nothing more than a Couch install and a static server for the SPA.<p>The modern, offline web is great. If we had to do this in a native app we would never have gotten the project off the ground, because we initially need to use BYOD phones which were evenly split from iOS&#x2F;Android. We&#x27;d have had to use three languages, but a Mac, get developer licenses, and learn Swift and Java just to get an offline frontend, and sharing business logic code would be impossible.
评论 #19153153 未加载
评论 #19135132 未加载
nistenover 6 years ago
To add to this, bandwidth and app size is not important to the user(they&#x27;ll watch netflix later). The only thing they notice, is response time.<p>React with well defined static content routing and server-side rendering is amazing at this because the first packets that the server sends the user is html&#x2F;css jumble.<p>You can get your app to show text and formatting in as little as 20ms(depending on where you deploy it), then show images, then you don&#x27;t care if the rest of App and all the js and 3rd party crap take another 2.5s and 3mb to load, The user will do a bit of reading and picture watching, before using a button or input field. However if they&#x27;re on the go and loose connection, now they have a fully functional back button in their browser to read the next or previous cached html&#x2F;css content.
评论 #19134705 未加载
realusernameover 6 years ago
Also one of the things not listed here is the added complexity of an SPA, the routing bugs, the old browsers bugs, the added complexity of splitting js files so the initial load does not become too big, the data storage...<p>I&#x27;m currently maintaining alone two large websites and only one of them is an SPA, that&#x27;s definitely the harder one to maintain by far.
laszlokorteover 6 years ago
What I did for a mobile web app I built last year after the react prototype was to slow on old devices:<p>- Render all pages&#x2F;routes&#x2F;states into a <i>single</i> html file (size ~2mb) but each page&#x2F;component&#x2F;state hidden via style=display:none;.<p>- then write some hand crafted js (few hundred lines) to add event listeners to forms and show&#x2F;hide the components depending on url change<p>- cache everything via appcache&#x2F;serviceworker<p>- result: not so fast initial load (1-2 seconds) but really fast interaction afterwards even on old lowend devices, almost no time spent running js&#x2F;react&#x2F;vdom. even some scrolbugs I had to work round before when using react (eg replacing dom nodes but keeping scroll position of a parent container) resolved on their own.
评论 #19134761 未加载
评论 #19135046 未加载
评论 #19135307 未加载
geebeeover 6 years ago
This article and discussion does show, in a pretty stark way, the options and demands of very different career paths for a software developer.<p>One option is to become a programmer for hire. You keep your skills up, and those skills are as much about getting a job as doing the job. You re-study data structures and algorithms. You can permute sets, find matching subtrees in binary search trees, and answer questions about how addresses in web browsers are resolve to web sites. You learn java, then GWT, then EJB, then spring, then struts, then you add a 2 to the end of struts, then Rails or Django, then you give it all up and do it again in Javascript, React, Vue, Ember. You also play the agile &quot;estimate roulette&quot; as you write down tasks and expected completion times in JIRA, and are asked about deadlines every morning in an almost inevitable corruption of the original methodology[1].<p>You would never do this for your own project. If you had an exciting new idea, the last thing you would do is go off and learn to find all subsets of a larger set that, when concatenated, form a member or the larger set, at the whiteboard, in 45 minutes. It&#x27;s also fairly unlikely that you&#x27;d set out to write an SPA for many business ideas. But you&#x27;d definitely be doing this if you were applying for the next job, which you sort of always are doing, if you&#x27;re a programmer for money. Even if you aren&#x27;t looking to change jobs, you still do this, by and large.<p>Or, you can become the kind of programmer who creates a product, chooses the right tool for the task, and makes it work. The reason that this is difficult is that these jobs are rare. To really have this option, you often need to make the leap into doing your own thing.<p>That sort of entrepreneurial skill and mind-set seems to be orthogonal to most programmers. I couldn&#x27;t tell you if it&#x27;s innate or learned, but I do know that it&#x27;s a big leap, involves risk, requires a period of economic uncertainty that is tough for people with dependents (or people just trying to pay rent and make it through the next few months in an expensive city). But it may be the best way out of the programmer-for-money quagmire.<p>The thing is, if you have that kind of entrepreneurial spirit... well I&#x27;m not sure you really need to be a programmer at all, there are all kinds of great opportunities out there.<p>[1] Yes, this is a bad case. Not a worst case, but a pretty bad one. I&#x27;d say all programmers for money have gone through some version of this more than once, but I&#x27;m putting them all together into something that is more grim than most have to put up with.
arcticwombatover 6 years ago
I have to say my experience tracks this too.<p>A lot of the &quot;modern&quot; toolsets just aren&#x27;t worth the extra fluff they add.<p>Writing SPA&#x27;s in React, Angular, etc. tend to result in a very heavy first page load, then api calls with poor UX for all actions.
评论 #19134640 未加载
supermwover 6 years ago
Why do people insist on comparing the initial frontload of a SPA to the page load of every page in their SSR web app?<p>Once a SPA is loaded you can send tiny crumbs of data faster than any significant SSR.
评论 #19134572 未加载
评论 #19134502 未加载
评论 #19134585 未加载
评论 #19134583 未加载
pastulloover 6 years ago
Completely agree on this one. I feel that a big chunk of &quot;let&#x27;s make it an SPA&quot; is coming from the development team wanting to use and learn first hand these new exotic tech stacks. In the past two companies i have been, there was no strict guidance on the technology stack for each microservice or web app, so it ended up being a jungle of microservices written in GO, Elixir serving apps in React.js, VUE.js etc.<p>Did the company or the end user benefit from this? Hell no. Only one benefiting were the developers who ten left and asked for a 10k more salary on their next job for sporting that fancy new javascript framework. NICE!
amoitngaover 6 years ago
The latest project I&#x27;m currently working on I got to choose how to build. It is an internal CMS. I went with Rails API, React, Material-UI. So far, I like it.<p>I like separation. I know that one side ( ruby, rails, gems, pg, sql etc ) is all about data -&gt; one mindset.<p>Another side is about views ( js, css, html, multiple select, date pickers, autocompletes etc ) -&gt; different world.<p>I build my assets in one place, I work with my data in other. I wear one hat as a backend guy, and when I need refocus completely on front end work.<p>I wouldn&#x27;t argue it&#x27;s easier, but I think it&#x27;s easier for me. I like it better.<p>Plus, the API will be consumed eventually by user-facing site and apps.
评论 #19135077 未加载
foucover 6 years ago
There is a slight advantage of separation in frontend &amp; backend - writing tests for an API-only backend is so easy. On the other hand, the frontend SPA still needs tests, and I have no idea how to make that trivial yet.<p>P.S. If you folks want a really small react-like SPA, I recommend either <a href="https:&#x2F;&#x2F;mithril.js.org" rel="nofollow">https:&#x2F;&#x2F;mithril.js.org</a> or <a href="https:&#x2F;&#x2F;riot.js.org" rel="nofollow">https:&#x2F;&#x2F;riot.js.org</a><p>And you can avoid state management complexity by using a pattern like <a href="http:&#x2F;&#x2F;meiosis.js.org" rel="nofollow">http:&#x2F;&#x2F;meiosis.js.org</a>
评论 #19137457 未加载
nautilus12over 6 years ago
I see the same thing happening on the front end that I saw happen on the back end with big data. Just because it fits better into Google and Facebook&#x27;s Enterprise patterns doesn&#x27;t mean it will work for everyone. Very few companies need Hadoop, probably as few as need react
pier25over 6 years ago
After working exclusively on SPAs for a number of years (React, Vue, Inferno) I&#x27;m getting out of that unless there is a strong argument in favor such as a hybrid mobile app (and that will go away once we move into Flutter).<p>I don&#x27;t want to go back to Rails&#x2F;PHP&#x2F;Python though. I like having a REST&#x2F;GraphQL API. With Hasura I don&#x27;t have to worry about backend anymore for 80% of the cases.<p>What I&#x27;m doing right now for the front end is using Jekyll with Vue. It&#x27;s really liberating not having to worry about a router or managing application state anymore. For certain in-house projects I don&#x27;t even have to use Babel or Webpack anymore and still get to use Async&#x2F;Await.
donatjover 6 years ago
In my personal experience very few projects actually want or need to be SPAs, developers are just dying to work on SPAs so hiring managers oblige to hire talent.
CM30over 6 years ago
I&#x27;m in pretty much the exact same boat as the writer here. Nothing I want to build seems like it&#x27;d need to be a SPA, nor work better as one.<p>Maybe that&#x27;ll change if I decide to build games with HTML&#x2F;JavaScript&#x2F;CSS or want to make some sort of online version of a desktop program, but nothing in my current ideas list is app like enough to really warrant the SPA setup.
platzover 6 years ago
My favorite pattern right now is server rendered html shell including static parts of the page, and then invoking a view-only js framework with all the server data required sent in the initial page load for the dynamic client bits, which runs immediately on page load.<p>so, basically a &quot;functional&quot; front-end view-framework for client-side behavior, but with no routing.
c-smileover 6 years ago
Yeah.<p>1. Tons of existing jQuery components.<p>2. Ten of custom, loosely coupled ones.<p>3. Built-in PubSub for their communication:<p><pre><code> $(document).on(&quot;custom-event&quot;, function() {...}) </code></pre> 4. Routing (if needed) in 60 lines of code: <a href="https:&#x2F;&#x2F;github.com&#x2F;c-smile&#x2F;spapp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;c-smile&#x2F;spapp</a><p>And you can do any SPA out there. Or not SPA.
duxupover 6 years ago
Every time I read an article about SPAs... I feel like someone has a new view on what an SPA even IS, what it is good for, and so on. Many articles sound like they&#x27;re talking about entirely different things.<p>I get the definition, but I don&#x27;t see a lot of problems and etc .... necessary a part of SPAs.
shussonover 6 years ago
If anyone would like an example of the silliness that exists in SPA bundling see <a href="https:&#x2F;&#x2F;github.com&#x2F;angular&#x2F;angular-cli&#x2F;issues&#x2F;6137" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;angular&#x2F;angular-cli&#x2F;issues&#x2F;6137</a>
评论 #19134975 未加载
rkangelover 6 years ago
I&#x27;m really interested in Phoenix LiveView (<a href="https:&#x2F;&#x2F;dockyard.com&#x2F;blog&#x2F;2018&#x2F;12&#x2F;12&#x2F;phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript" rel="nofollow">https:&#x2F;&#x2F;dockyard.com&#x2F;blog&#x2F;2018&#x2F;12&#x2F;12&#x2F;phoenix-liveview-intera...</a>) when it gets released. It means you have the normal simplicity of server rendered code, but then an option for interactivity (e.g. A rich form) without having to have part of your logic in a completely different place&#x2F;technology.<p>When you start thinking about field validations and having to duplicate them client and server side, it makes even more sense.
rkangelover 6 years ago
I had always assumed that the move to Spa&#x27;s occurred in large part due to mobile apps. A mobile app effectively has to be a client rendering of data from an API, and if you have to do that for mobile, it makes sense to do it for the Web.
ashelmireover 6 years ago
I don&#x27;t think many projects <i>need</i> to be SPAs. But if you&#x27;re using node for your backend anyway, I think it&#x27;s basically equal work to make something an SPA vs a non-SPA. The SPA effectively handles the routing for you, and I think react-router is pretty easy to use.<p>The speed benefits are noticeable on sites where you&#x27;re doing a lot of internal navigation. But you can just as easily make a slow SPA (see JIRA).<p>So I guess in the end, do whatever takes less development time. Which usually isn&#x27;t an SPA, just because there isn&#x27;t really a good framework that reduces effort required. Rails and turbolinks are pretty legit.
vlaskyover 6 years ago
The Meteor framework has been actively developed ever since it was released and continues to have a broad, enthusiastic user base.<p>Mr Goldstein would have known this if he had visited the Meteor blog (<a href="https:&#x2F;&#x2F;blog.meteor.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.meteor.com&#x2F;</a>) and Meteor forums (<a href="https:&#x2F;&#x2F;forums.meteor.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;forums.meteor.com&#x2F;</a>).
theamazingtobyover 6 years ago
If the project I&#x27;m working on is a personal project, then hosting price becomes a big factor, and being able to host an SPA on S3 for pennies a month, with a free Firebase backend, becomes a MAJOR advantage over hosting a Rails app on Heroku. If I&#x27;m working on OPH (other people&#x27;s hardware), then I&#x27;ll go with whatever makes more sense. Or whatever the rest of the team wants to use.
woolvalleyover 6 years ago
As a mobile app developer, looking at the architecture of PWAs is a bit obvious to me. It&#x27;s to turn webpages into stand alone mobile &#x2F; desktop apps, with all of the power &amp; setup that implies. But without the size overhead of an actual app, because every phone has a runtime library called the browser.<p>It&#x27;s a great tool if that is your goal. Otherwise why spend the extra effort?
tracker1over 6 years ago
To contrast, I&#x27;ve been looking for a reason to use Go for a couple years now on an actual project, I haven&#x27;t really found one yet. That doesn&#x27;t mean that go doesn&#x27;t serve a purpose and is probably more representative of me being adverse to taking on the risk of learning&#x2F;using it with a project than it does as to the ability of Go to serve a specific role.
nistenover 6 years ago
Wtf is an SPA?
评论 #19134468 未加载
评论 #19135269 未加载
评论 #19134467 未加载
评论 #19134531 未加载
评论 #19134453 未加载
评论 #19134459 未加载
评论 #19139541 未加载
rchaudover 6 years ago
As someone who&#x27;s self-taught in Wordpress development, I tried to branch into React but I had similar questions that stopped my progress. I&#x27;d always be thinking &quot;why are they setting it up this way&quot;?<p>Are there any barebones tutorials out there for CRUD apps that don&#x27;t require Node.js, Python etc, and can be learned using PHP, MySQL and HTML?
Illniyarover 6 years ago
Do we really need to defend SPA every other week? The market, users, product, ui&#x2F;ux designers and the vast majority of developers decided that SPA is a better user experience.<p>Page loads greatly degrade the user experience, especially when you have long lag (which for many of us the reoundabout time is longer then the download time of 100k).<p>Even if you make your site extremely lean, it&#x27;s still a worse experience, and let not forget that for the majority of sites lean is far beyond them (not the least because you must integrate third party code such as social and analytics or fade into obscurity against those who do)<p>So some developers feel that the old way of doing things is just fine. There are always some of those. Probably the same ones who surf the web with js disabled. This is not even remotely what the average person expects and anyone who thinks they can build a website like that and compete are delusional (and hacker news is perhaps the exception that proves the rule. Even google is not html only anymore)
评论 #19135739 未加载
评论 #19135726 未加载
评论 #19137814 未加载
tripzilchover 6 years ago
... I read this entire article and still don&#x27;t know what a SPA is :)<p>Seriously, I&#x27;ve tried looking it up... <a href="https:&#x2F;&#x2F;acronyms.thefreedictionary.com&#x2F;SPA" rel="nofollow">https:&#x2F;&#x2F;acronyms.thefreedictionary.com&#x2F;SPA</a>
评论 #19147867 未加载
spricketover 6 years ago
I&#x27;ve found the most annoying aspect of using a SPA is having to consume your own API&#x27;s. Using Swagger or gRPC on both ends helps immensely.<p>These, combined with Angular CLI or Create React App, allow me to be just as productive as the pre-spa days
评论 #19136126 未加载
nickthemagicmanover 6 years ago
I don&#x27;t like them because they&#x27;re against the nature of the web.<p>They override routing, they override SEO, they make it hard to use build in browser tools, etc, etc.
punnerudover 6 years ago
Nr4. &quot;people argued that it would be faster to only pass the data you need as JSON than to render whole pages&quot; - This also kills your SE(O)-ranking
aaghaover 6 years ago
I gave up on the article as soon as I did a ctrl-f to find the definition of an SPA and didn&#x27;t see it.
rawoke083600over 6 years ago
Is SPA with unique-urls (think angular-routing) still a SPA ? Most of my websites+apps are done using Angular&#x2F;PWA.
评论 #19137525 未加载
crimsonalucardover 6 years ago
Nothing wrong with the concept of SPAs. It&#x27;s just these modern front end frameworks leave a lot to be desired. None of them simplify complexity and modularity is an illusion. Most of your components can&#x27;t be reused in another project.<p>Additionally these frameworks are harder to debug thanks to leaky abstractions.<p>The only front end abstraction I&#x27;ve seen do it correctly is Elm. I&#x27;m not saying Elms&#x27; pattern or language is good or correct; (I have no comment about that) I&#x27;m saying that the abstraction isn&#x27;t leaky. No javascript errors in Elm, just elm level errors. React Vue and all these modern frameworks need to be handled the same way.<p>I know technically that react is just a framework and not an entire language over javascript, but the ways and technology React is typically bundled with makes it a leaky abstraction and the common use case should be handled.