Are we supposed to use these features (javascript, jQuery, AJAX, etc..)?
Depends on your requirements for building an application. Use the tools that provide acceptable solutions to your needs.
If so why does it make such big difference in the size of pages?
I'm not quite sure if you are looking at just the page or the entire request. Most of the JavaScript I would assume is in separate files that can be cached by the browser. So the first request might be big, but subsequent requests would be much smaller. (Also to take more load off your server, look into using a CDN)
Is it the way I have used them or is it a common problem (I've heard so).
?
Since you haven't provided us any code or examples, it could be the way you've used them. Or it could be the controls you've attempted to use. I've noticed that Telerik controls seem to be quite bloated, but that is my own opinion.
How do I balance page interactivity and server's load?
These are mostly independent from each other. It is possible to create a very interactive page that can be either more or less load on the server (load I assume is CPU/Disk time). In my opinion, AJAX for the most part simply reduces the number of times complete layouts have to be sent by the server to the client which; is less bandwidth and slightly less load on a server due to the lack "rendering" html.
What are priorities?
Highly depends on your application requirements. It sounds like you've jumped off a diving board into a big pool of web based opportunities, but don't know where to swim to.
I am mostly using JQuery
, which has a lot of very good useful features:
- DOM element selections
- DOM traversal and modification (including support for CSS 1-3)
- Events CSS
- manipulation Effects and animations
- Ajax
- Extensibility through plug-ins
- Utilities - such as browser
- version and the each function.
- Cross-browser support
Granted I have to program features myself.
Not knowing Phaser or Typescipt, I still try to give you an answer, because the problems you are facing are problems that are also visible with a lot of other frameworks. The problem is that components are to tightly coupled (everything points to the God object, and the God object owns everything...). This is something that was unlikely to happen if the creators of the framework created unit-tests themselves.
Basically you have four options:
- Stop unit-testing.
This options should not be chosen, unless all other options fail.
- Choose another framework or write your own.
Choosing another framework that is using unit-testing and has lose coupling, will make life so much easier. But perhaps there is none that you like and therefore you are stuck with the framework you have now. Writing your own can take a lot of time.
- Contribute to the framework and make it test friendly.
Probably the easiest to do, but it really depends on how much time you have and how willing the creators of the framework are to accept pull requests.
- Wrap the framework.
This option is probably the best option to get started with unit-testing. Wrap certain objects that you really need in the unit-tests and create fake objects for the rest.
Best Answer
There are some reasons why I prefer using
Map
s over plain objects ({}
) for storing runtime data (caches, etc):.size
property lets me know how many entries exist in this Map;.clear()
,.forEach()
, etc;Every other case, like passing function arguments, storing configurations and etc, are all written using plain objects.
Also, remember: Don't try to optimize your code too early. Don't waste your time doing benchmarks of plain object vs Maps unless your project is suffering performance problems.