Building a Dart (i.e. modern web development) team

206 views
Skip to first unread message

David Notik

unread,
Nov 14, 2012, 3:53:25 PM11/14/12
to mi...@dartlang.org
This is a more general topic I was hoping to get the community's perspective on.

tl;dr: Your suggestions for finding great Dart (i.e. modern web development) engineers?  Are you one of them?

Some background:  I want to build our product using modern web techniques and technologies.  That's why I've been toying with Dart for some time now.  I think the OO language, the tools, the structure, Web Components, full HTML5 support -- all that and more make it a very compelling option.  The only other compelling option as I see it is Node.js, but I see Dart as eventually far superior, not least because Google's behind it.  Our product is currently on Drupal (LAMP).  I want to go all in w/ Dart, even at this early stage with all its challenges.  I'm a founder and "product manager" of sorts.

Our product involves offering groups and organizations interactive web pages (that's just the beginning of it).  Drag and drop photos in, infinite scrolling, inline edit anything, real time updates -- a rich experience in the browser.  But also an architecture that's well thought out and scalable -- these pages will live on one platform.  I've learned that building this requires a special breed of web engineer.  There are those that focus more on the back-end architecture (e.g. the object model and methods) than the front-end (e.g. building drag and drop or infinite scrolling).  My experience has been that those are separate skills, and I suspect that's true even in a world where the line between server-side and client-side is blurred.

What say you?  What kind of engineer or engineers should I be looking for?  Where do I find them?  Should I be looking for JavaScript developers or to convert Node.js developers?  Am I looking for front-end developers and/or software engineers, or folks who are a little bit of both?  Most recently, our team and flow has looked like designer->front-end developer->developer, but I've learned that doesn't work when practicing continuous deployment.

As well, and here's my plug, if you're enthusiastic about Dart and want to put your skills and creative experimentation towards building a customer-driven product (we follow lean principles) with a big vision, talk to me.  :)

Thank you!

--D

John Evans

unread,
Nov 14, 2012, 4:55:31 PM11/14/12
to mi...@dartlang.org
I think finding top-shelf software engineers is probably good enough.  Obviously web experience is a plus, but a good engineer will pick up Dart quickly as a tool.  A common thread you will hear about Dart is that it is approachable and easy to learn.

Cliff Hall

unread,
Nov 14, 2012, 6:23:47 PM11/14/12
to mi...@dartlang.org
The people you're looking for should have OOP experience (Java and AS3 are very similar), but who also has in-the-trenches JavaScript chops.

Dart is OOPy as you wanna be. Your codebase will become a more manageable legacy if you have people who understand how to divide a problem into actors with clear roles, responsibilities, and collaborations. They'll be able to keep things loosely-coupled which leads to re-usability as well as reducing the impact of any one change to the overall system.

But ultimately Dart compiles to JavaScript, and in the browser, it has to interact with the DOM for implementing a UI. So deep understanding of the DOM, events, etc. is a must.

Finding a JavaScript Jedi who is also a Java Warrior is tough. I don't think you'll be able to fill a team with people having both strengths fully charged and ready to go. Trying to do OOP in JS is so hard that you have to write a language that compiles to JS in order to make it happen properly. And people who have strong OOP skills don't often envy JS functional coders.

I think having a team with some serious JS UI wizards who are in charge of creating the view and defining the API for communicating with it on one side, and some OOP architects and developers on the other side would be bliss if their roles and responsibilities and collaboration patterns were well defined. (Architecting an OOP application is sort've like building a company in that way).

The OOPy folks would be concerned with business logic, service communication, maintaining state, and adapting the application to the UI. The JS functional UI folks would be building the view components, defining the events they dispatch, exposing methods to be called to feed the UI data or change its appearance.

That'd be my approach.


chl

unread,
Nov 14, 2012, 6:41:09 PM11/14/12
to mi...@dartlang.org
On Thursday, November 15, 2012 7:23:47 AM UTC+8, Cliff Hall wrote:
Finding a JavaScript Jedi who is also a Java Warrior is tough. I don't think you'll be able to fill a team with people having both strengths fully charged and ready to go. Trying to do OOP in JS is so hard that you have to write a language that compiles to JS in order to make it happen properly. And people who have strong OOP skills don't often envy JS functional coders.

I respectfully disagree. Doing OOP in JS is not that hard. After all you don't really need objects and classes to do OOP. These just help you focus more on OOP.

I think most people find it hard because they are not bothered with learning the basic patterns involved.

Ladislav Thon

unread,
Nov 14, 2012, 11:39:27 PM11/14/12
to mi...@dartlang.org


> I respectfully disagree. Doing OOP in JS is not that hard. After all you don't really need objects and classes to do OOP.

Sure you do need objects to do OOP, that's the very definition of OOP after all. And you can easily build objects even in C. It's true that you don't need classes, but then, do you know what all modern JavaScript frameworks do? At their very core, they build a mechanism to define classes. There's a reason for that.

LT

chl

unread,
Nov 15, 2012, 7:47:33 AM11/15/12
to mi...@dartlang.org
I guess our definition for OOP are just different. My definition of OOP is influenced by alan kay. And by that definition LISP can be considered OOP as well.

David Notik

unread,
Nov 15, 2012, 11:37:13 PM11/15/12
to mi...@dartlang.org
Great thoughts all around, thank you!

@Cliff, I especially appreciate your thorough reply, and particularly your description of the roles for the JS UI types on the front-end and the OOP types on the back-end.  That seems right to me.  I've learned that "front-end developer" is a common descriptor for those with the JS functional UI skills, where "UI/UX designer/developer" has brought me people with an emphasis on the (graphic) design side.  I'd hope to find front-end developers who are skilled as you describe, yet also possess aesthetic sensibilities, i.e. so they might prototype UIs that are both functional and decent looking (a UI framework like Twitter Bootstrap can make that easy), with little more than a sketch of the IA provided.  Better still is if they went beyond basic sensibilities and made UIs that were not just functional but also aesthetically top notch (again, with sketches and IA direction provided).  I know folks like that exist, but are they more rare than reasonable?  Should I instead accept that I also need a designer, before the front-end developer even gets to wiring up the interactions?

Another way of asking it:  to build something like Gmail (i.e. strong interface, not graphical/design-y), do I need designers too, or can I look for front-end developers (those JS UI types) with aesthetic sensibilities/design skills (again, assuming they're provided strong IA direction)?

Thanks for entertaining all this.  I figure some of you find this interesting as I do.  :)

--D
--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

chl

unread,
Nov 16, 2012, 3:36:06 AM11/16/12
to mi...@dartlang.org
I think you should go with a designer first and then later down the road get a front-end developer. Because, it takes a long time to develop a high fidelity UI. 

I thinks its better to get a designer to knock out a couple of mocks and then evolve the UI into something good. Then, you get a front-end developer to code it up. That way, you can produce a good UI faster. And being faster you save more money on development.
Reply all
Reply to author
Forward
0 new messages