I want to permit users of my Node.js application to customise some elements of their visual experience normally defined by a CSS (e.g. the color scheme).
One idea could be a fully dynamic approach on the server side with some sort of CSS-preprocessing or templating, that I could execute in a similar manner to Jade templates when processing user requests, e.g. along the lines of res.render(html_template, css_template, vars). Is there anything suitable, will less.js work here for production use?
Another idea could be to transfer such customisation to the client side, persist it there and apply it with some custom-made javascript. Is there anything of this sort?
you can use less or sass on server side, and generate precompile files for users using grant. on client side link additional css file.
Related
I checked one of application built with the Meteor web framework http://demo2.telescopeapp.org it loaded huge JS file, about 2.6Mb (minified, unzipped).
I also created an empty app, and it also loaded about 1.2Mb JS (non-minified, unzipped).
Is there a way to make client side JS for Meteor Apps small? Let's say less than 500kb?
With meteor 1.1.0.3, the default app's bundled js weighs in at 329k. It's pretty substantial without adding anything yourself. A few things to keep in mind:
Meteor doesn't ship HTML - it's rendered via js.
Meteor's intent is to pay an up-font cost to load the application, but not have to go back to the server after it's running.
Version 1.2 will allow you to separate meteor-platform into some of it's component parts, so you could include fewer parts of meteor by default (e.g. if you didn't want to ship with jquery or mongodb).
So the answer to your question is a pretty straightforward - in order to reduce your code size you need to include fewer packages and write less code.
It's worth mentioning that meteor currently doesn't have a way to selectively load a portion of your app (it's on the roadmap for a future release). For some apps, you can reduce your overall size by separating it into smaller portions and serving them on different subdomains. The canonical example is separating the user and admin portions, rather than bundling them together.
We have software developers (PHP, SQL) and web designers (HTML, CSS, JS, Foundation, Bootstrap) in our team.
A typical scenario: a software developer implements the business logic while the design is done by another person.
Problem: whenever there are changes in the frontend design, the designers have to send new designs to developers, they have to track changes and modify the sources.
Question: what tools/approaches are available to allow designers to work with the Twig templates directly, and apply changes to HTML/CSS/JS without backend developer help (without Symfony and LAMP installation, if possible)?
Or on a higher level - what is the best practice to separate backend and frontend development in Symfony 2?
Or on a higher level - what is the best practice to separate backend
and frontend development?
The frontend team, can work in the templates and send you the markups and then the backend developers will decorate it with the data, that is how it is usually done.
BUT:
The best approach that you can take to separate totally the 'Backend' work from the 'Frontend' work is doing it. :
Create your backend logic to serve the data at demand (Web service / API), instead of serving the views, send a response with a clean body that contains only the data in a readable format, like json objects.
Then the frontend developers can make the corresponding request to the web service to get the data and decorate their templates with it.
The only thing that you need to do is to provide them with the URL that will provide the data for the template that they are working, and the expected output/format that they will be receiving when requesting that url, so they do not even need any server working, they can mock your response while they are testing / creating the view.
Personal opinion:
I think that even for simple applications, this approach is great.
Why?
If you create your backend as a Web Service / API, then it would be easy to expand it, at some point your application would be used by third parties applications, or you just want to create a native mobile application version, or whatever. If that is the case you don't need to re write nothing.
Short History
I've seen huge proyects that were supposed to serve a web page, then it become populars and it ended with more usage from third parties than the web itself and were not prepared for that. They ended developing a web service, with half of the functionality for the third parties apps, and for each functionality that they added to the web service layer they used more code, more testing, and so on..
Come on, still writing?
Talking about web development, you can keep your frontend guys focused on display the data, style, and events of the page, while the backend guys keep focused in adding new features, so no one needs to distract the other side team just because they don't know how a tool from one side works, that for me worth the time that is saved.
The only "best practice" that I could recommend is to talk with the web designers and understand their needs.
Because TWIG is almost pure HTML
This is just plain wrong. TWIG may look like HTML but it's all about the data. Ask your designers if they would be happy seeing something like this in the browser instead of actual data:
List of Products
{% for product in products %}
{% endfor %}
Somehow I just don't think that will work for them.
I suppose there might be a tool out there somewhere that can convert TWIG into real HTML but what to use as data? If it does not match the back end data then problems will ensue.
I would suggest that you will need to teach your developers how to use composer update as well as your source control system. The database should not be a problem. You can have a single designer database somewhere that the back end folks can keep up to date. Someone else can install and configure the LAMP stack,
You could even setup virtual designer machines (perhaps with vagrant) that will be fully loaded with whatever software your designers needs for a specific project. Your developers might find these virtual machines useful as well.
The other approach is the nuclear option. Don't use TWIG. Your back end turns into a web api and only deals with data. No back end generated html at all. Your designers now have complete control over the front end. Bit radical perhaps but it does seem to be the way the industry is moving towards.
Twig is related to Symfony controllers for the "data".
If your designers wants to modify a html part of the twig templates, they can do directly into templates.
If they want to add additional elements which are related to specific data, the should work with backend developers in order to update controllers code and populate this data from backend to front-end part.
If you use symfony to provide only data (JSON based on lot of AJAX Requests from front-end) I think that designers can work alone with interface and mock JSON data in their local installations without using symfony code.
There is no "best practice" to separate backend and frontend development in Symfony 2, simply because it uses the MVC pattern, which in itself separates buisiness logic from views. All your views are gathered in a single directory, and the only job your designers will have is to display the data. Controlers and all the backend stuff is gathered some place else and is invisible to them.
Symfony is not an obligation (although it is the perfect tool for what you want to do right here), but I'd recommend you choose a framework that implements the MVC pattern, because it is the cleanest way to develop, and assures your code to be maintanable a long time from now.
I will share our solution/practice out of PHP, which completely separate the front-end works from the back-end and our designers and developers are separated in different departments, they are connected by redmine's tickets, but they do not need to communicate to each other in most cases, and also their work will not interact with others in most cases.
Out solution is based on java/javascript, simply we developed our own framework to combat with the issue about separating front from back. Currently we have two independent frameworks for this issue, one is for server side rendering by Java, another one is for client side rendering/binding by javascript, a client javascript MVVM framework.
At first, the basic idea of our frameworks is separating all the template rendering logic from the html template, thus our html templates are real pure html files, without any back-end intrusion.
The second step, our designers will complete their works on the independent html files without any consideration of back-end logic. Then at the same time, our back-end guys will write the back-end rendering/logic by separated java/js source.
Assume we have a html file like following:
<div><input name="name"></div>
<div><span id="name-preview"></span></div>
We will perform the server side rendering by java as following:
Render.create()
.add("[name=name]", "value", user.name)
.add("#name-preview", user.name);
Also we can perform the client 2-way binding by javascript as following:
Aj.init(function($scope){
$scope.data = {};
$scope.snippet("body").bind($scope.data, {
name:[
Aj.form({name: "name"}), //bind the $scope.data.name to input[name=name] in 2-way
"#name-preview" //bind the $scope.data.name to #name-preview in 1-way
]
});
});
As in the above examples, we use common css selector to describe where and how we want to render/bind our values to.
At a matter of fact, in our practice, over than 90% front-end refactoring would not need the help from back-end side. Even in the left 10% cases that our back-end guys have to fix the broken rendering/binding, the fixing would become very simple because we just need to change the target css selectors in most situations.
At last, although we implement our server side framework by Java, we believe it can be ported to any other languages such as PHP, ruby, python, etc.
The server side framework:
https://github.com/astamuse/asta4d
The client side framework:
https://github.com/astamuse/asta4js
I realise that this is going to be a fairly niche requirement and will almost certainly raise a few "WTF's" but here goes...
Within an ASP.NET Webforms application I need to serve static content from a local client machine in order to reduce up-front bandwidth requirements as much as possible (Security policy has disabled all Browser caching). The idea is to serve CSS, images and JavaScript files from a location on the local file system referenced by filesystem links from within the Web application (Yes, I know, WTF's galore but that's how it is). The application itself will effectively be an Intranet app that's hosted externally from a client but restricted by IP range along with standard username/password security. So it's pretty much a hybrid Internet/Intranet application but we can easily roll out packages of files to client machines. I am not suggesting that we expect nor require public clients to download packages of files. We have control to an extent over the client machines in terms of the local filesystem and so on but we cannot change the caching policy.
We're using UpdatePanel controls to perform partial page updates which obviously means that we need to Microsoft AJAX JavaScript files. Presently these are being served (as standard) by a standard resource handler within IIS/ASP.NET. Ideally I would like to be able to take these JS files and reference them statically from a client machine, and no longer serve them via an AXD.
My questions are:Is this possible?If it is possible, how do we go about doing so?
In order to attempt to pre-empt some WTF's the requirement stems from attempting to service a requirement with as little time and effort as possible whilst a more suitable solution is developed. I'm aware that we can lighten the load, we can switch to jQuery AJAX updates, we can rewrite the front-end in MVC etc. but my question is related to what we can quickly deploy with our existing application architecture.
Many thanks in advance :)
Lorna,
maybe your security team is going crazy. What is the difference between serving a dynamic HTML generated by the server and a dynamic JS generated by the server?
It does not make any sense. You should try talking them out of it.
what is the average size of pages and viewstate data. you might need to store viewstate in sqlserver rather than sending it to client browser every time.
What are the suggested methods for using javascript files with MOSS 2007 ? in the 12 Hive somewhere or directly in the site's virtual directory in a scripts directory ? Or possibly as a embedded resource in a webpart ?
Personally, it all depends on what purpose the JavaScript files are going to serve. If they're going to be shared amongst multiple components then I would suggest placing them in the 12-hive. If however, they're going to be isolated to a single component - a web part for instance - then embedding them as a resource will work as well.
This article has a discussion about best practices for the deployment of web part resources which you may find useful, in concludes:
In this post, you have seen how to
both link to and embed Web Part
resources. Each has its own
advantages and disadvantages, mostly
boiling down to whether you need to
maintain the resource separately from
the Web Part. In both cases, the
resource file can be cached, so there
is little performance difference from
each option. Feel free to use one of
these two approaches for your next web
part.
I suggest you deploy these scripts in the 12-hive.
Having them in the 12-hive ensures fast access, which is important for scripts. You risk page rendering lag otherwise. More admin overhead as you must deploy them on all frontend webservers in your farm.
Having them in the content DB makes them more centrally manageble at the const of performance.
Mine where added to Sharepoint Designer in a folder I called "scripts" I think that puts it in the database.
We use a seperate scripts directory.
We use a similiar approach to images.
This allows us to share images and Javascript easily between our webparts, and custom applications which are available though Sharepoint.
This should also mean they're only downloaded once, and cached.
I have been rather successful in promoting JQuery within my organization. No small feat on it's own. However, one of the ideas being kicked around here to make it part of our app is to create an ASP.net server side control. (We are going to be sticking with WebForms for the foreseeable future.)
I'm not too wild about this approach as it seems like overkill when a couple of script tags will do the job. We found an article on the web, and the amount of code involved really doesn't seem to justify itself. However, I do hear that there is some benefit in the script caching or generating that happens with the server controls.
My questions:
Has anyone else written an ASP.net server control to serve up the JQuery js code?
Does anyone else think that this is a crazy idea to just avoid writing JQuery or Javascript code?
I know Microsoft (along with Nokia) is "mainstreaming" jQuery and will be integrating it with future versions of Visual Studio. You may want to explore how they'll be officially using it so you can tailor your setup now, and hopefully ease your transition to "official MS jQuery" down the road.
I agree with you. It is not worth the time to create and overhead to create a control to make to add a JQuery script location.
A better solution would be to have 1 .js file that has all the links required to load on the page. That could eliminate allot of .js links, if that is the issue with the team.
The only time I would excuse creating a custom control to just link JavaScript would be for whatever reason you did not want to copy the JavaScript to the server and want to be embed it into the .dll. However you will not stop people from seeing the JavaScript on the page because if you embed the files in the .dll you must register them in the header as the full script file.
One reason for using a server control for injecting the JavaScript reference is that it is easier to control which JavaScript files get added to a page. Imagine a scenario where you use jQuery core, plus jQuery UI and a handful of other plugins. Depending on how you coded this control, you could allow a developer to easily choose which features were needed for a specific page without worrying about the specific scripts needed. This approach would allow you lots of flexibility for segmenting your application: for example the server control might be used by a master pages, a child page, user controls or another server control. If the master page registered a requirement for one jQuery library, but the child page or one of the user controls requires additional libraries, then having a unified API makes this simple. Personally, I believe this is best handled by a helper library rather than a server control.
The bottom line is how much you want each developer re-inventing the wheel or using a common, simple to use API which enforces uniformity across your apps.
I found Scott Hanselman's blog post with a sample app that has ASP.net AJAX + JQuery. It's a simple app, but it includes all the javascript with script tags. I don't see any advisement to use a server control to serve up the scripts.