4 ms·

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 c

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
  I've had that question myself more than a few times. If you find any good reads on that question, I'd love to see them!
- Nitramp 13y ago
  Last I heard, browser vendors are waiting to be able to drop XSLT. XSLT is a functional language with a very weird syntax, and a very domain specific default mode - transforming XML trees in streaming mode. XSLT was the translation of SGML's DSSSL [1] into an XML syntax, DSSSL is (was?) a subset of Scheme. XSLT is actually a pretty good tool for streaming "push" templating - writing a stylesheet that generically specifies how to handle certain kinds of elements. It really sucks at "pull" templating, i.e. writing the result and indicating where data from the input should go, how most templating languages work. It turns out "pull" templating matches the mental model of most people much better, is easier to understand, and is in particular useful for ye olde typical website. On top of that, it inherited XML with all its baggage, and is forever coupled to that one particular data model. I'd still use XSLT if I had to format something like a book, or a massive manual. Put for formatting programmatic results in a web app, I never would. [1] http://www.jclark.com/dsssl/ http://www.jclark.com/dsssl/
  - jamesbritt 13y ago
    It turns out "pull" templating matches the mental model of most people much better, is easier to understand, and is in particular useful for ye olde typical website. And for that I found I was happier using a streaming parser and writing event handlers to grab data as it went by and formatting as needed in my handler code. XSLT might be a good fit if your logic depends on whole-document handling. For example, you need to know how many foo elements there are in order to generate a TOC. Or something where you're explicitly working of irregularities and optional data so you need to have the whole XML doc at hand and apply your transformations "all at once" so to speak.
mattmanser 13y ago
I worked somewhere with a similar brilliant framework. It was so much easier, etc., etc. Similar sort of genius auto-loading thing. XML/XSLT. Could slap stuff together fast. I could make those XSLTs sing man. I made a pivot table out of XSLT, no shit. It was amazingly fast compared to the IE7 javascript engine. Orders of magnitude on masses of data, it actually was amazing. Know how many times Ive used my crazy mad XSLT skills since? Never. In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways. And because every problem was novel and usually caused by some restriction in the framework you learnt solutions and patterns that you never, ever used again. And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. They had effectively learnt a completely useless programming language.
- jamesbritt 13y ago
  In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways. Well, at the time it was alta-vista not google we turned to. :) The code was pretty straight-forward Java (about the most clever thing was use of forName and assorted reflection), so finding stuff was not a problem. We had many examples; examples as part of the rather good documentation was important for us. We tried to avoid doing anything complicated. That was part of the point. Negative lines of code was a win. It was easier to work with and figure out and extend than the alternatives at the time, and arguably still cleaner and more light-weight then what came after. When the time came to move to some standard Java thing is was no easier (and often harder) to find decent examples or docs. And because every problem was novel and usually caused by some restriction in the framework you learnt solutions and patterns that you never, ever used again. No, not at all. I really don't get this broad dismissal of all in-house frameworks. Is it so far-fetched to think that a small group of smart developers with business domain knowledge can build fast, lean, code? Maybe I was just lucky to have experienced this, but I don't think it's so rare. The code was good, clean, Java. We ran into some issues because of garbage collection (we were really pushing things for speed and memory) for some related code but roadblocks due to our basic tools were rare. Somehow we avoided over-engineering stuff. It actually worked, and worked well. And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. They had effectively learnt a completely useless programming language. Again, no, not at all. They had little trouble picking up EJBs or whatever was the Java-du-jour, if they needed, but unlike devs who only knew how to piece together beans and JSPs (basically plug-and-play coders) they knew how to handle things when stuff didn't work as expected or as the docs insisted. They could actually program because they actually knew the language. Contrast this to people who learn, say, only Rails, and Rails conventions, and write very little custom Ruby code. They're at the mercy of the framework because they're married to a particular tool rather then being immersed in the underlying language. Ideally if one picks a framework one should also really learn the underlying language, but given a choice in hiring I'll go with the one who knows the language over one who knows a framework. Perhaps not every case of using your own custom tools, well-designed for the task at hand, is the same, or does not work out well for every type of programmer. I have worked places where they used poorly-conceived in-house tools, and it was not good. But that's not the case everyplace, and a business can get a competitive advantage using tools streamlined for their domain.

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
I've had that question myself more than a few times. If you find any good reads on that question, I'd love to see them!
Nitramp 13y ago
Last I heard, browser vendors are waiting to be able to drop XSLT. XSLT is a functional language with a very weird syntax, and a very domain specific default mode - transforming XML trees in streaming mode. XSLT was the translation of SGML's DSSSL [1] into an XML syntax, DSSSL is (was?) a subset of Scheme. XSLT is actually a pretty good tool for streaming "push" templating - writing a stylesheet that generically specifies how to handle certain kinds of elements. It really sucks at "pull" templating, i.e. writing the result and indicating where data from the input should go, how most templating languages work. It turns out "pull" templating matches the mental model of most people much better, is easier to understand, and is in particular useful for ye olde typical website. On top of that, it inherited XML with all its baggage, and is forever coupled to that one particular data model. I'd still use XSLT if I had to format something like a book, or a massive manual. Put for formatting programmatic results in a web app, I never would. [1] http://www.jclark.com/dsssl/ http://www.jclark.com/dsssl/
- jamesbritt 13y ago
  It turns out "pull" templating matches the mental model of most people much better, is easier to understand, and is in particular useful for ye olde typical website. And for that I found I was happier using a streaming parser and writing event handlers to grab data as it went by and formatting as needed in my handler code. XSLT might be a good fit if your logic depends on whole-document handling. For example, you need to know how many foo elements there are in order to generate a TOC. Or something where you're explicitly working of irregularities and optional data so you need to have the whole XML doc at hand and apply your transformations "all at once" so to speak.

mattmanser 13y ago

I worked somewhere with a similar brilliant framework. It was so much easier, etc., etc. Similar sort of genius auto-loading thing. XML/XSLT. Could slap stuff together fast. I could make those XSLTs sing man. I made a pivot table out of XSLT, no shit. It was amazingly fast compared to the IE7 javascript engine. Orders of magnitude on masses of data, it actually was amazing. Know how many times Ive used my crazy mad XSLT skills since? Never. In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways. And because every problem was novel and usually caused by some restriction in the framework you learnt solutions and patterns that you never, ever used again. And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. They had effectively learnt a completely useless programming language.

jamesbritt 13y ago
In reality, your framework sucked. Just like ours did. The lack of just being able to google stuff slowed everyone down massively. The lack of extensive code examples slowed everything down. Doing the easy stuff was amazingly fast. Want to do something creative or complicated? NO!! That custom framework held back the talented programmers in so many ways. Well, at the time it was alta-vista not google we turned to. :) The code was pretty straight-forward Java (about the most clever thing was use of forName and assorted reflection), so finding stuff was not a problem. We had many examples; examples as part of the rather good documentation was important for us. We tried to avoid doing anything complicated. That was part of the point. Negative lines of code was a win. It was easier to work with and figure out and extend than the alternatives at the time, and arguably still cleaner and more light-weight then what came after. When the time came to move to some standard Java thing is was no easier (and often harder) to find decent examples or docs. And because every problem was novel and usually caused by some restriction in the framework you learnt solutions and patterns that you never, ever used again. No, not at all. I really don't get this broad dismissal of all in-house frameworks. Is it so far-fetched to think that a small group of smart developers with business domain knowledge can build fast, lean, code? Maybe I was just lucky to have experienced this, but I don't think it's so rare. The code was good, clean, Java. We ran into some issues because of garbage collection (we were really pushing things for speed and memory) for some related code but roadblocks due to our basic tools were rare. Somehow we avoided over-engineering stuff. It actually worked, and worked well. And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal. They had effectively learnt a completely useless programming language. Again, no, not at all. They had little trouble picking up EJBs or whatever was the Java-du-jour, if they needed, but unlike devs who only knew how to piece together beans and JSPs (basically plug-and-play coders) they knew how to handle things when stuff didn't work as expected or as the docs insisted. They could actually program because they actually knew the language. Contrast this to people who learn, say, only Rails, and Rails conventions, and write very little custom Ruby code. They're at the mercy of the framework because they're married to a particular tool rather then being immersed in the underlying language. Ideally if one picks a framework one should also really learn the underlying language, but given a choice in hiring I'll go with the one who knows the language over one who knows a framework. Perhaps not every case of using your own custom tools, well-designed for the task at hand, is the same, or does not work out well for every type of programmer. I have worked places where they used poorly-conceived in-house tools, and it was not good. But that's not the case everyplace, and a business can get a competitive advantage using tools streamlined for their domain.