I would like to build an app using Webcomponents , but I'm wondering whether that means that I cannot use server side rendering (for the web components=, unless I use some headless browser such as puppeteer. Since I mainly want to use SSR for performance reasons,using a headless browser does not look like a good option to me.
Skatejs attempted to render web components server side, but I cannot get the example working.
https://github.com/skatejs/skatejs/issues/1576
It also looks like skatejs has not been maintained since a while and might therefore not be a good option anyway.
Is rendering web-components server side without a headless browser really feasible as of today?
Related
...Or are both used in tandem for each of their distinct features?
I have been trying to figure out why server side scripting is different that running a compiled program to handle web requests. I would really appreciate an example of the usefulness/use of server side scripting that makes it necessary.
I read this about ASP (I've been using ASP.Net without knowing much about it): "When a browser requests an ASP file, the server passes the request to the ASP engine which reads the ASP file and executes the server scripts in the file". I understand that this has something to do with customizing an html file with user data that was passed with the request for the ASP page (and the server-side scripts can/are kept secret by nature from the client). ->
Is this why server side scripting is used: it is easier to edit a dom with embedded dom editing scripting languages that were created for such purposes rather than use a compiled program that takes variables from a client to edit a dom on the server side?
Thanks
Well some systems do use script languages that run sever side.
And no, asp.net server side code does not run any of the JavaScript you have server side.
When you click on a asp.net button? the web page is sent to server. Then code behind runs, and then it is rendered and sent down to the client. So when you talk about code behind? You are talking about C# or vb.net code.
There is next to zero reason to try and run some scripting code server side. JavaScript is desinged and runs 100% in the browser, and thus is designed to run say without a compiler.
The advantage of client side Scripting? Well it runs 100% on the client computer, and thus no round trip or post back is required. So for a fast windows like experiance? Well, you start to adopt more and more client side code. The reason then is that the client software running in the browser can feel, respond very much like a windows desktop program.
So we see the rise of technologes like say ajax. This means that you still run browser side code, but that browser side code can now make "tiny" or "smaller" calls to the web server. And in some cases asp.net can and will setup + inject some browser side code for you. For example, when you drop in a few text boxes, and then drop in a asp.net validator? Well note how fast and instant these validators work. (they work without a round trip! and without a post back!). So when you drop in these validoators into that web page? Asp.net will write and automatic generate the JavaScript to run in the client browser for you.
So, in asp.net, there would be little gain and benefit to use a scripting language to run server side when that code can (and should) run all great in the browser. And who would want to give up a great IDE and development language like c# or vb.net, and have to write in some difficult language like JavaScript?
But because we want more and more "responsive" applications that run in a browser? Then more and more effort is being spent on this simple question:
How can we have more and more code and logic run 100% in the browser, since then that means the user interaction will occur 100% local, and without having to hit the server. This not only reduces the server workload, but also means that the response time becomes more and more like a desktop program. The advent of ajax and other approaches means that you can now run a spreadsheet 100% in a browser.
And what do you think all the hub-bub is about blazer? In a nutshell, blazer is simply a technology that allows say your server side c# code to now be written to run 100% in the client browser. The advanage of this means not only do you get to write in one language, but now that c# code can run either server side, or browser side. Again, this concept is a attempt to allowing developers to push more and more code down to the browser to run in place of code having to run server side. Now server side code is not a bad thing, but if you require a post back or sending the web page up to the server for that code to run? Well, then it takes time, and thus you don't get a fantastic interactive web application like you do say with 100% desktop software.
In fact the interaction we now have available with a combination of web side and server side code? Well, we have the ability to create a really fantastic user experience, and now web applications can run, feel and respond just as good as what a typical desktop application can achieve, but requires no software install.
So at the end of the day? No, there is little reason to want to run some Scripting code server side. And in the case of asp.net? None of your JavaScript code does run server side - it quite much used for code that runs in the browser.
There are few reasons to want or have Scripting code run server side. This really all comes down to how the web works. But if you can push more and mode code to the client side? Then you will. And as the tools get better and better? Well, they allow more and more code with greater ease to be run in the browser side. (that's what blazer is all about).
So, if you write a cute tic tac toe game? Well, you could write it 100% to run browser side. And that means zero load and stress on the web site. And it also means that the user gets a desktop like user experience. (and in fact they ARE running that game 100% with browser side code).
So just keep in mind, that none of your JavaScript in asp.net runs server side - that js is used for code and interaction that runs in the browser side - and thus does not need some post back or even to talk with the server. However, you can call say a sub or function you do have in that web page (with a js ajax call).
So it not necessary easier to use/change/edit parts of the DOM server side or client side. But hey, if you CAN do that editing or changes 100% client side, then you should, as then you not need to talk to the server. However, the client side code does not have nor allow you to do things like say write a sql query, and fill a table. It needs to talk to the server to do that. And thus you can use your really great server side coding system to pull that data. And the other issue is security. If I can write some browser code to pull data from a datbase? Well, then i will go hit amazon.com and steal all their data!
So, JavaScript is VERY limited. It can't do things like say go and grab a file on your disk drive and up-load it to the server. If you could do that, then when you visit my side, I would run some code to grab your outlook or even some spreadsheet called passwords.xls and upload it. So for reasons of security, the code that runs in the browser BETTER be VERY limited in what resources and things it can do on your computer - else it too big of a security risk. But computer running on my web site and my server? Well, I want that code to do anything, including things like process your credit card or have use of say banking information.
When loaded a PWA (Progressive Web App) inside a iframe, it will work normal (saving Web Workers, offline availability, etc) or some features will be blocked?
I have a PWA that uses an iframe. It uses some pretty advanced features, including a web-worker (in addition to the service worker) that I implemented long before recently porting it over to a PWA. All of those features work the same, with the additional benefit of controlled caching of specified resources. I haven't seen anything in the documentation to suggest otherwise, and can honestly say it works amazing! So fast to load now, it's in the app drawer, etc., even installs and looks like a normal app on desktop. My only issue is the soft-keyboard overlaps in fullscreen, but there is a solution, I've seen it work.
My suggestion-- try it. It's pretty easy to set up. Test your features. I am sure you will be impressed.
I was reading about advantages of PWAs, but I really can't understand why we have to use this technology. Is this similar to SPA? Or this is completely something else?
A Single Page Application (SPA) can be a Progressive Web App (PWA) but a PWA doesn't need to be a SPA. They are two different things. A PWA as defined by Google is:
Reliable - Load instantly and never show the downasaur, even in uncertain network conditions.
Fast - Respond quickly to user interactions with silky smooth animations and no janky scrolling.
Engaging - Feel like a natural app on the device, with an immersive user experience.
The Google PWA site is a good place to start learning about PWA and why and how you would build one.
https://developers.google.com/web/progressive-web-apps/
A SPA is simply a web app where a single page is loaded in the browser and all subsequent routing and page view rendering is handled on the client (browser) using JavaScript.
Properly combining the principles of PWA and SPA can result in a much improved user experience especially on mobile phones with unreliable internet connections.
Probably the best example today of a well implemented PWA is Twitter Lite. Check it out here:
https://mobile.twitter.com/home
...and read about it here:
https://blog.twitter.com/en_us/topics/product/2017/introducing-twitter-lite.html
A SPA is something different than a PWA. You can view PWA as an enhancement of your website. By adding a service worker and a manifest you can bring your website (SPA or not) out of the browser, work like a mobile app and make it perform better.
Recently we have started using Meteor for our apps, but we didn't want to use same layout for all mobile (android and ios) and browser views.
Is there any best way or good practices to build different layouts for multiple platforms without having to duplicate all /server and packages again in different projects? I mean, keeping everything on same place?
I assume you don't have to duplicate the server or anything else but the client folder content. The way I understand it, as long as you use a meteor client, the server side is agnostic of what the client specifically is.
Let's say you want a desktop bootstrap version of your app, and an ionic version for mobile. You just need to route the client on the right client subfolder (bootstrap or ionic) in the Meteor startup code for client depending on their user agent.
Unless you plan to use dedicated servers for each (meaning it would be like two different apps connecting to the same mongo database) there is no way to split everything in two versions and keep it as a single app (i.e. both mobile and desktop clients are handled by the same meteor server process).
Bottom-line: if, after evaluating it, you consider that the delta in the amount of client side code sent is two big between a dedicated version and a multipurpose version (or to rephrase it, the useless packages weight too much), then make two different servers and handle the redirection in a third. If not, keep two different clients working with the same server
I'm looking for a templating library, similar to JsRender, that runs server side on .NET.
Mustache is a non-starter, because it's mostly logic-less. We need something with functionality similar to {{if}}, {{else}}, {{for array}}, and the ability to call custom functions within the template.
In theory, I could probably use JsRender on the server by reading output from WatiN or any other .NET headless browser... but I thought I'd put the question out there in case I can bypass the headless browser part.
Any ideas?