The latest of my evaluation applications uses Dart for the BE as well, not just for the FE. It was surprisingly simple to get working together with Angular2 FE. Code sharing between the 2 is also a nice addition. I will definitely consider a Dart BE for the next production application I work on.

Hello Vlad, another approach would be not to localize your website on code level but rather translate it with a translation proxy solution. Easyling is a very well known one - guess what language was chosen for it's front-end ;) Very little to no extra coding is required to get a translated website up and running with it. Sign up for a demo, they'd be happy to show you around!

I am by no means and expert in the subject and this is my own personal opinion: If you have a flat organizational structure, it could be beneficial from certain perspectives among peers. Promotes equality, removes walls between people, makes senior co-workers more approachable. However it does not resonate well with everyone. Some people need to have some kind of indication where they are within the organization - they think of it kind of like a "status symbol". Taking titles away from these people might feel like a demotion to them. How the company I work at deals with it is this: there are no official titles for anyone and everyone can make up one for themselves, should they feel it to be important. And thus we have happiness engineers for support and professional services, lead pixel guru for front-end and many similar, often playful titles. When talking to an outsiders or customers, we forego this and say a title that describes our position, experience and field more accurately so that the customer can have an idea who they are talking to. I'd say, that the answer to this question should be examined within the constraints of the given organization and general principals be adopted to the needs of the organization and the people in it. I don't think it's a simple yes-no question and thus I did not vote either.

This is valid JS: [ ][ (![ ]+[ ])[ +[ ]]+([ ![ ]]+[ ][ [ ]])[ +!+[ ]+[ +[ ]]]+(![ ]+[ ])[ !+[ ]+!+[ ]]+(!![ ]+[ ])[ +[ ]]+(!![ ]+[ ])[ !+[ ]+!+[ ]+!+[ ]]+(!![ ]+[ ])[ +!+[ ]]][ ([ ][ (![ ]+[ ])[ +[ ]]+([ ![ ]]+[ ][ [ ]])[ +!+[ ]+[ +[ ]]]+(![ ]+[ ])[ !+[ ]+!+[ ]]+(!![ ]+[ ])[ +[ ]]+(!![ ]+[ ])[ !+[ ]+!+[ ]+!+[ ]]+(!![ ]+[ ])[ +!+[ ]]]+[ ])[ !+[ ]+!+[ ]+!+[ ]]+(!![ ]+[ ][ (![ ]+[ ])[ +[ ]]+([ ![ ]]+[ ][ [ ]])[ +!+[ ]+[ +[ ]]]+(![ ]+[ ])[ !+[ ]+!+[ ]]+(!![ ]+[ ])[ +[ ]]+(!![ ]+[ ])[ !+[ ]+!+[ ]+!+[ ]]+(!![ ]+[ ])[ +!+[ ]]])[ +!+[ ]+[ +[ ]]]+([ ][ [ ]]+[ ])[ +!+[ ]]+(![ ]+[ ])[ !+[ ]+!+[ ]+!+[ ]]+(!![ ]+[ ])[ +[ ]]+(!![ ]+[ ])[ +!+[ ]]+([ ][ [ ]]+[ ])[ +[ ]]+([ ][ (![ ]+[ ])[ +[ ]]+([ ![ ]]+[ ][ [ ]])[ +!+[ ]+[ +[ ]]]+(![ ]+[ ])[ !+[ ]+!+[ ]]+(!![ ]+[ ])[ +[ ]]+(!![ ]+[ ])[ !+[ ]+!+[ ]+!+[ ]]+(!![ ]+[ ])[ +!+[ ]]]+[ ])[ !+[ ]+!+[ ]+!+[ ]]+(!![ ]+[ ])[ +[ ]]+(!![ ]+[ ][ (![ ]+[ ])[ +[ ]]+([ ![ ]]+[ ][ [ ]])[ +!+[ ]+[ +[ ]]]+(![ ]+[ ])[ !+[ ]+!+[ ]]+(!![ ]+[ ])[ +[ ]]+(!![ ]+[ ])[ !+[ ]+!+[ ]+!+[ ]]+(!![ ]+[ ])[ +!+[ ]]])[ +!+[ ]+[ +[ ]]]+(!![ ]+[ ])[ +!+[ ]]]((![ ]+[ ])[ +!+[ ]]+(![ ]+[ ])[ !+[ ]+!+[ ]]+(!![ ]+[ ])[ !+[ ]+!+[ ]+!+[ ]]+(!![ ]+[ ])[ +!+[ ]]+(!![ ]+[ ])[ +[ ]]+(![ ]+[ ][ (![ ]+[ ])[ +[ ]]+([ ![ ]]+[ ][ [ ]])[ +!+[ ]+[ +[ ]]]+(![ ]+[ ])[ !+[ ]+!+[ ]]+(!![ ]+[ ])[ +[ ]]+(!![ ]+[ ])[ !+[ ]+!+[ ]+!+[ ]]+(!![ ]+[ ])[ +!+[ ]]])[ !+[ ]+!+[ ]+[ +[ ]]]+[ +!+[ ]]+(!![ ]+[ ][ (![ ]+[ ])[ +[ ]]+([ ![ ]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])() :D Reference: Sweary website URL Also: 0.1 + 0.2 === 0.3 // false but 0.1 + 0.4 === 0.5 // true

TS and Flow has their own ecosystem, their use can provide you with several benefits over vanilla JS. The Type System is only one of those things. Generally speaking, it's always a good idea to catch potential sources of bugs as early as possible , way before the application would get ran. The weak type system and the mutable nature of JavaScript provides many opportunities for an application to misbehave at runtime and makes it very difficult to analyze it without running it. One advantage of the a stronger type system, like that of TS's or Dart's (I do not know Flow) is that types are optionally present or can be inferred. That helps static analysis tools to understand the codebase without running it and provide the programmer with useful information on potential pitfalls, sources of bugs. Maintenance Working on a large codebase, being able to analyze the code makes it simpler to track your code, navigate it, find uses of variables, classes or other data structures. Most IDEs also provide refactoring tools on top of that.

Very good read and welcome to the Dart world! :) One thing I cannot stress enough about Dart is it's super helpful guys on it's Slack channels. I've been looking at Angular 2 Dart as well for the past couple months and the experience was very similar to yours - feeling like a Rock Star. An interesting thing I noticed was tiny size of the built JS files of my project. Generally speaking, dart2js can produce large files, especiall if mirroring is used but this does seem to be the case, the compiled application was smaller than the dependencies of the TS version. I was quickly won over!