Develop Reference

When to use a back-end templating engine and when to use a front-end templating engine? [closed]

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...

JavaScript framework for client [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
My team consists of more java guys and limited experience with JavaScript. I know this question have been asked several times, but just to get my facts right, I need to clarify few things as my experience in client side technologies are very limited. We've decided to build our solution using GWT instead of pure JavaScript framework (given there are more java experience).
These were the facts to back my decision.
100% written in java
Requires basic java skills (Java SE not Java EE)
OOPHM – Out of process hosted mode – Define your browser & version. Browser compatibility no longer our problem
Debugging – debug your GWT apps just like any other Java application, using your IDE's debugger
Optimized JavaScript - GWT writes faster and more compact JavaScript than you
But some of my application function needs to use external js libraries.
For e.g. Let's say I need make use of some specific js library to draw some stuffs on a particular page. (actually that js files written in dojos).
Can above requirement be accommodated with GWT?
Do you think the decision to go with GWT is wise or do have any other recommendation?
We've found sencha gxt has the best widget library around( I'm aware its commercial, at least i found all widgets what we need). Do you think it's a wise idea to use wrapper library over core GWT ?
Thanks in advance.

Can above requirement be accommodated with GWT?
Yes (see #Andrey Kapelchik's answer).
Do you think the decision to go with GWT is wise or do have any other recommendation?
Given your background and the points you mentioned, I think it is a very good decision. I have built apps with JavaScript, jQuery etc., but for anything that's larger than 1000 lines of code, I wouldn't want to build a JavaScript app "manually" again. The points that are decisive for me:
With GWT, I can re-use parts of the code both on the server and client side. For example, I can validate on the client side to give immediate feedback, then validate again on the server for security, using the same code.
I find my way much easier in large GWT projects. While it's certainly possible to arrange even large JavaScript code in a clear way, it always tends to get unwieldy.
I make intense use of IDE features all the time (refactoring, finding write access to fields, ...), and IDE support for JavaScript is too limited for me.
You will still need a tiny bit of JavaScript knowledge here and there. Your team definitely should learn CSS, and I'd recommend to learn it thoroughly - no matter which client side framework you choose.
We've found sencha gxt has the best widget library around( I'm aware its commercial, at least i found all widgets what we need). Do you think it's a wise idea to use wrapper library over core GWT ?
In a few projects I'm working on, we're using GXT, because that decision was made a few years ago. Here's my opinion: If you need to build something that looks very much like a desktop app, GXT may be perfect, otherwise I wouldn't recommend basing the app on GXT.
You get the best performance with pure GWT, and if you know CSS, it's much more flexible. GXT has some nice features, but working around its limitations, significant performance issues (and sometimes its bugs) can be quite time-consuming. If you really need a special GXT widget, you can still build a pure GWT app, and then add just that one GXT/SmartGWT widget.

I suppose GWT is perfect for the requirements and objectives of your described project. GWT has JavaScript Native Interface to use native JavaScript. JSNI allows integrating GWT with existing JavaScript or with a external JS library. It solves these issues by allowing you to integrate JavaScript directly into application's Java source code.

My team really struggled with this issue after many false starts we determined that JavaScript can not really be avoided and it is not as bad to master as I feared it would be. The time it would take to ramp up on GWT would be around the same as it would take to ramp up on client side JS MVC framework.
We did consider GWT but dropped it because it will be harder to maintain in the long run for the following reasons.
What if the developers of GWT loose interest in maintaining it, it takes a really sophisticated skill set to maintain something like GWT.
Widgets that we might want might be available for something other GWT and porting to GWT might be more work than we want to do.
Modern JavaScript MVC frameworks are getting really mature with a lot of really cool features that make it easy to develop complex one page apps.
Browser will get better, JS frameworks will get better, it will be easier to higher front end developers ... etc.
We also evaluated dojo and dumped it because we felt that customizing it was going to be too hard for our team. Here is what we ended up with.
Twitter Bootstarp for a CSS / widget framework
A bunch of different jquery plugins wrangled up form various places online
JQuery, Backbone, Handlebars for the client side MVC framework.
If i was starting the project again today, I would go with AngularJS from Google, it really is an amazing approach for building client side web apps. Especially because of the clever use of Dependency injection in JavaScript and the two way biding and a bunch of other stuff. I was at a Throne of JS conference and the google AngularJS guys were saying that they ported a 17,000 line GWT app to 2500 line angularJS app.

mustache.js vs. jquery-tmpl

I'm looking at javascript templating for the first time and mustache and jquery-tmpl are the top contenders at the moment.
Some of my requirements:
templates will live in separate files to be included on multiple pages
all (or almost all) data will come from calls to a restful api which returns json
we're a java/eclipse shop, so syntax highlighting and compatibility with that would be nice, if it's an issue at all
Anyone know of any comparisons in terms of speed, ease of use, flexibility, stability? Any other factors I should be considering? Other top templating engines?
(I know there are other questions on this general topic, but I don't see any direct, broad comparisons between these two.)

My reason to choose mustache over any other template language was that it is implemented for any language you are likely to use. As it is also a true logic agnostic templating language your templates become portable. Therfore you gain the flexibility to choose to render your templates on the client or server side. Even though I have no benchmark available I don't think that performance should be an issue.

Initially I started out using jquery templates but development on that halted a long time ago.
Have a look at handlebar.js as an alternative to mustache.js ( see http://catchvar.com/jquery-tmpljs-vs-handlebarsjs )
handlebar.js seems to be about 2x faster than mustache.
I've been using handlebar in a few projects and mustasche in one or two. I much prefer handlebar and find it 'better'. Here's a nice tutorial by Andrew Burgess I found.
Edit Mar-2013: Also since then Twitter have released Hogan.js which looks awesome like everything else that Twitter does, so I'll be investigating that too at some point.

Can anyone suggest a good client-side architecture and structure for large scale web applications? [closed]

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'm building a large scale web application. It will grow in the future so I need a good back-end and front-end architecture for my application. at the back of the site, I use Zend Framework so the architecture is OK for me. But at the front, working with javascript and ajax without having a good architecture makes later changes hard and confusing.
For now, I'm using my own architecture. I have a big object for the whole application say BigObject. I extend it when modules are added to the site. say I have an upload module. I use this:
BigObject.upload={
//initialization
init:function(){
},
//I tried to use what I named semi-MVC architecture!!!
controllers:{
//index is a controller
someController:{
init:function(){
//initialization
},
someAction:function(){
//Code goes here
//call a model if necessary
//call view script
BigObject.upload.views.someController.someAction();
}
}
},
models:{
//models required for this module like loading contents with ajax.
loadContent:function(part,callback){
}
}
views:{
init:function(){
//initialize view
},
someController:{
someAction:function(){
}
}
}
}
What do you think? Is there any better solution to this problem? anyone thought about a good structure for front-end part of web applications ( like what we have at back-end,good file structure and object-oriented methods )?

The most up to date answer to this question in 2020, would be to use React + GraphQL + Styled-Components. The best place to start with React is the official Create React App tool. Their are a few different implementations of GraphQL; on the client side the clear leader is Apollo. On the server you have a lot more choice and it is reasonably easy to even roll your own server implementation, so go with what work best with your current backend. Styled-Components gives you CSS in JS, in the same way that React gives you HTML in JS.
For a more complete and opinionated experience, take a look at Gatsby, which brings all of the above into a single framework.
Over the last couple of years a more functional style to writing JavaScript has become popular. If your not used to functional programming then it can be a bit of a steep learning curve to start with, but start by leaning about a library called Ramda.
Here are few links to get you started on functional JS
An introduction to functional programming in JavaScript
Thinking in Ramda
Indentation is the enemy: Writing less complex JavaScript
Mostly Adéquate guide to functional programming
When it comes to testing, then Jest combined with Enzyme is by far the best current option.
Finally for a much deeper answer, checkout this talk from Cheng Lou on the Spectrum of Abstraction.

Most of the answers are proposing stuff like jQuery, React, Angular, Vue.js... which are not frameworks, neither architectures. All of these libraries are layers on top of JavaScript. I just remind you that JavaScript is already a high level language!
Since the question is about a good client-side architecture and structure for large scale web applications, I would say that none of the previous answer solve the problem, and there is a reason for that :
There is currently no emerging or commonly accepted architecture for front-end JavaScript source code organization.
I already read dozen of blog posts, Stackoverflow questions, Youtube videos... I never found someone who detailed a generic, general and scalable architecture. The main reasons are:
front-end JS code is quite small regarding back-end source code, most of the developers do not need a scalable architecture.
execution is ephemeral, lifetime of JS is the same as web pages lifetime.
the problem for many developers is more about manipulating the DOM than structuring large JS code. This is why people answers are about libraries rather than frameworks.
I really expect that some day, someone will propose the first real JS architecture (like MVC for example). But in my opinion, this architecture will be more about event-callback than MVC. Before concluding, I'll suggest you the following ressources:
Imperative or procedural programming.
Functionnal programming (probably the best lead with modules)
Awesome videos of Fun Fun Function
JavaScript modules
To conclude, I'll strongly recommend to consider JS modules that have a great underestimated potential. This is not exactly an architecture, but:
JS modules organise your code
JS modules are scalable
maintanability is easy
JS module are reusable
Previous list isn't the main reasons why you need to organize your code?
Word to the wise!

A lot of people push for either Dojo or YUI for large applications. They are honest frameworks where most everything else you'll find is a library.
Personally, I tend to stick with jQuery. I create jQuery plugins or jQueryUI Widgets as needed. I've managed to push jQueryUI pretty far.
Everything falls in either $.fn.myPlugin or $.ui.myWidget. To me, this has the added benefit of pushing you to keep code very modular and portable (assuming you abide by jQuery/jQueryUI conventions).
$(element).myWidget({
color:'eggplant',
someValue:42
});
$.upload(args);

I was actually struggling with the same question for sometime.. after doing few large-scale projects, I thought of sharing my learnings as a reference architecture incase someone else finds it useful.
Have a look at http://boilerplatejs.org. It is not a library, but a framework that integrates some industry leading libraries with architectural patterns for large scale javascript development.

According to my understanding on the frontend i will ask you to use web-components that uses only HTML,CSS and JS.
No need to spend much time on understanding the other languages. If you take the latest UI frameworks or libraries like Angular, React they have built on web components.
You can customize your own components and use cases which you want to use in your project.When you are using frameworks it will take some time to load and follow up for few libs that are using.
JS you can use it any way you want. You can re-use these components in any number of projects once you have created.
Just look into webcomponents https://www.webcomponents.org/introduction you will get a clear idea. I hope this helps.

With the experience of scaling some of my content for million viewers in my application. But then I had to close the application for less profit and more stress in managing it (not the cost though, but the profit was not high enough to keep up motivation)
My architecture was:
Mithril.js.org library - Checkout mithril here for front-end
Twitter bootstrap front-end framework
Backend with "Laravel and started migrating some of the heavy write data to nodejs"
Redis as in-memory storage.
I was almost in a situation to move my storage to s3 before I shut down the app.
No jQuery - I kept my app jQuery-free ( I heard and read somewhere big app avoid jQuery, so without further investigation myself, I planned to remain jQuery-free as well, though I have no solid or bullet proof reason to avoid jquery)
I found mithril more interesting then react or angular, it was so easy to start and I was building while I was learning, it was damn easy and they claim, they are better than react, vue and angular in terms of size and performance.

My response would be to ask why you need this? I've worked on plenty of applications which make use of javascript, but one thing that I've learnt is that the best thing to do is to minimise javascript and most especially object orientated javascript to an absolute minimum. Web pages with large and complicated javascript tend to be slow, memory hungry and a pain to debug with all the browser variations.

What are the arguments against using a JavaScript Framework for a Web site development company? [closed]

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
Our company builds websites and web applications. We are a small firm and our team of developers are always building the javascript functions from scratch or copying from other websites built by us. Every time I bring to the table the word standardization and using a JS framework like JQuery, Prototype or any other, I am told Frameworks have the three points below as arguments against them:
Mainly for people that don't know enough JS
Frameworks limit Javascript developers
Frameworks bloat the actual development code with a lot of things that are not used.
We don't use enough Javascript in our applications for us to need JS framework
In my mind it seems that Frameworks, give our team a good starting point, documentation, a community and always the option to grow on top of the framework. Could some Framework users elaborate further?
EDIT 1:
Thanks to all of you for your great responses. I really did not think that this was going to be such a hot topic. I am glad I asked the question. I posted another similar question in the following link in case you might think you want to add something. The topic of the new question is CSS related. Thanks.

By your coworkers point of view, .NET and JAVA are for people who don't know enough assembly.
Frameworks exist for a reason. They allow you go focus on the problem instead of dealing with repetitive code. They allow you to be confident (assuming you use well tested frameworks) that certain pieces of your code are reliable and well tested.
If your coworkers are against frameworks, I would seriously consider moving on.

Since no one has mentioned it - a Javascript framework rapidly becomes one more project dependancy, and in general terms, dependencies are bad as they represent points of failure.
As for this:
Mainly for people that don't know
enough JS
Without elaborating, I will say that if one of our team said something like that in my presence, I would try to shrug it off as a joke. If I thought they were being serious, I would probably have to kill them.
And as for this:
Frameworks limit Javascript
developers
That could translate to "Frameworks make it marginally harder to write spaghetti code, and that's what I do best"
Those are not arguments, they are excuses.

Arguments against:
Frameworks prevent you from re-inventing the wheel
Frameworks generally contain well tested code
Frameworks are well supported by the community
Frameworks force you to focus on the business problem you're trying to solve
</sarcasm>
Frameworks may have a license you don't agree/can't work with

A few positives for javascript frameworks (like JQuery).
They provide standardization in ui
elements.
Reduce time to develop complex
interfaces and effects.
Normalize efforts by providing
functions that are already
cross-browser compatible.
Due to efforts in cross
compatibility documentation is more
useful in a framework as you can use
the framework's api as canon
instead of searching for obscure
support for various/proprietary
javascript functions.
Reduced learning curve for new
developers making them productive on
your software quicker.
I completely disagree that a framework limits javascript developers. Quite the opposite actually. Most frameworks provide extensive plug-in mechanisms where the framework can be extended using raw javascript utilizing hooks in the framework itself.

I'll use jQuery as an example, but what I'm saying here could apply to most JavaScript frameworks.
Many frameworks (notably jQuery) are far too monolithic and not modular enough.
While depending on well-tested 3rd party software is often more than justified, "frameworks" tend to give you a lot more functionality than you need at the moment.
In many projects, I very much like the convenience that jQuery gives me for selecting sets of elements (using $(".classname"), for example). But, if I'm not using any significant amount of AJAX, I don't need the AJAX utilities provided by jQuery.
Software should do one thing and do it well, and software written in JavaScript is no exception. Most of the frameworks you refer to try to do everything, resulting in unnecessary complexity.
One place this can bite you is when you're considering upgrading to the next version of the framework. That involves crawling through jQuery's changelogs for backwards-incompatible changes and searching your project for areas where that code is used. This can be quite a nightmare, especially if you don't necessarily have a comprehensive list of which jQuery features you use and which ones you don't.
Also, jQuery (and other frameworks) tends to cause developers to start depending on new features of jQuery without even thinking about it, making it harder to determine which features of jQuery your project uses and which it doesn't.
If you use a utility which does one thing, then you know exactly which features of that utility you're using. There's only one. (If you aren't using that utility at all, it's easy to determine. Such a determination would mean you could safely remove it from your project.)
I'm all for using well-tested 3rd party code. But if it tries to do too much, (that is, if it's a framework rather than a utility), you should probably look for an alternative. If it tries to do too much (like jQuery tries to do too much), then it's got some serious, foundational design flaws that will probably come back to bite you.

I'm surprised no one has already mentioned it:
A lot of web developers default to using JQuery without considering the alternatives
And end up including it on a web page to do a few trivial tasks which could easily be done in pure JavaScript
The result is that users have to wait for the whole library to download and it slows down web browsing
Also:
Some web developers get carried away with the design of web pages, and end up developing unnecessarily complex web pages because of the power of JQuery
Just because JQuery enables you to create scripts with good cross-browser compatibility it doesn't mean that the end result is usable on different devices / interfaces
I'd also argue the cross-browser compatibilty because I've seen instances of webkit not playing well with JQuery
JQuery encourages "fast" scripting - but if you rush it you are likely to have missed something out
Writing in JavaScript from scratch is slower - but I believe that you end up with a more complete solution which more closely matches the users needs
Using JQuery can shift the focus of the web developer to creating web sites which are highly graphical and visually appealing, whereas the focus should be on functionality and usability
JQuery is not a silver bullet for web development
I am biased here because I don't use JQuery, but it is because I haven't found a need for it yet - maybe it's because I focus more on usability and functionality rather than making the user interface look pretty (sorry I know JQuery can do more than that).

An argument against libraries is BROWSER SUPPORT most libraries support only a subset of browsers out there .
Here is an example of BBC rolling out their own instead of using something like jquery .

I liked the answer of pb +
Mainly for people that don't know
enough JS
I believe it is too complicated for them, so they use this excuse. FW allows you to build much more complex applications.
Frameworks limit Javascript developers
bullshit
Frameworks bloat the actual
development code with a lot of things
that are not used.
what is it today extra 100k-200k? especially if you use the CDN versions (at google for instance). And this is assuming you use nothing in the FW.

There are plenty of good reasons to be suspicious of frameworks in general, balanced of course by lots of reasons why they are worthwhile.
I use jquery now, and frankly within an hour of learning it realised that it fits the job so well that if it didn't exist I'd only end up reimplementing something very similar myself, only it wouldn't be as good or as cross platform.
There isn't much bloat there, it's very small and well designed and does nothing at all that stops you writing any javascript you want for specific cases that don't fit your needs.