4 ms·
CFML ?
by ValentinA23 2y ago
CFML ?
- bdcravens 2y agoColdFusion Markup Language
- acdha 2y agoCold Fusion Markup Language - the CF application server was really popular in the 90s and early 2000s because it was a fairly approachable HTML-like templating language which had some good shortcuts for things like form processing and was cross platform in an era where that mattered more along with supporting most popular databases. The thing which killed it was poor performance (PHP 3 was 10-100 TIMES faster in tests I did for our customers) and Adobe-level support. They milked customers mercilessly and refused to fix even major bugs – as an example, we had an app which generated a report table like this (I forget the exact syntax): <cfloop query as row> <tr> <cfloop row as col> <td>… They had a bug using a shared pointer internally so that would print the first row over and over for the number of rows. We reported this. Not fixed, but then they told us the next paid upgrade might fix it. It didn’t and we moved the remaining customers to PHP, which we’d already been going for features.
- tombert 2y agoIIRC performance got considerably better when they moved to a JVM-based thing, but yeah it was always pretty slow. It doesn't help that they sort of advertised it for non-programmers, meaning that there wasn't exactly hyper-optimized code being written to begin with. I one time worked for a company that had a import on the top that called every single SQL query as part of the template, meaning that there was about ~20 SQL queries running sequentially on every page load. I think just using the built-in caching for it improved performance by an order of magnitude by simply utilizing the built-in caching. I think what killed Coldfusion was really the price. PHP was free, open source, faster, and also had easy templates integrated into the language. Why pay an absurd license fee for a slow language when you can get something comparable for free?
- acdha 2y agoThe JVM pivot helped but IIRC it was still far behind PHP. If memory serves we noticed it most on database drivers - PHP used the native bindings but CF used ODBC/JDBC and that hurt them a lot for reasons I assume we’re not easy to fix. There was a usability argument for CF in some cases but as you noted it wasn’t enough to cancel out being proprietary, especially once there was a stable of people with PHP experience to hire. > I one time worked for a company that had a import on the top that called every single SQL query as part of the template, meaning that there was about ~20 SQL queries running sequentially on every page load. This is bringing back painful memories of the time I was billed out at some obscene rate to do some overtime bailing out a client (local utility company). We’d had the design side of a product locator site but they’d given the software side to a bigger contractor, and 12 months into a 4 month project they were missing half of the features and the developers were telling them they needed to drop a million on a high-end server to handle the database. I looked at it and quickly found the problem: none of the developers knew SQL well enough to know how to filter a JOIN, so they had multiple nested ASP loops which were retrieving hundreds of millions of rows, using an if statement to decide which ones matched the active filters, and then did more queries in the inner loop. The client paid double our normal rate for me working a few late nights, got five orders of magnitude better performance, and had a very interesting conversation with the original team about the money they had been billed for people who clearly weren’t the senior engineers they’d been paying for.
- tombert 2y ago> PHP used the native bindings but CF used ODBC/JDBC and that hurt them a lot for reasons I assume we’re not easy to fix. Tangential, but JDBC, even in the year of our lord 2024, has been one of my biggest headaches for performance. I have a pretty decent job with a very decent manager, so I started replacing as many JDBC calls that I could with Vert.x and got considerably better performance, I think because JDBC is so block heavy and threads just spin idling a lot. > none of the developers knew SQL well enough to know how to filter a JOIN, so they had multiple nested ASP loops which were retrieving hundreds of millions of rows, We didn't have hundreds of millions of rows, but at the Tae Kwon Do studio I worked at (who had their own martial arts management software), the initial person who wrote it wasn't great with SQL, and for the "belt management" service the person who wrote it was similarly doing lots of nested loops and conditionals on those loops, all in Coldfusion. Another employee that was pretty good at SQL ended up rewriting everything with a lot of clever joins, views, where clauses, brought down the runtime by like three orders of magnitude.