It was busy day. Very busy. Information overload!
This time, it's be very fact-based, just programming stuff.
It helps to solve the following problems:
- Developers needs to ensure that all dependency JS files are loaded in the correct order => it results in a dependency map, hard to handle, manange, etc.
- Only god knows what's the dependency map of the single-page apps (SPA)
- use RequireJS
How to start?
- just import <script data-main="js/main.js" src="require.js" />
It's AMD complaint (asynchronous module definition)
=> AMD is aimed to solve dependecies and modularity of the application
- Helps separating public/private members, establish scoping
- There is revealing module pattern which is better (more readable) than just standard module pattern.
How to define a module
- Use define() method
- Syntax: Define(id?, dependecies?, factoryMethod)
It's possible to define a module with multiple dependencies:
- multiple dependencies, but you need to follow the order of dependencies
Using a module
- Using require([dependencies], callbackFunction)
- It's non-blocking asynchronous loading mechanism
- automatic dependency map resolution
AMD vs CommonJS
- The difference is asynchronous vs. synchronous loading
- CommonJS for server side, see node.js
- Instead of define() method there is export
- You can mix them on the server side
- CommonJS doesn’t make send on client-side because we don’t want synchronouse loading
Possible to use it for loading not just JS but other files, too. Works via plugins:
- Plugins for loading text files, css, json, etc…
- Other useful plugins: async, domReady, etc.
This approach can result in sending many requests to the server
=> use optimizer to bundle it together, it's page specific, works as node.js package
- 2 purposes:
- Loading dependencies
- Overwriting loaded dependencies for so called mocking, works well with BDD/TDD style (I'll write a blog post just about testing with RequireJS)
- RJs is just a middle step
- ES6 module, export, import capabilities is going to be replacement, let's see what comes
IMHO, TypeScript is a way to go.
- It can compile TS code into JS and use AMD (via RequireJS) for resolving dependencies and
- once browsers support ES6 (hope next year), the TS compiler will just use new capabilities, no changes on development side
- Use SASS (already using ;o)
- Look at the Compass which provides SASS plugins
- Follow object oriented style of CSS
- Use BlockElementModifier style of writing the CSS style names
- Take a look at: Scalable and Modular Architecture for CSS
It's great to see our front-end guys following much of that style which really turns CSS into maintainable piece of code
Unfortunately, not very good talk.
Telephones and postcards: our brave new world of messaging
This was performed by Jimmy Boggard. I met his output when using StructureMap, anyway, respect!
Nice talk, I bet you to see online video next week. Main takeaway was how he presented CQRS system on real-world example (ala burger king shop). I like this style when the speaker use real-world examples explaining the technical stuff. If you want to use CQRS (I bet you should know about it), watch the video!
Erlang: a jump-start for .NET developers
I must say great talk. Great to know about Erlang, its approach. Deails can be found here
- functional language which can achieve 99.9999% of availability
- complements C# as any functional language
- concurrency oriented language, fits really very well for solving concurrency problems with fault tolerance
- Main idea about concurrency:
- Concurrency via message passing is faster, scalable and cheaper
- Shared memory concurrency is hard
- Difference to traditional styles:
- 1 thread in WinOS allocates by default 1MB
- 1 thread in Erlang just 1 kB => results in less overhead, bigger throughput
- and many more ...
It's main goal is: concurrency and fault tolerence
- Worth looking at the video or at http://erlang.org
Already used by many known companies in the production!, i.e. Facebook
Btw, Erlang concurrency model reminds me new OS, currently in the development phase, Midori.
The Architecture of Uncertainty
Again, general talk, worth watching the video.
- isolate uncertainity from your system by making a border (interface) so that the code is not affected when uncertainty evolves.
ClojureScript: Lisp's Revenge
Funny message was announced by the presenter: JS is dead ;), closure will survive 😉
- Based on LISP
- Solves JS pitfalls
- Compiles to JS
- Has module support
- Immutable lists
- Better scoping
- Equality is based on the value
- Uniform interfaces
- Lazy sequences,
Uff, that's all for now... yeah, party time ..