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.
Related
I've been reading about how nuxt can generate a static site when a client makes a request to view the website. We are planning to build a headless cms to migrate the database with the data the website needs. This data will only be changed when you save it in the headless cms.
My question is since this data will only change when it is changed in the headless cms. Isn't it possible to just generate the site when it is modified from the headless cms, and then serve that site to the client? To reduce server costs.
Is it possible to do this with nuxt? Or are there any possibilities to do this?
We are planning on using Firebase as a backend.
There's nothing explicitly preventing Nuxt from being rebuilt each time you change an item in your DB. The part that matters is how you tell your app to rebuild itself.
By far the simplest way is using some sort of "build hook". See Netlifys docs here for a quick overview of what they are. However, this only really works if you're using a headless CMS that can send hooks on save, and a build provider that can trigger builds using those hooks.
You will absolutely save on server costs using this sort of method, but beware: if you have a lot of user generated content triggering builds, your build cost can easily outweigh the server costs. You also need to be aware that builds generally take a few minutes, so you won't see instant changes on your site.
The other option you have is foregoing static site generation in favour of SSR, which can dynamically load and render your content, completely avoiding the need to build every time a new DB change is made. This is what I'd consider the best alternative if you do indeed have a lot of user generated content.
It's hard to give any further advice without knowing the specifics of the CMS or build provider though.
I have an ASP.NET MVC project that is deployed via Visual Studio's Web Deployment - all works fine so far.
I now need to deploy another version of the same project (e.g. for a different customer) - with the same code base/functionality, but with a different layout, i.e. other CSS and images (maybe even with different views/Razor code). Ideally, the content from the other configuration would not be published at all.
I know I can use different connection strings for the persistence layer - but is there a way to configure also configure other content elements?
I'd like to avoid having two versions (or later even more) that required branching/merging - but rather like to simply deploy the latest version with the different "themes"...
I have a MVC project with 4 class libraries. And i deployed it into 3 other domains.
I copied only MVC project without controllers or code classes for each client, and added them into my solution. I use them only for visual changes or themes. Not for server side functionality. So the copied projects' assemblies shouldn't be deployed. Only the UI files should be deployed. Assemblies are deployed from the original MVC project's output folder.
I build solution and publish dll's into 3 domain, and publish only each client's UI files into it's server.
This enables me to develop server-side functionality in only one MVC project. Separate UI files from server side functionality.
Hope this helps.
are you using MVC then?
What you can do is to override the default razor engine and create your own. What the razor engine does is mainly to map your requests to views in particular folders, you can tell the razor engine when to map those requests to views in one folder or another.
MVC4 Razor Custom View Locator
A full fledged explaination is here :
http://nickberardi.com/creating-your-first-mvc-viewengine/
That is for views, if you just want the CSS or JS to be different, you just have to map your requests to a razor bundle and then vary what the content of the bundle is depending on a variable, or the pressence of a configuration file, or by filling a variable with a value from the database.
As you can see here bundling is very easy :
http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
Say your html points to : /assets/mycssbundle.css , but what that file would actually contain can be altered by where you tell to the bundling function that the files are located.
This seems like a design question. If you foresee possible changes like this in the future, and you already swap content via DB, then you should consider loading css file from database. There're of course many other ways to do this but simple and efficient is preferable.
This would mean structuring your html properly to ensure all layout is properly handled via CSS and can be achieved via ViewData or ViewBag. See case example.
Edit:
Not css data but the relevant css file.
You have two options:
A) Develop a custom view engine that switches between different page sets depending on the configuration. This will allow you to switch between the page sets just by changing the web.config settings, which fits well with the visual studio's built in deployment model (different web.config transformations kick-in for different deployment environments). One implementation that comes to mind - switch between view engines for different deployment environments (in different web.config transformations).
Unlike the other suggestion to load pages from the DB, I would recommend loading them from folder or physical location (e.g. different view engines targeting different sub-folders of the project). DB approach is not developer friendly when it comes to developing and fixing pages and their markups that are in the DB.
B) Develop all page sets (all variations) under the same project and then write custom deployment scripts which deploy particular page sets depending on the deployment environment. Drawback of this approach is that it's hard to notice issues like page sets intersecting or links crossing the page set boundaries.
While plan B sounds a little bit simpler development-wise, it can become a nightmare maintenance- and deployment-wise.
So, I recommend plan A.
Your Question is too broad.
However we have also a similar use case. We put all the theme related stuff (css, images, etc) as an embedded ressource in a separate assembly. We have Customer1.Theme.dll and Customer2.Theme.dll etc.
The App loads dynamically the Theme.dll and references the ressrouces from there.
Among other solutions,
assuming that you are using asp.net mvc.
and assuming that you have content1 and content2 folder available in the same repository or making available in same repository is not a concern.
and assuming your are bundling your contents.
and assuming your images are referenced only using css.
You can have a app config key which will tell you whether you want content1 or content2.
something like,
<add key="sitecontent" value="content1"/>
Now in your Application start in global asax, read the app config key and depending on the value, call the
BundleConfig.RegisterContent1Bundles(BundleTable.Bundles);
BundleConfig.RegisterContent2Bundles(BundleTable.Bundles);
I think this is a design issue. As you can see below you can organize your .net application in different layers:
Source: Microsoft
There are some key principles (Separation of concerns, DRY, etc) that Microsoft strongly encourages through the .net platform and I believe will find good use in your project.
Based on what you describe a simple approach is to keep in one project -same for all clients- your business layer (including the Services or the Data layer - even with different connection strings for each project) and create separate projects for the Presentation layer.
You may find more information from Scott, CodeProject, or more traditional methods (BTW this is a great book).
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.
I'm developing a mobile site where startup time is a critical issue.
Currently meteor apps load the templates for every single page in the whole app,
and it seems there are no plans to change this before 1.0 meaning there's an initial startup hit. Overall the experience from then on is really snappy, but i'm trying to optimize the first part - esp. on mobile (asia) 3G networks.
So what techniques are people using to reduce the apparent startup time?
Because of the "full stack" nature of meteor i'm not sure how best to approach this.
For example having a separate bootstrapping/preloader page that loads the meteor app in the background (iframe?), then redirects to meteor URL when ready?
Or combining meteor with static site generated pages and disabling DDP for the first few pages?
Any techniques appreciated!
One quick fix you might look at for repeat visitors is Meteor's appcache package. With appcache added:
Once a user has visited a Meteor application for the first time and
the application has been cached, on subsequent visits the web page
loads faster because the browser can load the application out of the
cache without contacting the server first.
According to the specs it is available for most of the major mobile browsers. Of course, it will not help with the initial site visit.
As mentioned by emgee.. fastrender is absolutely worth a look.
This issue has been addresses in Meteor 1.5 by using dynamic imports. See here.
I have a semi-large web application that we run locally and I need to deploy it at another location. The second location will require some slight modifications to the project (especially cosmetic). How do you manage these differences and what do you use to distribute the site and updates to a customer like this?
Edit:
Right now our web app runs in-house and we build with Cruise Control .NET and MSBuild with WDP. What would be a good option for deployment to the customer? We will not be updating their site for them so a solution that is simple for them to deploy and update is desirable.
Branch your code.
Hopefully your code is source controlled (if not, start now!), you should branch from the base to the "Customer X" branch and just make the slight cosmetic modifications in that branch. Then just build and deploy off of that branch for that customer.
Additionally, if the changes are minor enough, you could try to make the changes configurable. That way you could deploy the same site everywhere, and just change the configuration to match what the customer wants. The more complex the differences, the harder it will be to make them configurable though.
After reviewing comments: Its good to note that configuration is practical, but ONLY if the # of changes are minor, otherwise you will pollute your code with configuration logic. (Thanks commenters)
So: Lots of changes --> Branch (more maintainable), few minor changes --> Make configurable (more practical).
We have to do it all the time. We try to generalize and make the differences between versions configurable. The most common reasons for customizations are:
additional database fields: we implemented a dynamic way to store these items in db
UI layout: we have special folders where we put images and css files which are loaded on demand
different mandatory input fields: we store the definition in the configuration and activate them programmatically
special reports: we put the template files in the custom folder in order to be chosen instead of the standard template
Some changes require programming new modules. We code them in a custom library which will be dynamically loaded inside the main application.
We usually make those differences by being data driven. The customer's difference is just a different setting; any other user in the future could as well reuse the same "custom" options later on.
Creating "one-off"s doesn't scale.
Custom patches are a pain for this very reason. We typically just branch in our source control system, and manually apply the changes after updating with a script. Because of the additional overhead, we discourage custom patches as much as possible.