2 ms·
you have to setup and maintain this separate proxy and headless browser. This is surely more complicated than outputting html from your web app.
by jshen 17y ago
you have to setup and maintain this separate proxy and headless browser. This is surely more complicated than outputting html from your web app.
- kls 17y agoNot if you are supporting multipal clients and want to seperate out your concerns. The point is that the UI should be decoupled from your core application logic. The advantages that brings, negates the few hours one will spend setting up an out of the box server and proxy to support SEO. There are many web apps that don't even have SEO as a problem domain.
- jshen 17y agoYou are arguing that this approach is better, therefor it isn't more complicated. You realize that isn't valid logic, right?
- kls 17y agoNo I am arguing that setting up a route based on an agent does not require custom logic and therefore removes the problem from a development issue. It would be just as valid to argue that a fire-walled web environment is more complicated than one that is not fire-walled, while true it ignores a host of realities, but it is accepted that the advantages of security outweigh the complexity of a firewall. What I am saying is that much like a firewall, it is a task of configuration and not custom development and therefore given its ease of implementation, the advantages outweigh the marginal complexity (I am arguing that it is marginal) that it brings. As well, I am arguing that much like a firewall ejecting this problem domain out of the application, creates a simpler solution. You can implement access security in your application, but it is commonly accepted that rolling your own is a bad idea. The advantages of dynamic user applications are clear and I am arguing that those advantage clearly outweigh the need for this simple solution, if SEO is even a problem domain of your application, it is not for some.