Since I started down this path, I’ve sometimes asked myself, “Why all this extra work? Why follow what seem to be tangents? Why not just use existing technologies?”
The main reason is simple: the market demands that I not be static in my approach. It’s no longer possible to be good at one thing for twenty, ten, or five years and expect to do that same thing over and over for a fee. I’m looking ahead to position myself in a different place on the game board within five years. (Aren’t you?)
The reason I’m not using PHP or CGI or Perl is because I want my stuff to function without a web server. We don’t need more web servers. We have plenty of ways to push data around the interwebs (and a lot fewer IP addresses left to do anything new with). So serving data is not the problem. Being flexible enough to get the data back and forth to where the client wants it, is.
So my goals are this:
- Embrace HTML5 for interfaces. This will translate to internet web development and intranet web app development easily.
- Utilize FileMaker as a smart back end, using the Model-View-Controller idea. In this way, I utilize the scripting and calculating skillset I’ve developed over the past 15 years, but present those skills anywhere they need to be presented. (If you have noticed, the desktop is starting to go the way of the Mini Computer).
- Make this transition in a way that’s easy for other FileMaker-only developers to follow. If I really wanted to learn an entirely new way to build apps, I would. Instead, I’m asking, “What’s possible today?”
- Insulate myself from the changing business landscape. I don’t want all my eggs in any single basket. Up to this point they have been. But technology has changed so that it’s easier to escape that problem.
On the desktop, the plan is to use FileMaker Client as a listener app. It will look for changes in the HTML pages (once per second) and make the appropriate updates. It will also communicate with a central database (server or not).
For mobile, I’m still going to be using Go in the short term, but it will be a hybrid. I hope to use HTML for viewing and editing information, but it will be in a web viewer on a Go layout, so I can cause some interaction between the two. Whenever a connection is available, Go will sync with the server. Eventually, I think I’m going to end up with a custom SQLite app, so that mobile is platform independent.
There is a lot of work left to do. But I’m learning that taking the path less traveled makes me a better developer.
If some of these posts look as messy as open heart surgery, that’s because it is. I want to document how I get to where I’m going, not just the moment I arrive. So I’ll say things, and then backtrack, and then post results, and then question them. Since innovation requires breaking things, you’ll be seeing a lot of broken things around here.