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
Similar to this question; When to use JavaScript template engines? but not quite.
Is it practical to make full sites (e.g. skip static HTML and PHP processing and just send JavaScript with HTML templates for client side rendering) in client-side JavaScript with a template engine such as handlebars? Or, are template engines only useful when it comes to re-usable template sections?
You have half of the the answer, which is re-use, but you can get that on the server-side. To me the other half is as follows:
Allow front-end developers to handle all the interactive development in JS and HTML, almost without knowing JS for simple templating needs.
For web applications the UI rendering on the server slows or limits the interactions/experiences one can design, or at least limit performance. Why does the server have to know and understand the User button clicks? The browser is powerful enough to handle the button clicks.
It pairs nicely with REST services. The browser knows how to request the data and determine the user context.
More complex web server side design. State is a very complex thing to manage across clusters and nodes. Not that you can't but why should you? Especially as for most modern web applications (web 2.0 and all that jazz) the whole point is the browser doing more, handling button clicks, sorting data, etc. Guess what all that is user state. So the browser already has a lot. So why distribute that state across a cluster of servers adding latency, dependencies, etc. I have a no HTML in the application server policy.
Change control. When you write PHP and embed HTML snips in everything things end up tightly coupled. It reduces flexibility of use case changes.
Separation of concerns, forcefully. Many developers are tempted to do business logic in the view. Simple templates help reduce the likelihood of this. One could easily construct an argument against all non-templating based approaches, JS or server-side but that is not the question at hand.
If you are going to build a mobile app you want and need services that avoid presentation markup. So never generate HTML in the application server or else your app will only speak one language. People might shout server side MVC will help, but not for off-line, different access patterns, etc.
There are some performance, device detection, 'dumb phone' reasons to generate html server-side, but then write it off of the services which your JS web app use. Let that be the exception. Even better write it in JS on the server-side and re-use the business functions and logic on both.
I use a JavaScript template engine when I make one-page web-apps (with backbone.js for example).
In any other case, I would not use a JavaScript template engine.
The reason for this is, that if I create an application in anything other than JavaScript-only (PHP, Rails etc.), I like having the templates done on the server rather than at the client.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I was talking to someone that was saying that frameworks like Angular, Vue, or React
have a big drawback: except the API part (the interaction with the DB on the server), all the other code is visible from the frontend, so anyone can steal your app.
This is a fundamental fact of writing rich client-side behavior, it's nothing to do with the frameworks. It's to do with having client-side logic. The same issue exists for sites that use, for instance, jQuery, or that manipulate the DOM directly. The primary protection of your work isn't obscurity (hiding your code), it's copyright law.
The fact that the code is client-side has several ramifications:
Regardless of any rich behavior you implement on the client, you must validate all actions and inputs on the server as well.
If there are business processes or calculations or similar that are trade secrets or proprietary, you must not implement them client-side, because whether you obfuscate the code or not, it is visible and can be seen by others.
And yes, it means that anyone can steal the client-side parts of your application. The only thing preventing that is your copyright.
But again, that has nothing to do with the frameworks. It has to do with implementing part of your app client-side.
A side note about frameworks: It's becoming more and more popular to enable server-side rendering (SSR) of code written for frameworks like Vue.js, React, Svelte, etc. So using one of these frameworks doesn't necessarily mean you're writing client-side code: You could use it only for server-side rendering.
There is one interesting thing that's happened recently that's potentially making it much harder to reverse-engineer client-side code, though: WebAssembly. With WebAssembly, what's delivered to the client isn't JavaScript code, it's WebAssembly bytecode. Like Java bytecode, you can reassemble source code from bytecode, but it's a very messy process and the results are very hard to use. So, like really thorough obfuscation, it raises the bar, makes it harder for someone to take your work and reuse it. But it only raises the bar, it doesn't prevent it. (This is a side benefit of WebAssembly, not at all its main point. The great thing about WebAssembly is that it can be the output of compiling any number of other languages, including C, C++, Rust...)
JavaScript codes are compact and dirty .
This makes access to the source code difficult and sometimes impossible
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 7 years ago.
Improve this question
Although currently still in the planning stages of implementation for our company website, we are considering different methods and technologies that successful at addressing scalability, performance, and security (as in people can't steal or easily reverse engineer our financial algorithms) concerns.
According to several posts here on stack overflow, it appears that since we have already completed a good deal of algorithms via Java for our desktop applications, accessing these algorithms via Java Servlets and JSON requests (as can be seen here and here) online might be a good choice, as it would save considerable time and money by not having to rewrite them in a different language.
Before moving forward however, I would like to know if the time and money saved by this approach would be worth it in the long run, and specifically, is accessing (java methods and array data) via JSON and Javascript both secure and scalable, compared to say rewriting all of them in straight javascript? Also, is support for applets and servlets ubiquitous, or is it possible that a good chunk of our user base would not be able to have access our website without having to download additional plugins?
In the ideal situation (minimizing learning new technologies), I would like to use technologies involving HTML5 canvass and JavaScript for all of the graphical stuff, but also be able to access small data via java algorithms (which will return an array with less than 100 indexes), however eventually on a large scale in terms of number of simultaneous users (no logins).
Is this a good option in terms of speed, compatibility, and security, or is there perhaps something that we overlooked?
Sounds like you're describing a fairly common architecture of web apps.
The client side is in HTML/CSS/JS and is responsible for presentation and UI related logic and the backend does the heavy lifting. The communication between the two is done via HTTP requests, probably asynchronous (AJAX) to REST endpoints your server provides.
This is a proven method in terms speed,compatibility and security. Pretty much every website out there uses something like this.
To get started you'll need a REST server running, I recommend using Dropwizard which allows you to setup a RESTful server fairly quickly and easy. Although if you have special scalability requirements you might want to look at other frameworks.
Here's an example of how an REST endpoint looks like in Dropwizard.
#GET
#Timed
public Saying sayHello(#QueryParam("name") Optional<String> name) {
return new Saying("Hello " + Name);
}
The name variable is being sent from the client side (JS/AJAX) and then you have a standard Java function where you can do whatever you want. Finally you return some kind of result (Saying) and parse the result on your client side.
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
Most traditional MVC frameworks include their own templating solution (Jinja2, Mako, etc). If one decides to use one of those new ui frameworks such as angular or backbone, they seem to encourage the use of front end templating solutions.
Is there any difference in performance? What are the pros and cons of going either way? Are there issues in ie or other browsers when using some of theses js templating solutions?
My take on this is simple, really.
Use a server side templating engine when you want to template the structure of a site. Use a client side templating engine when you want to template the data of the site. And there is nothing wrong at all with using both, as long as they don't have a large amount of competing tokens.
A VERY common example of this is using ASP.Net MVC to manage the bulk of a site structure using the razor template engine, and using a JavaScript client library such as Angular.js to simplify the data structures on the individual pages.
Depending on the situation, one major factor can be a significant change in bandwidth usage.
For example, my newest project includes the ability to have colour codes in chat (and other places). These codes look like:
`1blue `2green `3yellow `4red `bbold on `Bbold off `b`iBold Italic...
I could parse this server-side and return:
<span style="color:blue">blue </span><span style="color:green">green</span>...
But see how I only did two words and I'm already going longer than the source text! Instead, I chose to implement the parser in JavaScript, on the front-end. This takes a lot of processing off of the server (which would otherwise have to parse this stuff for every single user) to the client (where only one user is being dealt with).
It also had the advantage that I could implement a live preview just by plugging in to the same parser, but that's irrelevant here.
Additionally, client-side templates can be cached, further reducing the amount of data that needs to be sent. This can be particularly beneficial to mobile users, who may not have unlimited data (those poor people... I weep for them... not really)
Personally, given the choice, I'd strongly recommend client-side templating (although in my usual style, I would shun all pre-made solutions and make my own XD I'm weird like that) for a variety of performance reasons. Obviously, the major downside is "no JavaScript = no website", but I'm fine with that since the entire site relies on JS...
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 9 years ago.
Improve this question
There are a lots of new frameworks, technologies coming up. And it's becoming so hard to follow up all of them. One of the thing that confuses me is client side frameworks. I heard that Angularjs,Backbone,Knockout,jsviews,knockback, SPA... are the most popular right now.But I can't understand how does the security concept applies? If we take an example of querying a table form database it's now possible to make queries from client side database, by specifying table name and fields and etc... So if it works that way, than everyone else can write another query and get all other information. I am pretty sure that I am missing something very important here, and it doesn't click my mind. So please can anybody explain me where can I start learning those primitives.
I really appreciate, and I am really eager to learn but I am searching it wrong way I guess.
Whatever the framework used, the security matter will still the same, and very similar to mobile apps:
which data can you afford to be handled in an untrusted environnement
which treatment can be applied in an untrusted environnement
By "untrusted environnement" I mean the browser itself. You have to understand that any code executed in the browser can be corrupted by a medium/good JS developper.
Data security suffer the same threat: giving access to data from your client means that you do not control anymore who is using it.
Once you've dealt with this simple matter, it became easier to decide what must stay on server side, and what can be deported to client.
That said, there are various ways to make data/algorithm steal more difficult:
Obfuscation that comes with minification
Double data validation (forms for example): both client and server side
Authentication protocols, like OAuth
Binary over webSockets, instead of plain json and ajax call...
The browser sandbox imposes some limitations, but mainly to protect the local computer from damages due to malicious JS code. It does not protect your code nor your data from being seen and manipulated by the user itself.
I am using angular for some of my projects. I haven't used other frameworks , but in angular you usually consume an API to get the data. You don't query your database directly. So, the responsability of securing your data is more in you API (Backend) than in your angular client.
You can use OAUTH, or other security method that you want to make your api safe.
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
A colleague of mine at work proposed a challenge the other day. The problem: Solve one of our common problems human resource management ie. assigning ppl to projects. The one caveat was we had to do so using a technology that neither of us had used. So we set out building this project using the MEAN stack. Its been a fun learning experience thus far, but it has me wondering.
At what point do we decide that server side MVC rendering trumps client side MVC rendering. Most of the customers we work with already have an instance of IIS running somewhere, so we would using use asp.net MVC, which obviously will do most of the HTML rendering on the server side. Even when using angular in combination with node the HTML rendering is server side.
But if we couple angular with IIS we can do full client side HTML rendering. At what point have others made the decision to use Client vs Server HTML Rendering? Are there concerns of slowness on mobile platforms?
What does the community say are the pros and cons of each scenario?
Thanks for the thoughts!
I've gone with a pure separation between the client and server. My server stack relies on PHP (using PDO and ph-pass) and MySQL for persistence. The major advantage in my view is the complete decoupling of the view/presentation from the server side logic. It is absolutely clear in my application that the PHP generates data and returns it formatted as JSON and accepts JSON formatted parameters but has nothing to do with the display (it just creates data structures that are easily parsed on the front-end).
On the front end I'm using AngularJS, UI Bootstrap (angular wrapper for bootstrap), Google Maps V3 Javascript api (wrapped in an angular directive), and D3js (again wrapped in an angular directive).
The few sites I've worked on haven't really encountered any issues on mobile... even when doing some pretty heavy data processing on the front end... I do all my filtering and some aggregation in the client side code for displaying filterable markers on a map and to draw some charts. Unfortunately the app I'm currently referring to is about a week from being made live so I can't show a link ATM.
Here's my main site though, this one isn't dependent on any PHP so all Angular:
http://www.intellectual-tech.com
You can also check out the portfolio sites and http://www.shanklandfinancial.com I did all of these with just AngularJS and no server side code. The site that does rely on a database but is still WIP is http://www.eat-data.org
The longest delay is still in fetching the initial data which is in the 60kb range after gzipping. On mobile the google maps drags things down quite a bit and CSS animation isn't smooth/fast, but everything is still useable.
Another plus is if at some point I decide AngularJS isn't the way to go, or the client wants a native app, the server side code is all entirely re-useable without modification.
The only down side I see really is if the client wants to export the views I don't really have a good means to do that... I've recently used the PHPExcel library to output the data as XLSX files but in terms of charts etc. nothing in my server code is so fancy and would require overhaul if this was required. That said I don't think this is real problem that having printer friendly pages to be "printed to PDF" can't solve.