4 ms·

As a JavaScript developer who spent much of his early career writing framework-less JavaScript (as many of us did in the not too distant past), the sentiment be

by cdata 13y ago

As a JavaScript developer who spent much of his early career writing framework-less JavaScript (as many of us did in the not too distant past), the sentiment behind this post really rings true to the way I feel about programming for a client like the browser. Modern frameworks are all young and imperfect in their own ways, every byte counts and JavaScript is certainly powerful and expressive enough to get you by without a framework. On the other hand, now that I have had the experience of leading teams of JavaScript developers, I know first hand the value of building a project on top of a common base that is readily familiar, well documented and easy to pick up by outsiders. The reality I have experienced is this: as your project and team grow, not everyone you work with will hit the ground with the architectural ambition to contribute to or absorb a new paradigm. Many developers will come to the table with useful domain experience related to a specific framework, or a desire to learn a tool that will be useful to them in a future job. Asking developers to learn your company's proprietary paradigm is asking them to invest time and effort developing a skill that they often can't even use in a side project if they wanted to; putting aside questions of commoditization of the profession, I think that this can be a potential enthusiasm killer for your team mates. The ability to think beyond the framework and self-solve problems with code is a great skill to engender in a team. That said, the pursuit of that skill often must be balanced with the business need of crafting a product.

SkyMarshal 13y ago
The other big benefit of popular frameworks to businesses is that they're more likely to reach maturity faster with more people using, fixing, and contributing to them. With frameworks, bugs, security holes, and performance issues - especially the hard-to-find edge cases and gremlins - once solved are solved forever (more or less), whereas every time you start your own new framework you have to deal with that again. It's probably best for a business, if you want to give your employees experience architecting a framework instead of just using one, to standardize on something like Angular.js/Ember/React/etc and then encourage/incentivize your employees to become contributors to it. Almost best of both worlds - benefit from using the framework, and employees get valuable experience, resume builders, and connections. Only thing they miss in that scenario is architecting a framework from scratch, which is something only your early employees would have gotten to do anyway.
- d4nt 13y ago
  This is very true. I once went to work at a .NET company which had built their own ORM and web UI binding framework. It was very nice back in the .NET 1.1 days but ASP.NET MVC, Entity Framework, the .NET base class library and the javascript community gradually overtook us. After a while it became more of a liability than a benefit. We'd never really documented it very well. New people ended up duplicating features and some of the quirkier bugs just never got fixed. Recruiting and retaining staff got hard and we ended up in a local minimum where each new screen was quicker to do in the in-house framework, but overall we were always falling behind. It helped us to begin with, but my view is you have to factor in what the abandonment cost might be when the industry standard starts pulling ahead of you, and that could be big. As soon as it looks like the industry is settling on a standard way of doing something, start skating to where that puck will be.
tdumitrescu 13y ago
Indeed. Having seen JS job listings that include rhetoric like "work with our hand-rolled pseudo-framework! it's sort of like Backbone but with a special socket layer baked in specifically for our app!" I can't run away fast enough.
jamesbritt 13y ago
On the other hand, now that I have had the experience of leading teams of JavaScript developers, I know first hand the value of building a project on top of a common base that is readily familiar, well documented and easy to pick up by outsiders. Yes, but choose wisely. :) Back in the late '90s I worked for a company that had their own home-grown Java Web application framework. It was conceptually clean, ran fast, and was fun to work with. URLs mapped to classes and methods; example.com/foo/bar basically located and loaded the Foo class and invoked the bar method. Domains were used to select "skins": XSLT files transformed the output. Internally it was URLs and XML all-around, making it easy to grab and verify data. (I realize that describing an application framework using the words "Java", "XML", and "XSLT" might cause some to flinch. Believe it or not this was a really, really sweet tool. I was lucky to work with some very smart people who wrote very good code. We took some liberties with how XML was handled for some interesting parsing advantages. Not a fan of XSLT, but I learned some useful coding techniques.) Teaching this to bright and motivated developers was not hard. It ran on relatively low-powered commodity hardware and customers loved it. Everyone was happy. Then the company was acquired, and the new bosses decided that they didn't want to have to train new devs on some hand-rolled framework. J2EE and EJB become the new frontier. Yes, it was easier to find devs who already knew about EJBs, WAR files, and so on. Was it worth it? No. In this case they would have been better served keeping the old framework. It was just better. If your company is using custom tools and you are concerned that this will make it harder to bring on new developers consider how your tools tack up against what's publicly available. Maybe the better choice would be to open-source what your're using, or just take the hit of training people when they get hired. If you make things too easy for run-of-the-mill developers you may end up with run-of-the-mill developers.
- gavinpc 13y ago
  XSLT gets a bad rap, I guess because it is verbose and rather special-purpose. I do wish that version 2 were more widely deployed. But hey, XSLT 1.0 runs in like, every browser in the world, and is practically designed for emitting DOM. I wonder why it's not used more often.
  - taeric 13y ago
scelerat 13y ago
In my experience writing web apps for many years (frontend and backend), you either (1) start off with an existing framework, (2) write your own, or (3) end up with a mess. You really shouldn't be doing (2) unless you've had several go-arounds with (1). (3) is, of course, undesirable.
chongli 13y ago
The problem with frameworks is that you can't do dead-code elimination with them. The solution to this is to use a *-JavaScript compiler of some kind. This lets you use bits and pieces from all sorts of different places without paying the heavy price of including all the dead code.

by cdata 13y ago

SkyMarshal 13y ago

The other big benefit of popular frameworks to businesses is that they're more likely to reach maturity faster with more people using, fixing, and contributing to them. With frameworks, bugs, security holes, and performance issues - especially the hard-to-find edge cases and gremlins - once solved are solved forever (more or less), whereas every time you start your own new framework you have to deal with that again. It's probably best for a business, if you want to give your employees experience architecting a framework instead of just using one, to standardize on something like Angular.js/Ember/React/etc and then encourage/incentivize your employees to become contributors to it. Almost best of both worlds - benefit from using the framework, and employees get valuable experience, resume builders, and connections. Only thing they miss in that scenario is architecting a framework from scratch, which is something only your early employees would have gotten to do anyway.

d4nt 13y ago
This is very true. I once went to work at a .NET company which had built their own ORM and web UI binding framework. It was very nice back in the .NET 1.1 days but ASP.NET MVC, Entity Framework, the .NET base class library and the javascript community gradually overtook us. After a while it became more of a liability than a benefit. We'd never really documented it very well. New people ended up duplicating features and some of the quirkier bugs just never got fixed. Recruiting and retaining staff got hard and we ended up in a local minimum where each new screen was quicker to do in the in-house framework, but overall we were always falling behind. It helped us to begin with, but my view is you have to factor in what the abandonment cost might be when the industry standard starts pulling ahead of you, and that could be big. As soon as it looks like the industry is settling on a standard way of doing something, start skating to where that puck will be.

tdumitrescu 13y ago

Indeed. Having seen JS job listings that include rhetoric like "work with our hand-rolled pseudo-framework! it's sort of like Backbone but with a special socket layer baked in specifically for our app!" I can't run away fast enough.

jamesbritt 13y ago

On the other hand, now that I have had the experience of leading teams of JavaScript developers, I know first hand the value of building a project on top of a common base that is readily familiar, well documented and easy to pick up by outsiders. Yes, but choose wisely. :) Back in the late '90s I worked for a company that had their own home-grown Java Web application framework. It was conceptually clean, ran fast, and was fun to work with. URLs mapped to classes and methods; example.com/foo/bar basically located and loaded the Foo class and invoked the bar method. Domains were used to select "skins": XSLT files transformed the output. Internally it was URLs and XML all-around, making it easy to grab and verify data. (I realize that describing an application framework using the words "Java", "XML", and "XSLT" might cause some to flinch. Believe it or not this was a really, really sweet tool. I was lucky to work with some very smart people who wrote very good code. We took some liberties with how XML was handled for some interesting parsing advantages. Not a fan of XSLT, but I learned some useful coding techniques.) Teaching this to bright and motivated developers was not hard. It ran on relatively low-powered commodity hardware and customers loved it. Everyone was happy. Then the company was acquired, and the new bosses decided that they didn't want to have to train new devs on some hand-rolled framework. J2EE and EJB become the new frontier. Yes, it was easier to find devs who already knew about EJBs, WAR files, and so on. Was it worth it? No. In this case they would have been better served keeping the old framework. It was just better. If your company is using custom tools and you are concerned that this will make it harder to bring on new developers consider how your tools tack up against what's publicly available. Maybe the better choice would be to open-source what your're using, or just take the hit of training people when they get hired. If you make things too easy for run-of-the-mill developers you may end up with run-of-the-mill developers.

gavinpc 13y ago
XSLT gets a bad rap, I guess because it is verbose and rather special-purpose. I do wish that version 2 were more widely deployed. But hey, XSLT 1.0 runs in like, every browser in the world, and is practically designed for emitting DOM. I wonder why it's not used more often.
- taeric 13y ago

scelerat 13y ago

In my experience writing web apps for many years (frontend and backend), you either (1) start off with an existing framework, (2) write your own, or (3) end up with a mess. You really shouldn't be doing (2) unless you've had several go-arounds with (1). (3) is, of course, undesirable.

chongli 13y ago

The problem with frameworks is that you can't do dead-code elimination with them. The solution to this is to use a *-JavaScript compiler of some kind. This lets you use bits and pieces from all sorts of different places without paying the heavy price of including all the dead code.