221–230 of 362 posts
Earlier quoted context omitted.
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?
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,…
I'm surprised you dislike Redux simply because it's a form of global state. Sure, global variables make debugging difficult when you don't know which function changed them where and when and why. But that doesn't happen if you keep your functions pure and only make changes from within reducers – at least that's my experience. (Boilerplate, yes, Redux adds that. But at least it's all in one place, and not scattered th…
If you keep your state in a component, you don't need any housekeeping, once the component is gone, the state is gone.
This is not true with Redux. You have to keep remembering to clean the state after you're done with something or you're going to introduce a bunch of bugs.
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.
> SPAs are attractive even for websites > having the website be like any other client that consumes your server's API. Did you fall hybernated sometime in the AJAX era? Now it's state synchronization over GraphQL run on dockerized autoscaling cluster. Satan only knows perhaps how to make that retarded bastard to work in a web browser. I have yet to encounter a backend/system developer who doesn't consider designing a…
I'm not sure what you meant with the rest of your post. There are technical upsides to having zero web client presentation logic implemented on the server at all. But it's just trade-offs.
Maybe you're suggesting with your "grunt work" comment that most complexity for most applications lives in the UI rather than the API? I'd agree. It's why there are upsides to keeping UI implementation off the server.
I just like to avoid the HN cargo cults of "this = good, that = bad" and "the people who do $X are probably incompetent."
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 often have "What the hell is this thing doing" moments as a web app hangs trying to complete a round trip over my mobile connection when I know it has already fetched the information on that page or I know it could be doing something useful despite not being able to connect.
The author is not proclaiming that SPAs are a bad idea. He'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:
Why does a website that orders food from restaurants need a Megabyte of javascript?
I tried to figure that out by inspecting the API calls. It turned out they were tracking every mouse event.
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.
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). [1] https://github.com/turbolinks/turbolinks
this is not just one simple drop in replacement, well it is if you load only html, but pages are usually html + js, even for "old" mvc. so because there is no page relaod you have to rethink all your events, objects and so on. so if i have to rewrite my js with this just so i could fake SPA then benefits are so much smaller
Is SPA with unique-urls (think angular-routing) still a SPA ? Most of my websites+apps are done using Angular/PWA.
Earlier quoted context omitted.
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…
> I have yet to see a long term project built with Redux that was maintainable. The only maintainable projects I have worked on in terms of web apps have been with Redux. Redux is not great for simple projects, it is great for medium and large scale projects. > All of a sudden something stops working because someone removes a component that is dispatching on a timed interval etc. That's the problem: react and redux a…
Earlier quoted context omitted.
Why use a tool to solve a problem with another tool, rather than using tools that don't have the problem in the first place?
Because I decided I like React? :P From my perspective, React is the thing with the problem: it doesn't have great state management for complex tasks / multi-component coordination. What I want to use is something like RxJS to manage such interactions and state, because it gives me a lot of power/control in a relatively easy way. One of the best options out there that I've seen is redux-observable, and thus Redux its…
The observer pattern is mentioned in the Gang of Four Book[1], published in 1994. JavaScript first appeared in 1995. Observers predate Redux. You don't need Redux to use observers, and in fact there's nothing about React that is incompatible with RxJS.
> It's also the Unix philosophy thing of use tools that "do one thing well" and then chain them together. React does view components rather well, Redux does state management rather well, Redux-Observable does state "interaction" rather well. Chained together they work remarkably well.
Don't sully UNIX philosophy by comparing it to Redux! UNIX is such a different environment from JS space that it's hard to really even compare the two, but at the very least I think we can agree that "Doing one thing well" in UNIX means not creating a bunch of new problems that you need other tools to solve.
[1] https://www.amazon.com/Design-Patterns-Object-Oriented-Addis...
Earlier quoted context omitted.
Why use a tool to solve a problem with another tool, rather than using tools that don't have the problem in the first place?
Because I decided I like React? :P From my perspective, React is the thing with the problem: it doesn't have great state management for complex tasks / multi-component coordination. What I want to use is something like RxJS to manage such interactions and state, because it gives me a lot of power/control in a relatively easy way. One of the best options out there that I've seen is redux-observable, and thus Redux its…
I liked it more than redux, because you can have have simple class implementation and side effects without much hassle. Also TS support and testing is easy.