Filemaker vs Servoy

[rochard]

I have been a FileMaker developer for about 17 years and have always been wildly enthusiastic about it. That hasn't changed one little bit because FM is a great program and will stay that way (unless Microsoft decides to buy it and then it will rapidly go the way of the Dodo bird!) However I have certain clients whose business has grown so fast that their FM solution is now starting to creak at the seams and reporting, among other things, has slowed down to a point where it just takes too damn long. For that reason, I am spending a lot of time learning Servoy, not because I want to (or will) stop using FM but we all have to use the right tool for each job; Servoy is a very good tool for those projects where FM becomes less than an optimum solution or where it is impossible to convince the client that anything other than an SQL application is what they need. It is interesting to see the different reactions that some FM people have to Servoy; you'd think that the plague had arrived! It's really silly; there is a huge world out there and massive amounts of room for both. Servoy is not now nor never will be a FileMaker killer but it is a killer app and well worth investing the time to learn!

[Harjo]

Well said!
I had the same thoughts as you, in the beginning!
When you use Servoy a lot for let's say an half year, would you share your view again?

I am very curious!

[rochard]

Of course, I'll be happy to re-assess in a few months. One of the things I have enjoyed most about working with FM is the sense of community spirit and the willingness to share knowledge with others which is exactly what is happening with Servoy. Busy people take the time (and lots of it) to help others; if only the whole world was more like the FM & Servoy communities, then it would be a far better place.

[Harjo]

Amen!

[mattman]

Well said!
I had the same thoughts as you, in the beginning!
When you use Servoy a lot for let's say an half year, would you share your view again?

I am very curious!

Funny quote here. It seems like the time you've spent with Servoy has moved you farther away from FileMaker HJK. While being somewhat prominant in the FileMaker developer market, it would be political suicide to say Servoy IS better than FileMaker. However, I must point out that as a developer tool, FileMaker has missed the boat for many years. This is widely known, even by FileMaker only developers.

I love FileMaker for its simplicity, yet robust power to create comprehensive applications. While it does fit in many situations, where record counts stay in the low millions, the key word I used was simplicity. The simplicity of FileMaker, as a developer tool (I must point out my viewpoint of FileMaker is from a developer), is what holds it back from the larger IT favoritism that is desired. The environment has been long to adopt industry standards and when it does put them in, their implementation isn't always optimum. The lack of event support and reusable code is what drives a developer crazy - but this is also what makes FileMaker simple for the lower-end developer (we all have to start somewhere).

The fact that much of the interface is stuck in 1984, with black check boxes, is a testament to how slowly FileMaker has grown with current developmental technology (although their implementation of XML is quite good) These features are offered in Servoy and without the cost of having to create complex SQL statements. While the initial thought of JavaScript may be a deterant to some FileMaker developers, it should be obvious to most everyone that it's more powerful. This power requires more knowledge than is required by FileMaker, and those opposing Servoy are unwilling to admit they won't take the time to learn.

By my nature I'm a pragmatist and follow the "Best tool for the job" mantra. I've never been a fanatic, nor do I choose to heed the proselytizations FileMaker only developers offer about using a tool that doesn't fit the circumstances. Those FileMaker developers who vehemently oppose Servoy do so out of a fear based motivator. Afraid what they know becomes less useful because there are better tools for certain situations and they won't take the time to learn them.

I will continue to promote FileMaker for the great tool that it is. I enjoy providing education for any tool that benefits my personal livelyhood. For my advocacy around Servoy, VB.net or any other tool that has more power, my response is that first, I'm a developer and second, there is no such thing as an "end all, be all" tool for solving problems. We provide services or products based on what we know, and if a FileMaker developer is unwilling to learn Servoy or publicly lambastes it, then this is a sign of their myopic viewpoint on solving a technical problem.

Because of my public exposure as a FileMaker enthusiast, if I am to be ostracized by some of my peers for not being a pureist, I have only remorse for these relationships that suffer the lack of a pragmatic viewpoint towards human interaction and technology in general. One thing is sure about communities based around software allegiances - You find out who your real friends are really quick. I'm all for FileMaker, but I'm now all for Servoy too!

If you're a FileMaker developer and you're reading this post, my advice is not to judge though ignorance. Rather, tell yourself you'll take one full day and look at learning Servoy. Emulate a project you have in FileMaker and you'll be surprised at what it has to offer. I'm also not saying "Give up FileMaker". You'll see me using both tools - but maybe a bit more Servoy since I have better interface control, full event support, multiple db support, zero deployment (after Java is installed), revision control, a more robust programming language and greater scalability.

I've been thinking about writing a review of the two environments and comparing them for the positives and negatives they each have. Learning Servoy comes with all the baggage of having to learn an object model, JavaScript and knowing the specifics of your SQL backend. But this isn't bad baggage, it's just another set of luggage to help you make the trip from inception to solution!

[rochard]

Matt makes a good point about vehement opposition being a sign of fear; it is human nature when faced with an uncomfortable situation to either become hostile (the most common result) or to withdraw. We all live inside a box, the box in question is where we feel totally comfortable and safe, however in order to 'grow', we sometimes have to break out of the box and try new things. When we do that, we simply find ourselves in a bigger box which we gradually grow used to until it is time to break out of that one. The process is often painful. As a novice Servoy user, it takes me much longer, at this time, to do something that is extremely simply done in FileMaker but I know two things without question; the first is that when I first started using FileMaker it took lots of time to get things right and I made hundreds of mistakes. The second thing I know for sure is that it will, sooner or later, all become second nature and, like learning to drive a car, the process will all but be forgotten. As developers, we are problem solvers and there will always be multiple ways to solve any problem. Is one way better than another? Perhaps, but if the problem is solved, then what does it really matter? Ultimately, curiousity is what fuels human growth and 'What if ...? is the ultimate question not 'Why?'

[ahmad]

Hi there,

Filemaker 7 was released today with many new useful features. How can I prove to someone that Servoy will be ever better product compare to FMP?

Can you give me some top points so that I can explain to my managers

Thanks
Ahmad

[mattman]

Filemaker 7 was released today with many new useful features. How can I prove to someone that Servoy will be ever better product compare to FMP?

Can you give me some top points so that I can explain to my managers

I'm going to post some of the major items, when it comes to the advantages of Servoy over FileMaker. Some of these are my opinion and others are fact. Also, I wrote this in an afternoon without through proofing so mistakes may be found.

DISCLAIMER: I want to point out that FileMaker still has a place in many organizations, depending on the ultimate goals of the solution, the size of the organization and it's needs. Even VERY large organization have needs for tools with lower capacities to handle data. My guess would be, out of ALL businesses in the world, 70-80% of them could get by using FileMaker at some place in their business. But here are some issues to think about when considering Servoy.

SPECIAL NOTE: I encourage other FileMaker/Servoy developers who have worked with Servoy to comment on segments of this post and make your own observations. The comments and information collected here will be valuable for people attempting to make a decision about either environment. Being that this is a Servoy forum the lean here will be Servoy focused. I am aware of unmentioned FileMaker advantages - I have used it for over a decade.

1. DEPLOYMENT:

UPSIDE Concurrency Issues: Given you have 100 employees, if you want each employee to BE ABLE to use a FileMaker database ar some point in time, meaning an accounting person may connect to an expenses database and a graphic artist may connect to a workflow database, then you will need to buy 100 licenses. One license for each computer that would potentially connect. This is because a copy of FileMaker must be on each machine. The client is what runs the interface code. This is different than Servoy. With Servoy you can focus on the issue of concurrency. With the likelyhood of only 30-50 people out of your 100 employees connecting to the database at any given time you can start with 25 licenses of Servoy because installing Java on a client machine is free. Servoy calls their deployment a zero-deployment environment and that is fine, with the assumption that the lastest version of Java is installed. However, in most cases the latest version of Java (from Sun) is not installed on Windows boxes. With Mac OS X the proposition is a bit better. Running OS Update will bring Java up to the current version. Doing this on Windows requires an administrative push activity in organizations with a lot of computers. Once Java is installed, then, like FileMaker, there is no additional upgrades needed until Java is updated. And even then you may not need to update Java at each release. But you do get any benefits of a Java upgrade for free - at least currently ( I don't think Sun is planing on charging for Java ) .

DOWNSIDE Java can be painfully slow on older machines. Double-clicking to load can seem like nothing happens when the machine is older and slower. With FileMaker, things seem faster because you get that immediate gratification of seeing something happen. With Serovy, they are doing a good job of caching most of the application on client machines who have previously opened it. This means it will seem faster after the first time. But a slower/older machine will be perceptively slower the first time Servoy is launched. Java also has some issues currently with the Mac OS. Things just aren't as tight as they are on Windows. The drawing of windows and interface elements isn't as clean.

2. EVENT SUPPORT:

Servoy has a VERY robust event model. You can find event triggers for pretty much any action you can think of. When records are created, deleted, duplicated, taken out of a list view, added to a list view, moving from one record to another and many more. When fields are changed, clicked into, clicked out of or triggered by the return key, plus other events. Ultimately, this is more of an interface issue. The more you can do with event triggers the more flexibility you have in what you can do in your user interface.

FileMaker has NO event support. It pretty much has one type of action that will allow you to auto-update the contents of a field. This is triggered when the field is exited but cannot be control upon navigating to a record or when the field is entered. Neither application has FULL event support - such as mouseOver() and watching key events. Hopefully, Servoy will put in key event support as they will soon be provding the ability to create custom menus. In my 10+ years with FileMaker I can't tell you how many times the request has been made for supporting the ability to assign menu command keys and associate those to a script. With Servoy this will happen in a much quicker time frame than 10 or more years.

3. REVISION CONTROL:

Both systems will allow you to work on the solution while it is live. This allows for immediate minor changes, however, the similarity stops here. With both systems, development will typically happen offline with non live data. With Servoy, the process of making a new version of your application is as easy as clicking a button. The whole release is duplicated and you can start work on new features without fear that you'll mess something up in the production system. With FileMaker you must export all data from the current system and then import into your newer revision. This can be time consuming if you find out you need to go back to an older version. With Servoy, you click a button to revert to a previous solution. With FileMaker you would have to export any newly added data and then merge this with the original data existing before moving to the new solution. With FileMaker, a lot of this can be automated but still takes time. With Servoy, your data is not tied in with the interface. Servoy is the interface and it only interacts wtih the data. In FileMaker they are tied together.

4. INFRASTRUCTURE LEVERAGE & MULTIPLE DB SUPPORT:

Many larger companies have existing licenses of some type of SQL system. This allows them to leverage their existing investment. When it comes to concurrency issues they may not be hitting their limits and using Servoy allows them to maximize this investment. FileMaker IS it's own database, even though it will work with SQL sources. With Servoy you can have one solution that will interact with MANY various departments and multiple databases. It also doesn't matter where these data sources are. With Servoy you can have a solution that would use a Oracle system in Tokyo, a MySQL system in California and a Sybase system in New York. To do this with FileMaker would require a transport mechanism to move data from the three different locations, and this would not be live, there is some type of delay - it really isn't practical in a live system. In a disconnected system you can do this type of syncronization with XML or even email.

One other BIG advantage that Servoy has is the fact that it DOES use Java. With systems like iAnywhere from Sybase you can have a powerful database that will run on the Pocket PC a cell phone or any other device that will support Java. This is quite big for many corporations wanting mobile support. While FileMaker does have a mobile version it is nothing compared to what you can control in Servoy. You are locked into their interface and their way of doing things - not counting the record count limitations and field count limitations. Syncronization is also a big factor for some larger companies. If the database supports syncronization, such as iAnywhere, then you get the feature that many a sales force uses through Lotus Notes. The process of "replication" is one of syncronizing data on a client to the server. This means the client can work without a connection to the database. Currently this is easier to do on FileMaker (using FileMaker Developer and binding) and isn't possible with Servoy. Although Servoy has publicly indicated they are working on this remote client option.

5. INTERFACE FLEXIBILTY:

FileMaker is fabulously easy to work in when it comes to the interface. Each layout is a blank slate where you can exercise a great deal of creativity. However, FileMaker does not allow you to lock interface objects to windows and the windows do not scale to the visual environment being used. In Servoy you could create a form that satisfied the form factor of a PDA but will scale to the size of a 1600 X 1200 flat screen (although not advised) You also have a lot more native interface objects in Servoy. If you want a calendar in FileMaker then the task takes 10 times the amount of effort (although you can get native FileMaker calendars to integrate for free). While you can use the native objects in either environment, both allow you to create you own interface objects such as buttons. Servoy has more objects because of what is offered through Java. The use of HTML and JavaScript in Servoy make it much more powerful for displaying a wider range of visual combinations.

6. SCALABILITY:

FileMaker simply cannot match the scalabilty of Servoy. This is because Servoy is not the part that is scalable. It's the database backend that is. With FileMaker you are limited in the number of concurrent connections to the database. This is somewhere around 250. If you want to go beyond this you need to start splitting out sub applications and dedicating servers to certain groups of solutions. While this satisfies many companies, there are some who prefer to work with solutions on a selection of hardware that creates what is known as a cluster. With Servoy you're only limited by the hardware and the DB. If you are using MS SQL then you can cluster the hardware and Servoy will be able to work within this framework. A clustered DB can outperform FileMaker when there are a large number of clients connecting. FileMaker has announced that it will support dual processors, which is a move in the right direction. Out of the box, a server used for Servoy with the exact same hardware for a FileMaker server will support many more connections. Thousands compared to 250.

7. REPORTING:

I haven't done enough reporting in Servoy to comment. Maybe someone else can.

8. OTHER AREAS:

Suggestions for other areas welcome.

Please post your findings to this thread.

[ahmad]

Hi Matt,

Thanks a lot for the valuable comments. I have been developing in Filemaker for more than 3 years. We feel that Servoy is a boon for our company for the advanced functions. Things we wish for years in FMP is been done is hrs by Servoyians.

But we will be also working on Filemaker in which we are expertise to some extent and to support our existing clients too.

I'm not very good in making a comparison as you did. But I will love to hear more from you people

Thanks
Ahmad
Hong Kong

[Riccardino]

8. OTHER AREAS:

Suggestions for other areas welcome.

Cost. Maybe a trivial subject, but I recently had a couple of work refused by the customer not because of the cost of my FileMaker application, but because the total cost of FileMaker and FM Server licenses was tripling the global cost. In a case like this, the developer is defenseless, because the problem is not related to the quality of his work or FileMaker's reliability.
With Servoy, you can provide an alternative and get the job.
That's why I don't see Servoy and FileMaker as rivals: each one of them could be the right tool for the job.

[AHunter3]

Hi! I'm a FileMaker geek from way back when. I'm looking at Servoy now not because of the differences between the two and ways in which Servoy might be better, but rather because with the advent of FileMaker 7, FileMaker is no longer familiar territory (they changed so much it's like having to learn an entirely new program) and Servoy and FileMaker are now much more similar in a lot of ways.

e.g., no one works on a dev copy of FileMaker and then imports all their data any more. Under 7, you put all your programming in one file and all your data in another. Or else you work on the live copy (the only thing you can't readily change without kicking users out is Field Definitions, and in Servoy you'd have to do interesting things to add, delete, or change the names of columns in the backend SQL database, yes??

e.g., modularity of code, it's not quite as reusable even in 7 as some other environments, I suppose, but no more writing duplicate scripts in several different files M-^W now that all your tables can be in a single file and your scripts likewise there's a lot less reduncancy

e.g., user-hostility and complexity, FileMaker 7 appears to represent FileMaker's determination to catch up with the rest of the database world in making solutions design less easy. (sigh). Easy keyboard navigation of the ScriptMaker is shot to hell and the newfangled Relationships setup screen is a nightmare.

BTW, if you're a FileMaker geek and you're investigating Servoy, you might want to look at Witango as well. I'm trying to become tolerably proficient in all three.

[bcusick]

BTW, if you're a FileMaker geek and you're investigating Servoy, you might want to look at Witango as well. I'm trying to become tolerably proficient in all three.

Ah! Tango lives! Hilarious. I thought that product had died and gone to heaven.

From their website:

This product suite was formerly known as Tango and was previously owned by Pervasive Software and before them, Everyware Corporation. The product has been in existence since 1996.

Thanks for the update and for sharing your opinions!

Cheers,

Bob Cusick

[Riccardino]

e.g., no one works on a dev copy of FileMaker and then imports all their data any more. Under 7, you put all your programming in one file and all your data in another.

That's pretty funny, because I read (and joined) a lot of discussions about the implementation of a TRUE separation model on FileMaker 7, and the result is quite opposite to what you're saying (unless you count a 300% of extra work).

PS: Of course, FM7 is a step forward, but if you have to mantain and upgrade your solutions spread across a large geographic area, you need to have Data really separated from Interface and Logic. But trying to build a FM Solution which keeps data in a file containing only fields like text, number, date, time and container (no calcs, no relations, no scripts) can be a very complicated matter.

[david]

PS: Of course, FM7 is a step forward, but if you have to mantain and upgrade your solutions spread across a large geographic area, you need to have Data really separated from Interface and Logic. But trying to build a FM Solution which keeps data in a file containing only fields like text, number, date, time and container (no calcs, no relations, no scripts) can be a very complicated matter.

Yes, the number one debated subject on various FM lists is which is the best way to keep your data tables separate from interface and logic (in FM 7). Nice not to have to think about how to make a program work the way you need it to.

- David