Which front-end framework should I choose for my project?
Developers are always bragging about the superiority of their technology above the rest of the world. It’s not different at the front-end framework market and before making a choice for your project, you should consider some factors first.
Whether you’re planning a structure for a new project or upgrading an existing moloch, you might be te under the impression of some great press around given framework, which would lead you to decision: “let’s use framework X, as it’s such a great framework”.
Not quite always the best choice – consider as an example Vue and Angular. Former you just throw in, kind of plug-and-play style, where latter is quite egocentric and requires restructuring app for it to work well.
In spite, it’s common to hear that framework X is waaay outperformed by framework Y. You even can find tons of benchmarks proving that point. The truth is unless you are building data or graphic heavy app, most frameworks will fulfil your needs performance-wise.
Community and popularity
Framework popularity and community activity play a great role in how fast you can move on with work due to the support you get. For example – Vue is a great framework, but since it’s not as popular as React or Angular, it means that there’s much less reusable code around (libraries, components, …) which you could just plug in and move ahead, but instead, you must write it from scratch.
This may be the most important factor of all. If your team has zero experience in framework X, which you think is best for your needs, then it might do the job, but the probability of your team making lots of smaller or bigger mistakes along the way is quite high and this, at very least, would cost you time, at worst – you might end up rewriting your code pretty soon.
On the other side, if you’d chosen the other framework which is known to at least one developer from that team, his experience will result in good architecture; and his code reviews will catch most of the rookie bugs the rest of the team might do.
However, if you’re still fixed on this one perfect framework that no one on your team has experience with, maybe the best choice is to get some on-demand support from the experienced dev team, that will help you kickstart the project. Also keep in mind, that learning curves can be quite different for various frameworks.
You may not pick the perfect framework for your project, but this doesn’t mean you won’t do a great job. Consider all pros and cons and don’t despair over 10% worse performance or 20% bigger library size if that’s not really such a great concern for the project.
That being said, we at Exlabs are getting fonder with React lately, but we also work with Angular 4 quite often.
No more cron jobs, orchestrate data pipelines with Azure Data Factory
How do you like maintaining lots of bash scripts defined in `crontab`. If you worked in a team responsible for a data flow you know what I mean. If it starts with one script it is OK. But if your crontab grows and grows it is no more fun. Or maybe you are running your BI processes which are doing well in your current warehouse but you encounter problems with the optimization and there are not enough resources to scale your workers up?
Left Join for Advanced Rubyists
Every now and then you will need to keep a track of user activities in the system. This can be approached in several possible ways – one possible solution is to store them as an activity log in the database. This alone can create some challenges and may require you to use less common SQL statements in the Ruby on Rails apps like LEFT JOIN, hence I’ve decided to shed some light on it.