Earlier quoted context omitted.
> built last year after the react prototype was to slow on old devices: Do you have a public implementation available for review? I'm having trouble understanding why this would be the case (I am pretty familiar with React's implementation). >Render all pages/routes/states into a single html file (size ~2mb) That's not good at all for mobile web pages.
This is one page/app I built that way [0]. In this particular case it's not even fully optimized (eg js and css not minified, loads some external images...) [0] https://app.ishl.eu/
None of my projects want to be SPAs
251–260 of 362 posts
Re: None of my projects want to be SPAs
#252Do we really need to defend SPA every other week? The market, users, product, ui/ux designers and the vast majority of developers decided that SPA is a better user experience. 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). Even if you make your site extremely lean, it's still a worse experience, an…
The phrase, "the exception that proves the rule" is not used properly here. A proper example is something like: "Parking allowed on Fridays", which is an exceptional case to a rule that is implied: "No parking any other days." Just a heads up, feel free to ignore.
If we are going by wikipedia definitions, then: "A rural village is "always" quiet. A local farmer rents his fields to a rock festival, which disturbs the quiet. In this example, saying "the exception proves the rule" is literally incorrect, but it is used to draw attention to the rarity of the exception, and to establish the status of the village prior to the exceptional event. "
Re: None of my projects want to be SPAs
#253This 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 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. Absolutely. This extends well beyond SPAs, too, in my experience. I recently burned part of a month explaining to my senior management chain why you don't just, literally, "do machine learning." Of course, it turns o…
[1] https://www.informationweek.com/big-data/ai-machine-learning...
Re: None of my projects want to be SPAs
#254Earlier 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…
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/17…
https://www.talkyard.io/-32/how-hacker-news-can-be-improved-...
Re: None of my projects want to be SPAs
#255Earlier quoted context omitted.
Unfortunately for most devs, the only way to set yourself up for "better" work later, is to force current mediocre work to use the tooling of the future work. In 2019 if you have on your resume that you're only familiar with Rails and ERB-sites, and you suggest using them for pretty much everything, you'll never get a new job. At a certain point, career-minded devs have to do the "resume driven development" game a li…
Depends pretty much where one wants to work. Outside the software business, on companies whose focus is totally unrelated to software, no one cares that much how things work. They just have a couple of devs, or hire some freelancers do do some stuff, no matter how, it just has to look pretty.
Re: None of my projects want to be SPAs
#256For 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
Compare this with rewriting your app as an SPA.
Re: None of my projects want to be SPAs
#257Earlier quoted context omitted.
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.
stdin/stdout/stderr may be redirected during the lifetime of a program. The OS manages them and they are "reference pointers" (file handles) for multiple reasons. 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 th…
> Also, "state" does not necessarily imply "mutable".
Okay, sure. I'd rather not get into a semantic argument about the meaning of the word "state". Suffice it to say that I'm talking about mutable global state.
Re: None of my projects want to be SPAs
#258Another angle is that "SPAs" are build on top of a fragile and anti-engineering tech stack: JS, CSS, HTML. In the past a 'SPAs' 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 "right tool for the job" and will never will, without serious re-engineering.
Re: None of my projects want to be SPAs
#259Earlier 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?
The problem that you end up with past a certain scale in a component-based app without a state management framework (third party or your own) is that you're performing business logic inside view components. By moving your business logic into your state management framework and using something like redux-saga that is designed specifically for managing complex asynchronous workflows, you can extract your application co…
I respectfully disagree here. All UI views in React can be controlled via parameters. Very few components in a React application require state management. You can add parameter functions to handle various events as well.
> which allows you to use equality comparison instead of a deep compare to see what state has changed
You are doing a lot of deep compares on state in a real world application? Why? If you only use parameters for the state of your component, everything is already handled by React out of the box.
> every slice of the state can only be managed by a single, pure function
Really? You can trigger reducers from literally anywhere in your application. Not only that, you can create multiple reducers to handle each action type. I've seen a situation with 24(yup, 24) reducer functions for a single action type. Many of those reducers contained complex business logic checking the overall state of the application. Then you have 2 or 3 action functions all with different business logic for that one type. Race conditions everywhere. setTimeout 0, here we go again. Step debugger hell. Of course, you should never do this, but in the real world, this is what happens over and over again.
> means unit testing your state transitions is almost laughably trivial
If you use parameters for state of a component it is 1,000 times easier. Because a component's view is not coupled to the global state of your application. Pass it parameters, test that it looks correct. Change a parameter, check if it is correct. Dead simple. Your tests are not bound to global state at all. Again, you started with an anti-pattern of managing state in child components, and now, instead of not doing the anti-pattern, you are adding yet another tool to fix it. Instead of just not doing it.
In summary, what you are describing is the "theory" of why Redux and associated tools should work. In every case that I've seen(10+ at this point) that has not happened. Not because Redux is a bad tool. Its not. But in the real world, it has become incredibly expensive for many organizations to maintain.
Re: None of my projects want to be SPAs
#260I 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'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.