Develop Reference

Difference between WebApp that connects to API vs backend rendering

Sometimes when I create basic web tools, I will start with a nodeJS backend, typically creating an API server with ExpressJS. When certain routes are hit, the server responds by rendering the HTML from EJS using the live state of the connection and then sends it over to the browser.
This app will typically expose a directory for the public static resources and will serve those as well. I imagine this creates a lot of overhead for this form of web app, but I'm not sure.
Other times I will start with an API (which could be the exact same nodeJS structure, with no HTML rendering, just state management and API exposure) and I will build an Angular2 or other HTML web page that will connect to the API, load in information on load, and populate the data in the page.
These pages tend to rely on a lot of AJAX calls and jQuery in order to refresh angular components after a bunch of async callbacks get triggered. In this structure, I'll use a web server like Apache to serve all the files and define the routes, and the JS in the web pages will do the rest.
What are the overall strengths and weaknesses of both? And why should I use one strategy versus the other? Are they both viable and dependent upon scale and use? I imagine horizontal scaling with load balancers could work in both situations.

There is no good or bad approach you could choose. Each of the approaches you described above have some advantages and you need to decide which one suits best to your project.
Some points that you might consider:
Server-side processing
Security - You dont have to expose sensitive information (API tokens, logins etc).
More control - You will have more control over what you do with your resources
"Better" client support - Some clients (IE) do not support same things as the others. Rendering HTML on the server rather than manipulating it on client will give you more support for clients.
It can be simpler to pre-render your resources on server rather than dealing with asynchronous approach on client.
SEO, social sharing etc. - How your server sends resources, thats how bots see them. If you pre-render everything on the server bot will be able to scrape your site, tag it etc. If you do it on the client, it will just see non-processed page. That being said, there are ways to work around that.
Client-side processing
Waiting times. Doing stuff on the client-side will improve your load times. But be careful not to do too many things since JS is single-threaded and heavy stuff will block your UI.
CDN - you can serve static resources (HTML, CSS, JS etc) from CDN which will be much faster than serving them from your server app directly
Testing - It is easy to mock backend server when testing your UI.
Client is a front-end for particular application/device etc. The more logic you put into client, the more code you will have to replicate across different clients. Therefore if you plan to have mobile app, it will be better to have collection of APIs to call rather than including your logic in the client.
Security - Whatever runs on the client can be fully read by the client. No matter how much you minify, compress, encrypt everything a resourceful person will always be able to do whatever he wants with your code
I did not mark pro/con on each point on purpose because it is up to you to decide which it is.
This list could go on and on, I didn't want to think about more points because it is very subjective, and in the end it depends on the developer and the application.
I personally tend to choose "client making ajax requests" approach or blend of both - pre-render something on the server and client takes care of rest. Be careful with the latter though as it will break your automated tests, IDE integration etc. if not implemented correctly.
Last note - You should always do crucial validations on the server. Never rely on data from client.

Asp.Net MVC: Serverside or Clientside Parsing HTML Content

What are the pros and cons of processing/creating/parsing HTML server- or clientside.
First Process:
Parsing the html-data on the serverside via Razor
Passing this HTML-code the clientside and include this
Second Process:
Passing data to the clientside
Parsing these for example with javascript for producing HTML-code
Currently, I find only Cons for the first one
The chunk of data is larger, because we are sending not only the
data to the client
Parsing the data on the serverside costs more
for the company.

For the Second Process: The data and all its processes (business logic or sensitive data) will be available for the client to see.
Also, rendering time of the page will depend on the client's computer since its executed locally and not in the server.
My suggestions would be to stay server side to protect your data processing.

Seems like this is mvc vs angular. The difference for me is the indexing of pages by google and other web crawlers. If that is not a concern I like to do as much as I can in the client, and angular or other such html frameworks provide the 'parsing' functionality, as well as two way binding, services, and a host of other features that make client side development in HTML a breeze.

How to combine JMVC (javascript-mvc) and server side MVC together

I have asked this quesion few days before here and no one answered it.
I had asked it in forum.javascriptMVC.com too and now I have a answer, however I need a a bit more idea.
Question:
I read javascriptMVC's documents and I loved it.
But I don't know how to use it in a large scale project.
I think on the server-side a MVC framework is needed or can help so much. And I've worked with server side PHP frameworks.
I am confused, my understanding of JavascriptMVC projects is that they handle client side events on the browser capture events, execute AJAX requests, manage the responses/data from the server and also show them to user in a graphical interface.
I know that in PHP MVC projects we also have controllers (and actions) that any of them is a separate page with a single entry point, my point is that these pages are whole HTTP requests.
I think the combination of these two frameworks would be in a form of a single or few heavy files (including js , css , imgs etc) that loads and managed by another Javascript libary such as steal.js.
Now user can work with site and its actions (as events) that result in running js functions that may change something in the UI or cause a AJAX request, as in Yahoo Mail where most things happens in one page.
So how will this affect the design of controllers and actions in PHP ? I mean normally in PHP MVC frameworks a lot of controllers and actions means a lot of pages. I think because of AJAX the number of controllers and actions should be actually less. I also think because of JMVC most controllers (and actions) should turn to AJAX responders, however how are layouts and views to be handled in this context?
Finally
I want to know about different aspects of using this method(JMVC+MVC). (I am using Yii as my server-side MVC framework and JavascriptMVC as my client-side MVC).
I also want to know about management of data on the client-side.
I would like to understand how AJAX and web-sockets could be used, where we can use AJAX and where we can use websockets?.
I want to understand about local-storage how we can use it for simulated page data management and maybe caching, how we can cache data coming from server as JSON in a form of a page? I am working on a very large project and I want to build its foundation very strong.

Say that you jave a JMVC framework where
The model gets data from the server using AJAX request - expecting JSON results.
The view does not rely on the server, for more that providing the raw HTML.
The Controllers do not rely on the server, for more that serving the JS files.
Essentially you use the server what it "should" be used for, data storage and processing, while you let your client browser handle all the tedious stuff.
Now, lets see how to define a server-side framework. As I see it we have several options, all of them fairly similar, albeit somewhat different (all returning someing in JSON format):
A fully fledged MVC such as cakePHP
Custom implementation
WebService implementation
Personally I would use a WebService, and I already have. Or rather, I used a WebSocket based JSON-RPC WebService.
Using a fully fledged MVC will have it's drawbacks in maintainability and, not insignificantly, server load. But it is very possible, just implement a view which formats the page as JSON...
Making a JMVC client does not, in my view, mean that it cannot request new HTML from the server. But it does mean that that requested HTML should be free of data, other than meta-data the Java-View needs to know where to put data recieved from, for example, the WebService.
So a main page in the JMVC could just contain a single
<div id=content></div>
and menu clicks can fetch a subpage from the server and load the content into content. Then that loaded content can contain some more javascript which starts WebService requests to get data from the server, to display in the empty placefolders it in turn contains.

First check https://stackoverflow.com/a/4458566/718224 after that you can move forward.
Try this (from https://stackoverflow.com/a/8424768/718224)
No, you don't need to use it server-side, but it will help with organization / separation of application and business logic. Depending on the scale of your application, that could help tremendously in the future.
The key is just making sure you organize your backend code well, otherwise you will end up with a monolithic and/or difficult-to-maintain codebase.
Server-side views would contain your HTML and any JavaScript that may or may not make requests to the server. This assumes that you are actually using PHP to build the pages that a user navigates to.
If you have a static html page that builds itself using AJAX requests, then you may not need to use server-side views at all. Your controllers would more than likely be outputting JSON data. If this is the case, it doesn't make models and controllers any less useful.
Try this (from https://stackoverflow.com/a/8424760/718224)
If you are using any of the major PHP frameworks (CakePHP, Code Igniter, Symfony, etc.) then you ARE using MVC already. If your server side logic is more complex than just a few really simple scripts than you probably should be using one of those frameworks listed, using MVC on the server and the client.
Many (most?) larger web apps being built today are moving towards using an MVC framework for both client-side and server-side application code. It's a fantastic pattern for separating concerns for many large applications, especially request/response server apps and event-driven browser apps.
Try this (from https://stackoverflow.com/a/8427063/718224)
Backbone.js connects your application over a RESTful JSON interface. I honestly find that it works wonderfully in conjunction with the MVC framework. If you build a RESTful API, you can let you server manage CRUD updates quite easily. All your server side code will be responsible is saving and sending back JSON objects to Backbone.js. Then let most of your logic and magic happen within the Backbone.js framework.
Try this (from https://stackoverflow.com/a/8078282/718224)
First, a client-side MVC framework like Backbone isn't just for single-paged apps. You can also use it to add some rich interaction to one or many views of a more traditional app. They simply provide structure and data abstractions on the client.
Next, these client-side frameworks are designed specifically to work with your back-end MVC frameworks. Backbone.js (since you tagged it specifically) models and collections work with REST services. They will talk via GET/POST/PUT/DELETE verbs and will ultimately communicate with your controllers on the back-end when they make asynchronous requests.
In the case of Backbone, it talks JSON instead of HTML. In the case of Rails, this is really easily handled in the controller. If the request is an HTML one, then you return a view as HTML. If it is a JSON request (*.json or Content-type) then the controller returns a JSON representation of the data. I am assuming that it is as easy in Django as it is in Rails to have the same controller respond to multiple content requests (HTML, XML, JSON, etc)
may this help you.

client side web apps and rich client side web pages often use jmvc backbones and etc. and with that kind if js libraries and HTML5 technologies like webstorage you can have a more applocation like websites that all things happens in client side like templating management and etc. and just we have ajax request/response to servers to get/set data or update status. and abput first section they are right a jmvc site are more like a single pages websites. ie hotmail yahoo , etc.

Javascript - Mail Compression (Not the webpage)

I have a emailing system in a program. The person writes a email, sends it to a database, and several people will be allowed to retreive that email later on. However, these emails are sometimes short but are sometimes quite long.
Consequently I would like to compress these emails before sending them to the database (in the javascript on the client side), then uncompress them when they are retreived (again in the js on the client side).
Are there any libraries (free) that can do this? Is such a thing easy to write myself?

If you really want to do this at the client end, you can maybe look how JSend works - it's not designed to save space; it's designed to compress data for transportation, but it's an example of encoding/decoding data. You will probably need to write your own script that does a similar thing.
Remember, by making the client do the compression, you need it to work in every browser. A server side script is much more reliable (and efficient).
You may want to look at InnoDB Data Compression. If you can implement it, you might find that a native database process is much more efficient than anything you can do in Javascript.

How to create temporary files on the client machine, from Web Application?

I am creating a Web Application using JSP, Struts, EJB and Servlets. The Application is a combined CRM and Accounting Package so the Database size is very huge. So, in order to make Execution faster, I want prevent round trips to the Database.
For that purpose, what I want to do is create some temporary XML files on the client Machine and use them whenever required. How can I do this, as Javascript do not permits me to do so. Is there any way of doing this? Or, is there any other solution which I can adopt in order to make my application Faster?

You do not have unfettered access to the client file system to create a temporary file on the client. The browser sandbox prevents this for very good reasons.
What you can do, perhaps, is make some creative use of caching in the browser. jQuery's data method is an example of this. TIBCO General Interface makes extensive use of a browser cache for XML data. Their code is open source and you could take a look to see how they've implemented their browser cache.
If the database is large and you are attempting to store large files, the browser is likely not going to be a great place for that data. If, however, the information you want to store is fairly small, using an in-browser cache may accomplish what you'd like.

You should be caching on the web server.
As you've no doubt realised by now, there is a very limited set of things you can do on the client machine from a web app (eg, write cookie).

You can make your application use the browser plugin Google Gears, that allows you a real clientside storage.
Apart from that, remember, there is a huge overhead for every single request, if needed you can easily stack a few 100 kB in one response, but far away users might only be able to execute a few requests per second. Try to keep the number of requests down, even if it means adding overhead in form of more data.
#justkt Actually, there is no good reason to not allow a web application to store data. Indeed HTML5 specifications include a database similar to the one offered by Google Gears, browser support is just a bit too sporadic for relying on that feature.

If you absolutely want to cache it on the client, you can create the file on your server and make your web app retrieve it. This way the browser will fetch it and keep it on the client cache.
But keep in mind that this could be a pain for the client if the file is large enough.