Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

None of my projects want to be SPAs

whatisjasongoldstein.com

Post reply on HN
Print view View original

181–190 of 362 posts

Re: None of my projects want to be SPAs

#181

Post by hombre_fatal »

repsilat wrote: post #140
s_y_n_t_a_x wrote: post #135

Earlier quoted context omitted.

It's really simple, if you're developing a web app, use a SPA stack. If you're developing a web page, use the minimal amount of tech you need on top of HTML, ideally where the HTML functions without JS.

Does that help much? The distinction between "web app" and "web page" seems fuzzier than the question "would a SPA lib/framework be useful here?" Is Reddit a web app? Is Twitter? Facebook? They all started with server-generated HTML, all kinda feel "document-like", all of them involve scrolling (if that means anything.) Is the "app" boundary further along the chain, like at Google Docs? I think instead of trying to c…

It's really easy to throw the baby out with the bathwater in this conversation as well.

A more interactive Javascript-heavy UI can improve a lot of aspects of even websites we consider to be a server-side-rendered gold standard like a forum or message board.

For example, look at the right-sidebar scrubber on Flarum that lets you quickly scroll to arbitrary parts of a long forum thread: https://discuss.flarum.org/d/17745-flarum-0-1-0-beta-8-relea...

Or look at how clicking a submission on Reddit's new UI opens it in a floating modal window so that you don't lose track of where you are when you click out of it. It makes opening submissions feel cheaper/faster to me where, in the old UI, I tended to open everything up in a new tab.

There's a more thoughtful consideration that needs to be had here than just "webapp or website?" Else you're back to cargo-culting.

Re: None of my projects want to be SPAs

#182

Post by quonn »

bryanrasmussen wrote: post #158
hombre_fatal wrote: post #144

Earlier quoted context omitted.

Well, SPAs are attractive even for websites that don't particularly benefit from them because of the technical attractiveness of having the website be like any other client that consumes your server's API.

sure but there are very few websites in the world that need to publicize an api, basically only sites that need to be able to function as applications. once you have a site that needs to be an application arguing for it to be single page is not that great a leap.

If you have a mobile app, you need an API, even if you‘re site does not function as an application.

Re: None of my projects want to be SPAs

#183

Post by master_oogway »

freehunter wrote: post #151
rossdavidh wrote: post #108

This may be a mean thing to say, but basically I think SPA'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/Django/Laravel way, but that would not set you up as a developer w…

The other day I was arguing this exactly in a thread here about Ruby. People argue that Rails is outdated and is irrelevant for "modern web development", even though the web is not as modern as most people might think. Even what Facebook does, the only really hard part is the sheer scale they operate at. Facebook (the website) is not a single page app and other than the scale could be done in Rails with some AJAX spr…

In order to have dynamic UI you either have to use jQuery or SPA library like Vue or similar.

For me the major advantage of vuejs over jquery is the way data drives UI

Re: None of my projects want to be SPAs

#184

Post by kerkeslager »

joshuacc wrote: post #99
kerkeslager wrote: post #79

Back when I was doing React, what pulled me in was that it WASN'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. 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,…

> 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. Redux offers a few benefits: 1. Allows you to keep your global application state 100% predictable by treating it as a pure function of an event stream (dispatched actions). This makes it trivial to test. 2. Allows you to "time travel" the state of your store using…

1. You're conflating a bunch of terms here, but I think you're referring to global application state changes being treated as a pure function which takes in the global state and event parameters, and returns a new global state. There's nothing stopping you from doing that without Redux; the state = function(state, event) pattern is supported by native JavaScript. If that's not what you're talking about, please clarify.

2. This is only marginally more powerful than a debugger.

3. I would consider this allowing you to shoot yourself in the foot. Explicit is better than implicit, and explicitly defining your dependency tree is a benefit, not a downside. When you're feel the small pain of having to explicitly define a data dependency, that prevents you from introducing it if you don't have to, thereby avoiding the much larger pain of having an overly complex dependency graph. By adding Redux you're adding hours of debugging time on complex global dependencies to save yourself a few seconds worth of keystrokes.

Re: None of my projects want to be SPAs

#185

Post by WorldMaker »

kokokokoko wrote: post #127
joshuacc wrote: post #99

Earlier quoted context omitted.

> 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. Redux offers a few benefits: 1. Allows you to keep your global application state 100% predictable by treating it as a pure function of an event stream (dispatched actions). This makes it trivial to test. 2. Allows you to "time travel" the state of your store using…

I have yet to see a long term project built with Redux that was maintainable. That seems to be the common denominator in React projects that do not survive technical debt accumulation. The issue with Redux is that it encourages side effects in components. After a while people are dispatching all over the place and you end up in a similar situation as you were with keeping track of JavaScript events. All of a sudden s…

> The issue with Redux is that it encourages side effects in components.

Which is why a lot of people that encourage Redux tend to also encourage one or more of the "side effect" managers such as thunks, sagas, or observables (my preference).

Re: None of my projects want to be SPAs

#186

Post by kalcode »

kerkeslager wrote: post #115
WrtCdEvrydy wrote: post #102

Earlier quoted context omitted.

Server side rendering mounts your application in the server and sends down html along with an initial state. The client receives this initial state and uses it with the html to glue together a working UI on the client. This removes the massive JS bloat into raw html and split JS for each component. Instead of sending 3MB of JS, you send only the JS needed to render the current page... and send additional JS as a user…

Okay, but that's an even worse idea than what I've seen Redux used for. Now you're splitting the UI between client and server in a completely custom way, that adds even more complexity. Worse, the performance is likely to be worse because now you're paying the bulk JS load cost of loading Redux AND the latency cost of loading small parts as you go: the worst of both worlds. I doubt this is what the Redux folks had in…

>because now you're paying the bulk JS load cost of loading Redux

Gonna have to quantify that. Cause I imagine if you did, you'd redact that statement. Redux is a very straightforwards and SMALL library that handles global state.

Its concept can be difficult to follow at first which may cause some to think it way more complex under the hood than it really is.

Re: None of my projects want to be SPAs

#188

Post by geebee »

GVIrish wrote: post #180
rossdavidh wrote: post #108

This may be a mean thing to say, but basically I think SPA'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/Django/Laravel way, but that would not set you up as a developer w…

> This may be a mean thing to say, but basically I think SPA's are massively overused, because developers want to demonstrate that they can do them. Unfortunately this is another side effect of the broken hiring process in IT. Recruiters are scanning resumes for the hottest buzzwords, hiring managers want people who have experience with whatever is currently hyped, so developers naturally steer towards those technolo…

I agree. It's also not simply a matter of making more money on the next job, it can be a matter of having a next job.

Re: None of my projects want to be SPAs

#189

Post by jaredsohn »

master_oogway wrote: post #183
freehunter wrote: post #151

Earlier quoted context omitted.

The other day I was arguing this exactly in a thread here about Ruby. People argue that Rails is outdated and is irrelevant for "modern web development", even though the web is not as modern as most people might think. Even what Facebook does, the only really hard part is the sheer scale they operate at. Facebook (the website) is not a single page app and other than the scale could be done in Rails with some AJAX spr…

In order to have dynamic UI you either have to use jQuery or SPA library like Vue or similar. For me the major advantage of vuejs over jquery is the way data drives UI

Why do you need jQuery for this?

Re: None of my projects want to be SPAs

#190

Post by hombre_fatal »

Slartie wrote: post #152
repsilat wrote: post #140

Earlier quoted context omitted.

Does that help much? The distinction between "web app" and "web page" seems fuzzier than the question "would a SPA lib/framework be useful here?" Is Reddit a web app? Is Twitter? Facebook? They all started with server-generated HTML, all kinda feel "document-like", all of them involve scrolling (if that means anything.) Is the "app" boundary further along the chain, like at Google Docs? I think instead of trying to c…

None of them is a web app. All of them want to provide certain views on their content that are uniquely identified by their URLs. This is especially true for Twitter and Reddit, which both aim to have their views on tweets and threads to be indexed by search engines. Facebook is probably the least clear one, since they put great effort into eliminating discoverability and accessibility from "outside", i.e. without a…

Deep-linking URLs are available to SPAs as well, though.

I run a somewhat popular media site implemented as an endless-scrolling SPA. Clicking on an image or video opens its detail page in a floating modal and changes the URL. I specifically wanted people to be able to link to content this way, and my SPA will load that modal and the media-gallery behind it.

Quickly, SPA just becomes implementation detail. It's the level of user-interaction that dictates your implementation. For example, if you insist on your site being server-rendered with heavy Javascript that takes over, there may be a point where it would've been simpler for you to just implement it all in Javascript (the SPA).

I could've implemented my media site without Javascript. Or maybe just with AJAX that returns HTML. But I know from experience that, while simple upfront, those become more complicated as you try to build more interactive UX and starting wishing your Javascript had more access to the context. At which point a SPA is just another tool for managing client complexity in some other quadrant of the graph. But there's some nuance to the question of whether your site is or should also be in that quadrant.

Post reply on HN