191–200 of 362 posts
Earlier quoted context omitted.
sure, although modern browser apis mean the url bar can change in a reasonable way
What about tabs? SPA can make tabs troublesome. If I can't open a site in tabs it is broken to me.
Earlier quoted context omitted.
You have information which has global nature, used in multiple sorts of the application. This could be, among other things - STDIN/STDOUT/STDERR file handles - static configuration - some parts of runtime configuration - application info (in a game maybe current score, current level, active players, ...) All that information exists only once and is needed in many parts.
Okay, I think we're talking about different things. I don't think of stdin/stdout/stderr or static configuration as state because they don't change. Typically when I talk about state, I'm talking about mutable data that may change over the lifetime of a program.
Also, "state" does not necessarily imply "mutable". (Redux encourages an immutable state approach where good reducers don't mutate state in place, but instead build new state from old, though Redux is not strict in enforcing this best practice. For Redux the "current state" is "file handle" that simply updates from one object to the next, not all that different from stdin/stdout/stderr or even somewhat to static configuration that is somewhat updateable without restarting the application.)
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…
But in reality most work is very simple. Most work does not require new shiny technology. Most work is insanely mundane.
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 have to let you in on a big secret. State has always been global. Have you ever worked on an application backed by an RDBMS? Redux simply moves state. It doesn’t expose it any more than a database.
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…
So far every way of doing UI I have seen isn't maintainable long term. Yet somehow things wind up being maintained even if it is in that "why me?" kind of way.
I think this says less about frameworks/libraries themselves and more about the amount and sources of entropy present in the front-end. That's really what we're dealing with here.
Libraries/tools/patterns/frameworks all usually have the function of containing some of that entropy. In theory the best tool contains the most entropy while allowing you to produce results you can sell to all stakeholders.
I think over the years we are doing better and better, but it's a long game. We're not all the way there yet, is it even possible to get all the way to the dream?
Earlier quoted context omitted.
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.
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…
The problem with that is, blogs are a poor barometer for that sort of thing. Nobody needs to write new blog posts about tried-and-true things that are already plenty well documented. The more solid and stable a technology is, the less incentive there is for anyone to bother writing how-to blogs about it.
Earlier quoted context omitted.
I recently started a hobby project and initially went with a JS solution. But when I had to start deciding on auth, maybe an orm, routing, db layer, and templating, I said fuck it and installed Rails. Previously I had never built a real product in Rails, only the book store tutorial. I'm really happy with Rails so far. I don't have to worry about a lot of shit I had to worry about in JS land and now I can focus on th…
As you're doing Rails I recommend you check out Stimulus JS ( https://stimulusjs.org/ ). I've installed it in a recently project (Rails 6, rake webpacker:install:stimulus) and it's like a breath of fresh air. Totally gets out of your way, but lets you add behaviour to your app as you need it.
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…
I remember a while back I wrote a blog post where the main topic was "You're not Google (unless you're Google)"[0]. It was related to micro-services but the same thing applies to SPAs too.
[0]: https://nickjanetakis.com/blog/microservices-are-something-y...
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…
I'd say that the only times I've seen Redux work effectively at all is when the project was small enough that the complexity remained manageable.
> > 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 are not enough for large projects, you also need a way to manage side-effects. Incorporating `redux-saga` would fit that purpose.
I don't need a way to manage side-effects, if I don't use Redux...
I'll admit I haven't used Redux-Saga, but you'll excuse me being skeptical that introducing more complex tools will solve my complexity problem.
> We did this at my last company: because our business logic was based on redux and completely separate from the UI layer: we were able to build: a cli, chrome extension, outlook plugin, and mobile apps using the same exact business logic.
Again, this is not unique to Redux. It's perfectly possible to have your business logic completely separate from the UI layer without Redux. In fact, my experience is that Redux tends to cause devs to mix UI logic into business logic (and any sufficiently complex UI will have its own state and logic separate from the business logic).