Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a React Web App build (index.html) that is called using an Iframe.
Iframe is an expensive call and I tend not to use it.
But I was glad to find that it hides all React details from Chrome web tools.
I consider it as good security measure.
However, I lost the routing displayed as uri (I am using HashRouter).
Can anyone highlight more pros and cons for using or not using Iframe?
I wonder whether Iframe for React App is good or bad?
Note, similar question was asked - but not for Web Applications
Barring some other reason to do so, no, you would not want to do this.
The React devtools still work just fine, you just need to load the iFrame independently.
If exposing your compiled React app is a security concern you've done something wrong.
The contents of your iFrame are still available just like any other page.
An iFrame is not “an expensive call” — it's an HTML element that instructs a browser to render content from another resource. The overhead associated with an iFrame is higher than embedding content directly, but whether or not it's excessive or justified depends on the situation.
There's nothing wrong with DevTools. Frontend can't do harm to your website, especially if you build your React app in production. Also iframe takes time to load, so it is better not to use frames for React.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I know I could utilize client-side storage, cookies, WebSQL to make an app independent of the internet if the tablet/phone went offline for a bit. But at the end of the day if the user refreshes the browser, the site will try to load the HTML/CSS/JS and it's going to fail to load. I haven't been keeping up on HTML5 enhancements in the last year so I'm wondering if something like this exists. For instance specifically telling the browser to cache the static assets and use them again upon reload unless newer versions exist.
NOTE: I'm only interested in how to allow the page to go through a reload with the site offline if such thing exists.
I believe that #NickZuber has answer my question with his link. The thing I was looking for is
Application Cache
Works on most (90%+) modern browsers Best suited for storing
application code
The only option to reliably load a website from nothing offline
Can storage a significant amount of data (50mb+)
Very difficult use without causing unintended consequences for most
websites
Here is a working example of it in action. You can essentially turn off your internet, hit refresh on the browser, close the browser and re-open it. Whatever you want and the app loads up just fine complete with Images, CSS Styles, and Javascript.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have been searching across the Web to find a solution to this:
Basically what I want to setup is a way to have an HTML page on a live production site to kept updated. This is because I have setup a SilverStripe Application as part of a graphics system (green chroma key) that runs through normal HTML.
AJAX load doesn't seem to be an option here since the load would be every 1 second or half a second to make sure the page is live.
I looked into web socket quite vaguely but the whole concept of integrating it with my project confused me entirely.
Anyone got any ideas of what could be done?
To do this you'll need a combination of:
AJAX, you'll need to never do a full page load after the initial Web 1.0 request.
Session history management, you'll need this in order to not break the browser navigation (e.g. back/forward buttons).
Web Sockets, you'll need this so when new content arrives on the server it is received by the client without first having to poll the server.
Web sockets will be the greatest challenge. I listed them in the order in which you should approach the project, in three phases.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Our application shows pages with 90% static content. Clicking a link always generates another similar page. In fact, with the exception of a proposed ticker of some sort, nothing will change on the page once its rendered.
Recently, I've been asked to evaluate either EmberJS or ReactJS as the framework to use in our next version. We do have quite the logic on the server-side, and we can render templates much faster on the server, and cache the resulting HTML.
My question is: since my app is NOT an SPA, is there any benefit at all for client-side MVC? Or should I just handle everything (templates, routing, state management) on the server side?
If nothing will change on the page once its rendered probably a client side MVC framework is not what you are looking for. They are designed for rich web apps, these frameworks dynamically load resources to the page as necessary, as a response to user actions or route changes. In a SPA application the page does not reload during user interaction.
If you render a diff page every time a user clicks a link everything will be restarted, you can still implement an "hybrid" app and use these frameworks, they are not SPA exclusive, we have accomplished this functionality multiple times.
SPA is a hugely concept to grasp but you usually adopt libraries to handle aspects that are essential to your app, but seems that right now you do not have one.
I suggest to read this article from John Papa.
http://www.johnpapa.net/pageinspa/
Thanks
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a question about the design of a web application with JavaScript: Should a web application be designed to work without JavaScript, and then later add JavaScript for users that have it? Or should I design a web application with JavaScript in mind and then add fallback functionality for user that do not have JavaScript.
I hope this question makes sense. Let me know if you need me to clarify something.
Thanks.
The terms, that describe what you are looking for are "Progressive Enhancement" and "Graceful Degradation".
Here is good article describing what you already have in your question in more detail:
A List Apart: Understanding Progressive Enhancement
An article that could help you on your decision:
Dev.Opera: Graceful degradation versus progressive enhancement (The named reasons are still valid, despite the fact that the article is marked as outdated)
I favor progressive enhancement in most cases, since it is more accessible when it comes to different output devices, software and the capabilities of the user using that website.
Answers like "there are so few people with JavaScript disabled" are just one side of the medal. Not relying on JS also could improve your site experience to non-graphical clients like search engine robots (how should they load AJAX content, when that is only accessible via JS?) or screen reader software. In fact there are many more good reasons not to rely on on JS.
At this time of age there are so few people with javascript disabled, that there is no signifcant benefit for creating a static version. Try to imagine who is your visitor and if he/she would even know how to disable it.
I suggest you to design a web application with JavaScript in mind and then add fallback functionality for user that do not have JavaScript.
Now a days everything runs on JS only. You should create some kind of services/API on server side and a separate project for UI, this is the trend being followed these days.
UI project can be based on any JS framework or it can even be a simple MVC/.net project. This approach can decouple stuff, and thereafter you can create 2 UI projects one for JS users and one for the users who do not have JS.
seems a bit of a work but, it will pay in the long run.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We're relaunching the landing page of our company (contains an info, jobs, team and help section) and decided we'll no longer maintain a Rails project only for this part of our service and therefore switch to static HTML.
As we want to give our HR and support team the chance to edit the texts (especially in the jobs and help section) without bugging the dev team, we'll get an Angular.js app running on the page and patch in the content using a JSON APi (like the one Wordpress.com offers http://developer.wordpress.com/docs/api/ or we might even use https://www.contentful.com/).
However, as we need our landing page to load really fast (conversion is king), we're thinking of serving the initial part of our landing page as static HTML and gracefully add Angular.js after the user has access to the most important information. We don't care if people with deactivated JS can't use the rest of our page, therefore we'd call this process graceful improvement.
Are there any best practices and/or Angular.js modules out there for achieving what I just described? What's the right terminology for this effect?
P.S.: We'll take care of SEO by rendering the rest of our landing page (team, jobs, etc.) using Phantom.js, therefore SEO is not a topic. It's only about the loading speed of the initial part of our landing page.
You could render the static page (whichever way you want to produce those) and add an event listener after the page is loaded. Then in the event listener, you could leverage angular.bootstrap to start the app manually. That way Angular can take its sweet time about it and not bog down the user.