461–470 of 522 posts
I don't get 'SEO for free' argument. You don't SEO application, you SEO landing page and you don't want crawlers to crawl your app.
Earlier quoted context omitted.
You overlooked this part: > Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks
You simply trade back-end frameworks complexities for the front-end framework complexities. With the right architecture there is no huge difference IMO, just of course you also need to upgrade your teams so that they can handle a lot more tasks on the front-end than with SSRs (and you'll probably need less back-end devs)
Earlier quoted context omitted.
Front-end frameworks have a way of going in and out of fashion / support much faster than backend ones.
Yes, but front-end developers are much more fungible as well.
Earlier quoted context omitted.
> I definitely get edge cases like Slack, but honestly don't think SPA has been a positive development, overall. I think the web was better as a document/HTML oriented design. But even Slack is subject to the same clunky and slow user experience you're describing because its entire user interface is an SPA. In my opinion, a site for the SPA hall of shame is the Starbucks.com progressive web app [1]. My grievances abo…
The Starbucks app in Edge is _miles_ faster than Amazon.com or eBay.com for me on my slow satellite connection. I think this is one often underlooked feature of SPAs. SSR stuff is a blank white screen about 50% of the time for people on slow connections, SPAs have a slower initial load and then from then on are either faster or _feel_ faster because they don't go completely blank for 5+ seconds every time you click s…
Earlier quoted context omitted.
Yes, but front-end developers are much more fungible as well.
Not if you've built your product around a front-end framework that's gone out of style.
We have one guy in the office responsible for all of it, as warm bodies with backbone experience are impossible to find. However, should we decide to employ remote workers, we can easily find developers with backbone.js experience from Romania, Lithuania, India, and Pakistan who would work for a pittance and be grateful for the opportunity.
Earlier quoted context omitted.
> I am not sure what the Angular or React solutions are but with vue just use the vue router. For React there's a couple, but most of them boil down to the same basic idea that you've got switch statements that decide which components to render based on router state (rather than there being anything "special" about routing entry points), and then something like a component that just acts like an tag but triggers the…
I used react-router before but absolutely hated how it mixes presentational logic with URL matching. For new projects I just use a small routing helper that’s written using React context and that performs URL matching the old fashioned way (a list of pattern with parameters that are routed to specific components). Works really well on all modern browsers and is less than 200 lines of code. It even allows for reverse…
You may like redux-first-router, which has the URL literals as part of a routemap attached to the Redux store, and then has all routing in the app actually just be the dispatching of Redux actions. Your navigational components then end up with stuff like:
Link text here
I used to feel that way, then I met a one javascript developer in particular who really made me see it differently. I won't get into those here, I just want to tone down the "probably don't need" into a "don't necessarily need". As a predominant back end developer, I do feel that the complaints from the article are due to inexperience or misunderstanding: 1. stateless requests: You don't have to cache any state by de…
Regarding 3: The Browser does a bit more than routing and no framework (as far as I know) handles these simple cases by default: - Timeout error / no network connection - Ability to stop requests - Show that the browser is sending a request
Also, in the favor of SPA's you can consider the horrible state of repeating post requests when users press the back button on server rendered multi-stage forms (like purchasing a flight ticket). Of course, you can just avoid implementing multi-stage forms via POSTs like this and I wish airlines would stop.
If you implement your SPA with a service worker and use cacheable GET's properly, your SPA can work offline and survive temporary network glitches (like on a train) in a way that server rendered apps never can.
Earlier quoted context omitted.
> Yeah, I start with an SPA and adapt to the use-case. It either needs to be a SPA Aha, by mistake you corrected your grammar! HNers cargo cult everything, including grammatical mistakes like "an SPA" ( see literally everywhere in this thread). Just say it out loud, "I start with an SPA", does that roll off the tongue? No, neither does, "I'm going to buy an sailboat". However, "It either needs to be a SPA, ..." is to…
SPA isn't pronounced "spa" but S-P-A thus an SPA is more likely correct. See "an FBI agent" for an example.
Now I can read SPA posts without cringing...
Unpopular opinion: I love SPAs for simple stuff. Yes, they're a ton of work. But the feel of them is unparalleled. I have my personal home page written as a Vue SPA. It was a silly amount of work to get together, and not everything works perfectly. BUT: it moves like a rocket. I pre-render the simple front page, so initial load is nearly instantaneous (especially with cloudflare &c), and, by the time a visitor finish…
I want to be open-minded for you to have your fun. But at the same time, I want to let you know the problems with your approach from my perspective if you want me to interact with your site. No offense, but I don't know you, so I'm not going to run untrusted code you serve my computer without some good reason. That means your website is completely broken for me. It is also likely broken from an accessibility standpoi…
Today, not running JS breaks the web. You can lament this, I too think it's not ideal, but you can't change it. So don't accuse devs of breaking the web for using an SPA just because you're part of the 0.002% of users that doesn't run js by default.
Furthermore SPAs do not break accessibility, that is nonsense. Devs may break accessibility if they choose to reimplement components without thinking about it but that has zero to do with SPAs.
Earlier quoted context omitted.
60MB is a significantly lower amount compared to 40GB, but I don't think it is fair to compare the disk space of an operating system, IDE, and database server to a directory of javascript libraries.
If a developer cannot meaningfully work within .NET without an IDE, it absolutely counts. Just like someone on the frontend cannot work without babel or typescript. Those libraries add specialized tooling for the project in question. Instead of downloading a runtime that has a huge std, in JS everything is downloaded on a per-project basis. I cannot speak to .NET, but want to work with python? Bring in one library an…
It's also more visible. Python libraries are hidden in the environment far from your shell or file manager. So you don't know that your virtualenv weighs 300mb. But node_modules is right there, you can't help but look.
In other words it's a complete lack of experience, regardless of how adamant the OP is about their skills.