I'm taking a look at Hogan.js by Twitter.
http://twitter.github.com/hogan.js/
They talk about being able to precompile templates via the server which I understand can be a perf gain.
Currently every time I render the template I perform the following after an AJAX hit to the server to get data:
var template = Hogan.compile($('#seasonsTmpl').html());
$('#main').html(template.render(data));
Given the following template:
<script type="text/html" id="seasonsTmpl">
<ul>
{{#season}}
<li>{{.}}</li>
{{/season}}
</ul>
</script>
What can I do to "precompile" server side using an ASP.MVC backend? Is this not possible as it seems to be centered around using Node.js?
You have the right idea to optimize your templates. There are two options, and the choice probably depends on whether you want to render your templates client-side or server-side.
If you want to render them client-side, you can do a true precompile using Hogan.js. Yes, this does not run on .NET, but I think you've misunderstood when precompilation is possible. Rather than expecting it to happen on each web request, or page load, you can compile your templates up-front as part of your build process. You will need to install node and npm to set this up, but you only need to run this locally on your own machine, or a build box if you use one. Whenever you update your templates, you would run Hogan again to update the output file. The compiled output will be a JavaScript file full of functions that are optimized for later use. These functions include your template strings, along with the logic to render the data a la Mustache. You can then include the output file just like any other JavaScript include, or include it with the other sources for minification if you do that.
The second option is to render the templates server-side. This is different than precompilation, the server will compile and render the templates again for each web request. Step away from Hogan.js and look at a .NET alternative such as Nustache. The great thing about Mustache is it has a spec and has been ported to several server-side languages.
There's a fundamental difference in these options in terms of where the rendering happens. You might even want to leverage both approaches in certain scenarios, say if you want to render the initial page load server-side using Nustache, but have dynamic elements that must be rendered in the browser using templates precompiled through Hogan.
More info:
Nustache on Github
I hope you find this helpful!
Related
I'm rewriting some templates and functionality previously developed using AngularJS 1.x which are currently managed and developed as static assets in an ASP.NET MVC application and are used alongside razor syntax (.cshtml). There are no components either. Imagine the AngularJS modules as a huge bunch of jQuery code linked and coupled with views.
This time, I'm implementing everything we need in a Vue 3 app in a separate git repository and I'm also using Vuex 4.
I'm hoping to be able to do the following:
Build the Vue app
Load the assets in BundleConfig.cs
Link the assets to my _layout.cshtml to have them on all my pages.
Use the components wherever I need them.
I'm going well on developing the components and functionalities within its standalone project, yet I'm facing several problems and/or ambiguities.
I have pages that are mostly if not entirely rendered by the client-side. These pages may or may not be handled by a client-side router such as vue-router.
I also have pages that are mostly rendered by the server and then stuff is added or dynamic contents are loaded by the client-side. These pages can't use a client-side router.
I'm not using a router and I'm having a hard time developing and testing those pages that are mostly rendered by Vue.
if I use a router I think I won't be able to do what I'm planning to do about those pages that are mostly rendered by the server. I really need all pages (whichever kind they are) to have access to my Vuex store.
What do you recommend I do to make it easier for myself both in development and production?
Should I create several static HTML files for each of my pages in Vue's public directory tweak Webpack's configuration in order to simulate what will happen in production (use within the ASP.NET project)?
Should I start having a router, put all pages that are mostly CSR under its control, and somehow configure it to have nothing to do with my other pages that are mostly SSR?
I need to be able to debug and test stuff when I run npm run serve and then do what I'm tasked to do. Unless the whole plan is a bad/wrong idea somehow.
I might also be able to build my Vue app as a library and then, in the ASP.NET project, init a small Vue app that imports that library and that itself is bundled with the back-end project. The whole reason I'm doing this is to make the client-side stuff reusable and easy to maintain. I don't want to take a GET SHIT DONE approach.
Thanks
I have a large rails application that I am wanting to split out into smaller applications. The one piece of this application that will be universal to all smaller applications is the mast and footer. I would like to extract the html, javascript and css for the mast and footer into it's own package that each app can load and render.
The main issue I'm running into is that the apps will likely not all be written in rails. Some will be rails, some will be expressjs, some written in Go, and some may end up being written in other languages, so my solution needs to be language agnostic.
My thought is that I can extract the html, css and javascript into it's own git repo, use mustache templates for the html, and then use grunt or a similar build tool to build a gem, a package.json structure and a golang module. Possibly each in it's own git submodule.
I'm curious if there is a more standardized way of doing this. Or if anyone knows of a simpler way of achieving this goal.
Sounds like the technology in common is HTML/JS/CSS.
Wouldn't it be better to export the mast and footer as a self contained JS library, or more precisely, as widgets?
So whatever the application server tech stack would be, you could always generate the HTML in the form of:
<script src="your_widgets.js"></script>
<script>new Footer.render('id_of_dom_element_to_render_to');</script>
By doing so, whether you want the widget library to load the template or you want to embed the template into the widget library or whether you want to simply just construct it using HTMLFragment will not be limited by the server tech choice.
I am deciding whether to use rails or django for a smallish web app.
One of the features I love in rails is that you can render .js.erb files, and then serve them to the client as a response, and the browser will execute the script
Is there something equivalent in django? If I change the mime type of a response to text/script will the browser realize it's a script and run it? Also, can I render scripts using the django template language like rails does with erb? Thanks.
You may render js files in Django by treating them as normal 'Django Templates' and using appropriate MIME type in order for browser to detect the files correctly.
Good day!
I'm looking for solution to combine, minimize and gzip CSS and JavaScript files. It seems they come in two forms:
In form of ASP.NET handler\module with processing files on the fly (with caching results)
In form of VS build tasks (to perform processing while building)
Generally I'm ok with either.
I've looked on a number of solutions (and I use ASP.NET handler from this article http://www.codeproject.com/KB/aspnet/httpcompression.aspx a lot), but maybe something "must have" came out and I've missed it.
Thanks in advance!
Here's my advice to you: use build tasks and HTTP cache the output.
In terms of build tasks, you'll want to check out your favorite JavaScript minifier (my favorite is Google Closure Minifier) that has a command line utility that you can just plug into your project file, MSBUILD file or NANT file. Same deal with CSS (I personally use Yahoo! YUI Compressor). If you're into using LESS, you can certainly combine this with the YUI compressor. To optimize images, I'd use optipng. There's directions on how these guys work on their individual sites.
Now, after you have these files all nice and optimized, you'll want to output them using a handler or controller action for MVC. To set the expiration so that subsequent requests will default to the file downloaded on the first request, you'll want this to run in your code:
Response.ExpiresAbsolute = DateTime.Now.AddYears(1);
More than likely you'll want a cache-buster strategy so that you can change the content files. You'd do this by passing a random parameter to your handler. There are a few different ways to go about this... just Google it.
Hope this helps.
I'm using the telerik mvc components for small-medium sites. It was simple to add and configure with NuGet.
Moth can (among other things) handle all your javascript / css requests on the fly. See Wiki: Javascript.
Best of all, it can also put all javascript at the bottom of the page, including parts you write in your partial views! Wiki: Inline script.
I'll start to develop a new app that uses a lot of heavy js librarys (prototype, scriptaculous, tinymce and so on).
Someone told me to make all the app using ajax, so all the js files will be loaded only once.
My question is, I really must do everything on ajax?
Lets say if I call myapp.com/projects and projects use all those js files, then I click on a "show" link and I'm redirected to myapp.com/projects/1 on this redirect, all js will be reloaded again?
No, your Javascript files will not be loaded again, they will be cached on the client.
But yes, your application will need to check with the server at every page load, the server often responding that the scripts have not changed. By using AJAX, you reduce the number of connections to the server. You can reduce the number of connections by concating all you Javascript files into one.
Note however that AJAX will add some new problems, like forcing you to track memory leaks as your application will never unload its objects if you never reload a new page.
If you are not at ease with Javascript, I strongly suggest sticking with the "old" model of reloading the page everytime. If you have performance issues, you can deal with them later.
Reloading Images, Scripts, etc...
Short answer: yes
Long answer: depends
When you view a page, your browser will request the HTML, once it has the HTML it will start to load external references (images, scripts, etc...). When it goes to request an image or a script, your browser may send a header which says when it got it last and stored it in its cache. The web server may respond with a 304 Not Modified code which tells the browser to use the cached version saving it from downloading it again.
Even if the browser doesn't use these headers, it will still be caching, it just won't know when the cache should expire. When you use the rails helpers to include images and scripts, it will append a number onto the end of the url which is unique to scripts contents. So if you change the contents, a new url will be used forcing the browser to get the updated version.
Use Google's Ajax Libraries API! Google now hosts the most popular js libraries including Prototype, Scriptaculous and jQuery. Once they host a specific version they are committed to hosting that version indefinitely.
There is a small Rails plugin by Ryan Heath at github:
script/plugin install git://github.com/rpheath/google_ajax_libraries_api.git
Then in your views instead of using the default
<%= javascript_include_tag :defaults =>
use this instead:
<%= google_jquery =>
<%= google_prototype =>
<%= google_scriptaculous =>
You can specify versions if you want. Check out Ryan's readme at github for more information.
This way you don't have to bother setting up an asset host (at least not for your standard javascript) and save yourself a truckload of bandwidth!