11–20 of 21 posts
And the first load issue can be circumvented with pre-rendering the first page on the server.
I tried this with React and it worked like a charm. It even went so far, that the whole page doubled for SPA and complete-server-side app, when JS was deactivated.
Earlier quoted context omitted.
I feel like Web Workers have been a HUGE help in this regard.
I don't know if that's true. I read that the workers can't get font measurements, which prevents layouting on webworkers.
I use it on the first page load so that I can get all of the data I need for most of the routing upfront so that I don't need to perform an AJAX request for every state change. I was originally having the server render JSON inline with HTML but Web Workers ended up being faster.
Curious, how are Web workers helping you counter UI Thrashing?
Initially, I was having the server load up large JSON objects inline with the DOM so that I could avoid doing multiple AJAX calls. This worked with 2 very large JSON Objects, but as soon as I hit 3, the page would have a noticeable jank trying to evaluate these JSON Objects and render the page.
I remembered this article from Hacker News a while back (http://www.pocketjavascript.com/blog/2015/11/23/introducing-...) and started using Web Workers based on the speed of the app (it's pretty fast, check it out pokedex.org). There was a HUGE difference with having that first initial page load with the AJAX calls in the background. The only thing I would recommend is that you should make your first page load not contingent upon any AJAX calls or any loops (ng-repeat in the case of Angular). This will allow you to load in the page without having to wait for any response from the server and usually, the page will load alongside the data retrieved from the Web Workers.
In my experience SPA load rather fast. Only the first load and some crazy animations are really an issue. And the first load issue can be circumvented with pre-rendering the first page on the server. I tried this with React and it worked like a charm. It even went so far, that the whole page doubled for SPA and complete-server-side app, when JS was deactivated.
- Angular doesn't enforce a convention. This gives you flexibility at the cost of zero convention. Developers tend to abuse this flexibility "because they can do it this way instead of that". Choose a convention among all the methods possible, then stick with it. - Angular can be hard to debug when using some architectures. Two-way binding is pretty hard to track down. Scope inheritance is also a pain, especially wit…
- Nailed it on this comment. I have been trying to figure out something that "makes sense" in terms of file structure and even code organization. So far, it hasn't been too much of a hindrance, but it I know the more code I write, the more unwieldy things will probably get.
- This is something that I have been very aware of and the way I have been handling it is limiting the number of controllers in general so I do not introduce new scopes. For the most part, all of the pages do not need to introduce new scopes and the data should be consistent across the pages anyways, so this hasn't been too much of an issue (yet).
-I haven't had this issue yet, but I haven't sufficiently tested this. From some initial testing, the memory footprint has been pretty light, but I need to do a lot more on this end once I have completed more of the app.
-State management hasn't been too tricky because there's only two states that I really care about: whether a user has logged in or if they are logged off. This part I have been addressing by loading JSON for contact information into the page to both limit the amount of AJAX requests and to enforce routing. Fortunately, this state is also managed by HTTPS Cookies so this is handled server side as well.
-I don't know how to validate or dispute this, but it looks like loading the minified scripts from CDNJS for both Angular and React were the same filesize. In any case, I have been using A LOT of what comes with Angular out of the box and have been using the UI Router library as well as the ng-Sanitize library for what I need. Haven't had too many issues with this.
Speaking as a backend dev who generally avoids writing client-side code, the biggest problem that I've had is figuring out the "right" way to build the fucking thing. The JS fatigue is real.
Speaking as a backend dev who generally avoids writing client-side code, the biggest problem that I've had is figuring out the "right" way to build the fucking thing. The JS fatigue is real.
What kind of stack are you working with? Honestly, this isn't the first time I tried building this on the site that we have, but this has been the farthest I have gotten without UI jank or slow initial loading. I would have much preferred to use Mithril, but I couldn't get the routing how I liked it; this is more of how the server is set up which I have limited access to.
Earlier quoted context omitted.
What kind of stack are you working with? Honestly, this isn't the first time I tried building this on the site that we have, but this has been the farthest I have gotten without UI jank or slow initial loading. I would have much preferred to use Mithril, but I couldn't get the routing how I liked it; this is more of how the server is set up which I have limited access to.
Been looking at Ember, Angular 2, and Backbone + React. It's all just such a CF though. I was reasonably okay at Angular 1.x apps, but the learning curve is just so steep with these new frameworks that I don't even know where to begin. I've been making okay progress with Backbone and straight jQuery, but jQuery is slow and huge, so I'm slowly coming around to the idea of replacing it with something else.
Earlier quoted context omitted.
What kind of stack are you working with? Honestly, this isn't the first time I tried building this on the site that we have, but this has been the farthest I have gotten without UI jank or slow initial loading. I would have much preferred to use Mithril, but I couldn't get the routing how I liked it; this is more of how the server is set up which I have limited access to.
Been looking at Ember, Angular 2, and Backbone + React. It's all just such a CF though. I was reasonably okay at Angular 1.x apps, but the learning curve is just so steep with these new frameworks that I don't even know where to begin. I've been making okay progress with Backbone and straight jQuery, but jQuery is slow and huge, so I'm slowly coming around to the idea of replacing it with something else.
In my experience SPA load rather fast. Only the first load and some crazy animations are really an issue. And the first load issue can be circumvented with pre-rendering the first page on the server. I tried this with React and it worked like a charm. It even went so far, that the whole page doubled for SPA and complete-server-side app, when JS was deactivated.
That sounds really cool! How simple/difficult was it to set up the prerendering and what kind of stack are you running?
The client needs to use the same data or else it will throw away the whole markup and re-render it.
Fetch the data on the server before you render.
Render the (static) markup with React and the data.
Send the markup AND the (serialized) data to the client.
The client will render the markup normally before React kicks in.
The client React then needs a way to use the serialized data with the pre-rendered markup.
Redux, for example, is a way to pass down this data to every component, so it's available at render.
Normally, when writing React apps, you can simply load data async and show a place-holder while the request runs.
If you want to render on server, all the data has to be fetched before, if it's loaded async, so the server can render synchronously.