I recently watched Diving Into the Developer Console so you don’t have to, and it got me thinking about the direction of the force.com platform. I spend quite a bit of time with force.com, so I’m always eager to get a glimpse into how things are improving for developers.
The first thing that’s very clear is that salesforce is continuing to invest heavily in development in the cloud. Some people call this Development As A Service. It’s really an IDE in your browser, which is what the Developer Console is all about.
Over the past year or two, it has grown from a simple System Log (which always functioned intermittently) to a fairly advanced developer Swiss Army knife. Some of the newer features are:
- performance analysis
- execution tracing/debugging
- taking and analyzing heap dumps (even in production)
- development in the console with syntax highlighting and rudimentary auto-completion
On the roadmap for the Developer Console are task-based perspectives, schema building, testing and deployment. Basically salesforce wants developers to develop in the console.
The current incarnation of the Developer Console is not without its issues, such as choking on large logs and the odd glitch here and there. But this is a quickly moving space. The browser vendors are improving performance almost daily and salesforce clearly believes in developing in the cloud. So, expect more big things in the future from the Developer Console.
You may be thinking “hey, what about the force.com IDE?” or, “you’ll have to rip my text editor from my cold, dead hands,” or, “how do I version control files in the cloud?” Wait, those are just the voices in my head. Remember Bespin? It didn’t exactly revolutionize the developer world as some predicted. It did, however, function more as an instructive research project that Cloud9 and others are doing interesting things with.
More importantly, one could imagine that when you develop code in the same environment in which it runs, some fairly amazing tooling is possible. And apparently there are no plans for a local execution engine for force.com, so it appears that eventually all phases of the development lifecycle will live in the cloud.
And speaking of the force.com IDE, it’s not dead yet. In fact, it just may get a fresh breath of life in the form of a major rewrite. Salesforce is working on a “Tooling” API that will expose a standardized interface for toolmakers, including salesforce themselves, to build tooling against. The current plan for the force.com IDE is to simply keep it current with the metadata API, then release a complete rewrite based on the Tooling API, once it is available. They also plan to open source the rewritten IDE so the community can do its thing. There’s been a lot of clamoring for the code to be open sourced due to persistent bugs, so perhaps we’ll see an improvement in this area.
Performance and Governor Limits
Apex has always seemed snappy for simple controllers and triggers. But certain tasks can expose some speed issues. Running tests for a medium-sized app, for example, can take 30 minutes – an order of magnitude slower than what it should be. VisualForce apps in general have had a history of performance issues. The AppExchange was noticeably slow when it was relaunched as a VisualForce app. It’s hard to say if the Apex runtime is the culprit, or something I/O related, such as creation/teardown of database test fixtures. In any case, improving performance is an ongoing initiative, and the latest release, Spring ’12, is supposed to benefit.
More importantly, as the runtime becomes more efficient, salesforce can continue to progressively relax the governor limits. And that’s what they plan to do with what is colloquially being called “Limits 3.0″. As with the limits overhaul a year or so ago, this iteration will loosen things up by reducing and simplifying the metrics. The idea is that instead of measuring very detailed things such as number of statements executed, the resulting impact of the execution will be measured, such as CPU time and heap size. Simpler is better, and this should help developers spend less time being governor limit engineers and more time solving business problems.
An Apex Renaissance
Another exciting improvement is the addition of reflection to Apex. Apex currently has minimal reflection abilities, which makes lots of tasks impossible with a static language like Apex. Granted, reflection is a somewhat advanced feature that simple VF controllers and triggers don’t need, but the possibilities that open up for larger apps are pretty exciting. For example, a big pain point is not being able to use mocks and stubs for testing. Another is a whole swath of design patterns that are difficult or impossible in Apex, such as Abstract Factory and Dependency Injection.
Salesforce is also talking about building more libraries into the platform. The JSON parsing library is an example of a library they’ve already baked in. apex-lang is slated for Summer ’12. I imagine we’ll see others, perhaps in the areas of OAuth, pre-built integrations with social networks, and improved support for consuming Web Services. What I’d really like to see is for a language like Java to be allowed so developers can leverage vast wealth of open source code libraries available. That would cut back on all the wheel reinvention going on.
Last, but not least, is refactoring. When you’re building on force.com, the concrete sets quickly. Resistance to refactoring is endemic to the entire platform and is a serious problem, especially for ISVs. Doing simple renaming of classes, objects or fields require Herculean effort. The current state of the art would likely involve emptying the org, externally modifying metadata XML, and reloading the org. Even the most basic refactoring support could not arrive soon enough. Fortunately, platform-level support for refactoring could arrive in some form as soon as Winter ’13.
What, no namespaces?
Salesforce is slowly shifting focus to “professional development” (their words). I’m not quite sure what means, but I do know that in order to create well-designed, maintainable applications on force.com, Apex must get namespaces – namespaces, packages, modules, whatever you want to call them. Creating and maintaining a large application with a language that lacks namespaces is simply insane.