271–280 of 522 posts
Not very convincing. React was introduced in 2013 and angular 2 was created in 2015. The only server side rendering I'll be doing in the future is with the likes of nextjs or similar.
Earlier quoted context omitted.
With gmail: Move your mouse pointer down to the lower right corner of the tab. Do a forced refresh (Ctrl+f5) and you'll see some text pop up while it's loading, one of which is a link to a basic HTML version of the site. Click on it and you're back to what appears to be almost the original gmail interface. Up the top of the page you'll see an option to make it default. It's super fast. Almost absurdly so, compared to…
There's also a hidden 'mobile webapp' version: https://mail.google.com/mail/mu/mp/167/?mui=ca#tl/Inbox
>Offline unavailable.
>The browser you are using is missing some features required to enable offline. To enable offline, you must use Chrome with version 61 or higher.
This. So much this. My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful. Prior to that initiative, we had been using the hybrid approach mentioned in this piece, embedding SPAs only where necessary and sticking to SSR everywhere else, which worked really well. Since the a…
Sorry, I don't have the complete context - SSR stack, app architecture, load times etc. So, I'm not in a position to comment on your SPA migration. But, I'd like to share thoughts from my current situation. We have a flagship product written in web forms (started in 2006). It's a big solution. Performance has always been a challenge with it. While I'm not proposing a complete rewrite into SPA, due to - migration requ…
If I understand your approach correctly, I often do something similar, but with modern ASP.NET Core MVC apps. Basically, I have a tiny bit of JavaScript that 'intercepts' all form POSTs and submits them using AJAX instead. Another tiny bit of JavaScript can then process the result and do something (update a table, display a message, redirect, whatever).
I feel like this gives me the best of both worlds - the backend is very testable, and really straightforward for new developers to come up to speed on, while at the same time we remove a lot of full-page renders.
You can find an example of this technique here[0]
I tried the other day, yet again, to give it a go. You know, firing up VS Code and make an app with express, node, react bla bla bla. Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. The hundreds of possible directions you can go in, in terms of frameworks, packages and what not is ludacris. I stopped working when my node modules directory topped…
You probably don't need a single-page app, right up to the point where it's a business requirement and you have to translate a GB worth of convoluted JSPs into one because the client likes smoothness in their flows, continuous saving, and all those nicely choreographed state transitions you just cannot get without having a framework hijack the History and File APIs from the browser's paws. Yes, a nice state machine-l…
> smoothness in their flows ...what? > continuous saving No problem. > and all those nicely choreographed state transitions Learn to say "no." It works wonders whenever people tell you that your aircraft has to go under water now.
Good luck keeping that client after the end of your contract.
This. So much this. My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful. Prior to that initiative, we had been using the hybrid approach mentioned in this piece, embedding SPAs only where necessary and sticking to SSR everywhere else, which worked really well. Since the a…
Agree with the article. I find server views to be substantially easier to work with. But more importantly, I also find server view rendering to be a faster, better UI experience. It's really frustrating having to wait several seconds for a SPA to load, or to have unexpected behavior when clicking the browser back button, or failing completely because some random hunk of JS garbage errored out, and it's one of the big…
It was nice and would still be nice if browser caching meant a site still worked well over a bad connection. But you can be browsing around a "static" site and hit the back button and be stuck staring at an empty or partly rendered page waiting for your flaky connection to load the page.
SPAs handle that situation better even for sites that are theoretically not suited for SPAs. The simple principle of doing your best to display the data you've already fetched is extremely refreshing compared to supposedly "document-oriented" sites, which typically take the opposite approach -- we showed you this page fifteen seconds ago, but we can't show it to you again until we exchange a few megabytes of data with headquarters. And now we can't show you the other page, either. Just be patient. If it's really that important you should have taken a screenshot, mmmkay?
(Slow-loading web sites are the main reason my not-so-tech-savvy family members, who are very stubborn and selective about learning anything, are all adept at taking screenshots on their phones. When it comes to information they might need later, they take screenshots, because you can't just leave a page open and trust it to be there when you need it. You might accidentally trigger some navigation and then who knows how long it will take to get back to the information they need, if it's even possible.)
Browser caching should theoretically let a document-oriented web site work smoothly over a flaky connection, as long as you stick to the pages you've already viewed, right? But how often does it help even a little bit? Maybe SPAs will eventually be just as broken, but right now it seems damned cool that they make a good-faith effort to show me stuff.
Earlier quoted context omitted.
I would rather change a page if and when it is needed by a new feature than over engineer up front.
And I would rather over-engineer a bit now to make feature additions trivial & rewrites unnecessary. Different stroke for different folks, I guess.
Earlier quoted context omitted.
It doesn't often happen because of Conway's law - that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." Its always possible to architect the web/app back end to do everything through APIs, keeping the APIs pure, and ensuring that others will be able to build UIs on top of them. But in many organizations the same people…
IMO it's one of the long-term failures of web architecture for CRUD that there isn't a unified solution for this; not only should they be the same team but they should be in the same repo, quite possibly in the same language, and the number of places a field has to be defined should be as small as possible. Let the machine sort out separation of concerns and what code goes where. Learn something from dBase and FoxPro…
1. One language - JavaScript
2. One repo - containing a Node backend, also builds/serves a front end bundle (alternatively use Next.js/etc if SSR is your thing)
3. Use GraphQL schemas to handle your API(s) and consume the minimum necessary data on the client, reduce redundant field declarations
One language, one repo, easy & consistent API production/consumption, no?