Just recently seems like I understood why holywars between programmers are happening. During revolution I basically saw the same holywar between people that believe that their truth is the only truth. Why even for smart people from both sides it is hard to negotiate for the same vision? I believe that the reason is that they have different values.
We often underestimate how much common values important for us to feel comfortable and productive in a team. We often do not care about having common values while looking for new jobs , we care about salaries more. Agree we make decision of accepting offer based on many factors, shared values as well though we do that unconsciously.
PS: Main question in any job interview should be around values, always!
This I hope is the last post about how Angular will bring you to a world of pain.
Recently I stumbled on this Angularjs hate article that I am totally alligned with on emotional level. Angular is clearly overengineering. And unlike some may say It is not giving you exclusive scalability.
I would compare Angular to React. I know that those are not comparable. But I believe that React based architecture is something that beats Angular solution in terms of simplicity and scalability.
React stack: 4 (everything is a component, some components have state, you may use model instead, Commonjs modules, router).
AngularJS: 7 (modules, router, controllers, directives, scopes, templates, services, filters).
There are twice more concepts to learn for Angular than React. Not even saying that React’s concepts are much more simple. For example you have controller and directive with templates that do more or less the same things. With React you have component only as a building block of your application. We all know that simplicity scales better, right?
Service/provider in Angular is a solution for a made up problem. Just use CommonJs and you won’t need service/provider thing. You will just use modules and functions that are natural for JS.
Well, directive is pretty useful if you use html templates as strings. Life is easier with React when you do not use strings for templates.
With react you can live in function world. And with Angular you live in enterprize patterns world.
My next story will be about why Angular might work for you.
Theoretically there is no manager in agile. If someone is telling you that they have agile team with a manager they are lying. That mostly mean that they are not ready for some reason to share responsibility across the team - they do not have agile.
Few years ago I was lucky to participate in @jeffpatton agile workshop. This had huge impact on my understanding of application development. Right now I had embraced some agile basic principles and consider them as healthier for internal group dynamics of a team. Agile is literally makes healthier and happier each individual in the team.
People are lazy. Developers are not exclusions. We do not like to work and take responsibility. We easily give out our responsibilities for anyone who will take em. And worst thing you can do is to give all responsibility of project’s success to one person. That what is happening when you put manager in your team.
On other hand people tend to step up and take responsibilities on products they are building and when they do they become more engaged and proud by stuff they do. They stop asking stupid questions and start committing themselves to the product.
We are developers and we are coming to our jobs and spend eight hours in a day to do magic. We really want to build something that makes sense, that could make world better. Isn’t that the best motivation for us? Business, please, spend time to share your passion about product with us!
PS: There is only one case when having a project manager is a good idea. When you have short time project and manager who takes BA role. It just do not make sense to commit in building a team.
A year ago I was excited of angular and I still think angular is a game changer. I see how community charmed with angular and how easy to start building webapps apps with it. However after a year of using angular I must say that I am not recommending investing time into this framework. I will write several posts about why.
I am using simple closure for dependency injection. It feels more natural.
But we still can’t replace angular’s module system right? Thus we need to use CommonJS (you can use browserify or brunch).
Why is that better? It is simple. It is better way for structuring your app - it gives you references and you can directly say where the dependency lives. It already works well for nodejs. It is compatible with existing package managers.
I know that how JS modules should look like is a debatable topic. I think that CommonJS pattern quite usable and much better fit for JS than AMD or ES6 modules. Though I definitely think that Angular got it wrong.
Not long ago I felt that as a developer I have more or less two best options to build an app. Whether do it in #angular or #backbone. Now I feel that #react is taking best of angular, do it better and allows to use best parts of backbone.
I hate Backbone Views and I hate $scope of angular, especially when it comes to directive scope and all &-@-= stuff. Transclusion and scope is a double hell and I am not talking about digesting and performance yet.
React needs other stuff like routes and models. I am taking them from Backbone.
By default React have single state this.state. Which is not usually best solution. It appears that cleaner way is to have multiple states. Where this.state is not persisting state and backbone models are.
In the React’s example you can find BackboneMixin but it has some flaws. Following one is better since it does proper cleanup.
// Whenever there may be a change in the Backbone data, trigger a reconcile.
In that way you can use same models in several nested components.
It’s kinda logical to have 2 way binding with those Backbone models. LinkedState plugin is working only for state thus here is BindMixin wich does basically the same as LinkedState but for Backbone models.
One of substantial difference of using sockets instead of plain http requests is that we usually broadcast messages without expecting any response. While building jschat I thought it would be ehough. Though even for a chat we need the response if we want reliability and better experience. Think of “Pending” state of a message when sending it in offline mode.
Raw libraries doesn’t provide any ‘response’ like functionality thus I had to build my own implementation. As a base for jschat we are using engine.io because socket.io is not supported for a long time and engine.io is kind of it’s successor and it’s awesome.
Socker is inspired by express. Simple and lightweight implementation of middlewares, routing and error handling. Socker wrapping both engine.io and engine.io-client and providing additional methods that implement express like API.
On the server we additionally have sock.use and sock.when methods. sock.use adds middleware handler. Middleware in our case instead of request and response gives socket and data objects.
socket is a message context object. And you can pollute it whenever you like. The “session” context object is socket.__proto__ so If you want to save some data for connection lifetime use prototype object.
Inside routing middlewares the route is already parsed and we have also socket.params object with all params from the route.
Using the mask METHOD uri is not required for socker. In the same manner you can name your routes.
We can also customize error handling.
It is important to put type : "ERROR" because that is the way client will treat the message as error.
You got clean and simple API and you got some latency boost. You save roundtrip to your session storage and handshake time. And now with socker moving from express REST API to socket based API is really simple.
why building another app compiler?
When you are frontend developer and start doing node npm completely spoils you. Because unlike we used to it provides single and predictable way of adding/using 3rd party libs and snippets to your code.
Commonly used way of adding 3rd libs is a /vendor folder that holds bunch of unminified (if you’re lucky enough) files that were downloaded by someone ages ago. Maybe you will find comments inside that will give you an idea of what version of library is used, maybe not. Also what-load-first dependency management is completely your pain. You might have a master file with all the scripts loaded in ‘right’ order .
Bower is doing great job adding more metadata to packages fixing some problemts. But Bower is just a package manager (c) and it doesnt load scripts. So again, you need to do additional job defining what-load-when relations.
Even if you will use require.js you need to configure 3rd libraries. Besides requirejs adds it’s own complexities into code. For example: do you know the difference between require and define functions? And frankly why do you need to know difference! You need something that just works.
Componentjs does most of work already. Compy just wraps the concept in one solid solution.
Componentjs was obvious choice. Unlike npm or bower component is really strict on what files considered a source. Which is not that important for server but really important for frontend.
Builder takes responsibility to compile out three files: app.js, app.css and index.html. app.js is built of js dependencies (components), precompiled templates and js source files. app.css is just concatenated css files and index.html generated automatically to eat js/css and run “main” file. Builder have bunch of plugins that allow to precompile sources. So you can use coffeescript, scss, jade, whatever. And just technically because we avoid on read/write cycle comparing to plain grunt it’s faster than grunt. And you can use mix of technologies require coffeescript from js and vice versa.
Compy is a simple, ‘zero’ configuration web app builder/compiller integrated with client package manager component.
Although there is almost no configuration it gives you all flexibility to code the way you like.
To start an app all you need is to tell compy where is the beginning. To do that you need package.json file with compy.main property pointing to main js file of your app.
appstart.js file will be executed right after the page load.
Compy will generate ./dist folder with app.js, app.css and index.html. All css in your directory will be concatenated/minified into app.css file.
adding watch option will recompile the app and livereload the changes in a browser.
Most powerful part of compy local require and integration with component.
Given that you can use those to work with language/template you want.
For example to use coffeescript you will need to install plugin in your root folder.