Have you tried it? (Don't forget to make sure it works in all the browsers at decent speeds!) It's not the most difficult thing, but it's reasonably complex, it doesn't seem like a bad example. How many teams have one person working on satellite code in Common Lisp and another doing a basic e-commerce site for a client?
Writing a CRUD app with business logic sounds more complicated.
The tough part is extracting the business logic and correctly mapping this to code. If done well, this will create more value to the business than a drag-and-drop framework.
That's the specific type of programming that's mentioned in the article "I am a programmer":
"We're middle-men (and women), glorified translators, and we're in the unbelievably fortunate position that programming computers is still much too hard for the average user of those computers, so we translate wishes and domain knowledge into a mental representation of machinery that performs some useful task."
The business logic is "the hard part" only in terms of client communication and project management, and then only barely.
Learning that "an Account Rep has Clients", and then modelling and implementing that, is ... not challenging? Three lines of ActiveRecord ('Duplo')?
They both vary tremendously depending on the problem, but on the whole, 'javascript widgets' trumps 'business logic' hands down. The fact that most business logic is simple is why you can glue things together so fast in Rails.
Olark's whole business is making a single javascript widget, and last I checked, they're still hiring.
Making things behave as expected in as heterogenous environment as the browser can be enormously complex as the sophistication and scope of the UI you present the user grows.
Boy, I really have a different opinion of enterprise software. The number and complexity of all of the various cases is astounding! To make it worse, they frequently come with no underlying framework, so you have to extrapolate and hope that you don't bake in something that's going to change next week.
IMO, making that software to handle the business processes IS way more valuable to the business than a drag and drop widget framework. Especially if you execute it well, it can make the business hum.
Enterprise software is not complex because it needs to be it's complex because the east way to deal with complexity is to create a complex system. Take the database design for my current project when I joined the project the database design had over 500 tables for a brand new system. But, by making a few minor design changes I cut several hundred tables from the design without sacrificing anything. At one point I removed 30 tables by adding a single field to a single table.
PS: Yes, copy and paste is easy, and yes it looks like work, but it's rarely the correct solution.
See my other reply below to toyg, if your company is writing a lot of similar software your going to have to start making flexible standard stuff rather than rewriting it every time.
But I agree with you if you're going in with a blank slate.
The business logic is "the hard part" only in terms of client communication and project management, and then only barely.
Yeah, but it's the part that most customers actually want. They pay for that, not for javascript widgets. A lot of customers are incredibly happy with basic, predictable interfaces, as long as they perform all the necessary "magic" calculations in the background, quickly and reliably.
So many developers waste their time chasing "the shiny", but most of the money is actually elsewhere.
This was an extensible product, it had to be able to handle extra functionality and the widgets were a way of achieving this, so it had real business value.
And to answer the original question, yes it was complex, but that was 5 years ago. People didn't really know how to build complex solutions in javascript and there were no working examples you could just copy, paste and modify.
You were also very restricted by the speed that IE6 ran javascript on old computers.
As far as usability is concerned, basic predictable interfaces are what you should be building unless the data & interaction you're modeling is unique enough to require non-standard UI.
