In the last few months, weâ€ve been busy adding a whole new set of amazing features that will be available in the next release of SmartClient and SmartGWT.
We have already announced some fantastic additions to the framework in our previous posts (Part 1 / Part 2 ), and now thereâ€s even more to extend the power and flexibility of SmartClient and SmartGWT!
This post shares just another taste of some of the new enhancements we have made recently.
FacetChart Databindingand Improvements
Historically, Charts have had their data values set by using the SetData() and updateData() APIs to set a static view of the chart.
In release 13.0, weâ€ve enhanced FacetChart to be a DataBoundComponent. The new features support a fetchData API that takes criteria and other DSRequest settings (like sorts), just like grids do, and will perform local filtering of data if criteria changes. So you can now easily create a drill-down interface that doesnâ€t require server contact.
OpenFin enables you to build multi-window desktop apps that look and feel just like natively installed apps so you can maximize your desktop real estate. Your windows can sit anywhere on the desktop, with or without frames. Apps you don’t actively watch can be minimized and automatically pop up when needed.
In collaboration with one of the worldâ€s largest banks, our support for OpenFin means you can now create desktop applications that can open windows on multiple monitors.
Sharper Imagery
We’ve massively improved the quality of our internal imagery, so no matter how much you zoom in, you’ll still get the crisp, clean, seamless image view that you need.
SplitPane AutoNavigate
SplitPane component just got smarter. Using an “Auto-navigation” approach, SplitPane analyzes the controls placed in each pane and the DataSources they are bound to. It then automatically navigates between panes at the right time based on the actions that you take.
If you want to see what’s available in V13.0, download the V13.0 Pre-Release from our Downloads page.
If you want to upgrade early to V13.0, upgrade discounts are available based on your last license purchase date. View our License FAQs for more details, or contact us to discuss your upgrade options.
We are proud and pleased to announce that V13.0 of SmartClient and SmartGWT is officially here, with tons of fantastic new features. We’re sure you’ll agree it was worth the wait.
Some of the great features we have added to V13.0 are:
Once you have purchased your upgrade, Download Release 13.0 to get started (don’t forget to log in first)!
As always, please send us any bug reports or feedback in the Forums. Please be clear about what product and version you’re using when reporting issues, including the exact date of the build.
That is exactly why applications exist and why we are all employed to provide them.
However, as developers, we sometimes get excited about new technology and the benefits they claim. For example, a basic grid component with a very small amount of source code – but this is the wrong focus because such lightweight components not only damage productivity due to their lack of features. They also damage the real-world performance of applications. Let us explain.
What drives productivity in today’s web applications?
Driving Productivity
End-user productivity – from a platform perspective – is driven by:
Advanced UI features (i.e. performing activities with fewer steps / clicks / screens / actions).
Performance & scalability (i.e. getting the result of each activity faster).
Without these key deliverables, you will always struggle to get product adoption and ultimately the efficiencies and improvements that the application was written for in the first place.
Can we build high-productivity applications with lightweight components?
There are a number of areas where lightweight components consistently fall short or fail to understand true enterprise requirements:
Wrong performance focus
People are excited about lightweight components, particularly grids, which claim to be able to render 10,000 or more rows in a reasonable time in the latest browsers. Developers often think this means that they can skip implementing data paging, and can use client-side filtering and sorting to improve performance. The reality is:
There is a reason not to load 10,000 rows in the database and it’s not the browser.
It’s not important that a grid can render a lot of rows all at once. The purpose of loading rows incrementally was always to avoid unnecessary database and application server load, as well as avoid wasted bandwidth.
10,000 rows is not a reasonable upper boundary – nor is 100,000.
Business data sets routinely get much larger, especially when you consider administrative interfaces that look at data from many users at once. If you ship an application that expects to load all data upfront, it will break in production as data volumes go higher than you had assumed.
Client-side filter & sort is achievable with Isomorphic grids – but not with lightweight component grids.
Our Adaptive Filtering technology automatically switches to client-side sort & filter when data sets are smaller, so you can handle extremely large data sets and reduce server load and bandwidth use. This capability is why Isomorphic grids dominate performance comparisons that simulate actual end-user behavior.
You can only render rows faster by removing features.
Isomorphic’s grid component uses a complex HTML structure because it supports a huge variety of productivity features, like auto-sizing of both rows and columns, on-the-fly column freezing, row-spanning cells, components embedded in rows, on-the-fly grouping, as well as many developer override points that require particular HTML structures in order to work.
We know exactly what simplifications would result in rendering more rows per second. We intentionally don’t apply those simplifications because they would remove productivity features, while not actually improving real-world scalability or performance.
Productivity comes from feature-rich components, not lightweight ones.
Consider grid components. End-users need capabilities like edit inline, freeze columns, grouping, sorting, formula columns, adaptive filtering, hiliting, export, drag & drop, etc. Without these and other features, performing simple tasks requires end-users to complete multi-step processes. For example:
With edit inline: End-users click a row or cell, edit the data, then move on.
Without edit inline: End-users select a record, click an edit button, are taken to another screen, perform the desired update, save the record, and return back to the starting point – hopefully without losing context.
Without feature-rich components, your application can become a frustrating time sink rather than a productivity tool. This is all too often missed with the adoption of lightweight components.
Forgetting something? Server integration!
Full server integration
Some of the most powerful features in modern UI technologies span both the client and server. Examples from Isomorphic’s technology include:
Single source validation & security rules. Validation rules declared in one place are enforced on the server (for security) and the client (for immediate feedback).
Automatic UI generation. Grids, forms, and other components can be automatically configured from server-side artifacts such as Java beans and database tables, greatly reducing redundant declarations and making applications easier to maintain.
Exports. Isomorphic’s UI components know to coordinate with our server framework to export themselves and their data to Excel, PDF, and other formats. Every application needs this!! it can be a huge effort to build from scratch.
Starting from a lightweight components, client-only framework puts you years behind the state-of-the-art solutions for UI technology, before you even consider which UI components to use.
Mixing components never worked, and still doesn’t
Most of the new crop of lightweight components frameworks emphasize the ability to plug-in components from different sources, so you can get the best of each component type. This should all work since they share a common data-binding system, right? Wrong, unfortunately:
Accessibility requires intensive coordination between components about tab order, modality, and ARIA markup.
Really trivial cases where just a few rudimentary components are combined will appear to work, however, when you have a lot of instances of dynamically changing tab order, multi-level modality, and the like, there’s no way to get components from different sources to work together and actually pass accessibility tests.
Skinning conflicts.
Skinning conflicts
Each component has a slightly different look and feel, and it can take a lot of work to correct the mishmash of different fonts and styles so that an application looks reasonably consistent.
Especially when fonts are made consistent, the sizes of various controls and sub-controls used in the app may need to be adjusted to fit the adjusted fonts.
Also, some frameworks make conflicting assumptions about CSS they can globally apply to the whole page, breaking other frameworks or components on the same page (e.g. Bootstrap).
Export and print support.
This is a rare feature among lightweight components, yet most applications require it, and just one component lacking support can ruin the ability to print or export a particular screen or report.
Internationalization and localization.
Internationalization
Pulling components from multiple sources typically means that localization work has to be repeated for each component, as every component needs the local word for “OK”, or to be told what date format to use.
Inconsistent quality and endless evaluation.
There is the practical consideration of whether it makes sense to constantly hunt for lightweight components. One grid has inline filtering but no frozen columns. Another has frozen columns, but no ARIA support for inline editing. A third has a nice date filtering interface, but it looks and operates completely differently from a date filtering interface you’re using outside of the grid, which will surely lead to user confusion.
Support.
Even if you succeed in finding a workable set of lightweight components, you may find later on that your bug reports are ignored by one team or another. If support is even available for your chosen components, how many separate support agreements will you be purchasing?
What about the many bugs that are not quite just one vendor’s fault? For the many single-component OSS projects, is there any reason to think the project will last as long as you need to maintain your application?
So are lightweight components always a good thing?
No, they’re not!! Especially when you’re up against true enterprise heavyweights. SmartClient has the richest set of UI components available, coupled with deep server integration to bring productivity and performance to your enterprise applications, with no need to look elsewhere.
Last week we talked to a Principal Scientist (let’s call him Ken) at one of the worlds largest pharmaceutical companies. Ken gave us some really great insight into why and how they use SmartClient.
Ken’s organization provides software support (at varying levels) for thousands of in-house scientists scattered across “innumerable areas of expertise and roles”. Scientists come to his group when they need customized or unified solutions from software developers with domain knowledge.
The web applications that Ken’s team writes are obviously used by people who are highly educated. Their time is precious and their patience low. They demand “solutions that are highly sophisticated“, and they have “uncompromised expectations on ease-of-use.” They “have many ideas, theories, and hypothesis that they want to explore”, so there is a long list of web applications to be developed, and also a long list of feature requests raised as their hypothesis unfold. Their work also generates and requires analysis of “huge volumes of data“.
For Ken, these demands meant he needed a platform that:
Can handle volume data from both performance and a usability perspectives
Has intuitive, high productivity UI components
Supports rapid development of web applications
Ken’s Results
With several years experience using SmartClient, Ken said:
I really like Smartclient because I can create new solutions quickly and then easily adapt to user’s feature requests as they evolve because it’s usually only a matter of re-configuring how I’m creating Smartclient objects. I don’t need to be too careful about collecting all possible use-cases up front because when they come to a new understanding of their own expectations, I don’t need to tell them that we’d need to change technologies to deliver their new ideas.
ListGrid, FormItem, and DynamicForm are the key widgets I turn to.
I also highly value the support forum. I imagine that my needs which are sometimes off the beaten track, so I highly value the rapid turnaround on enhancements, bug fixes and/or suggestions.
Here are just a few of the solutions Ken’s team built this year (note that all of these are leveraging our new ‘Tahoe‘ skin):
#1 Bulk Data Handling – “PPB Editor”
The PPB Editor (you can think of it as an electronic lab notebook) was written to enable scientists to rapidly load bulk data into a 3rd party data storage solution. The 3rd party had provided their own GUI, but it was too tedious to use at the scale the scientists required. It also didn’t match the scientist’s workflow. Furthermore, by writing their own interface, they have a convenient place to implement their own business rules (e.g., autocalculators and validation) to help people conform the raw data they collect to expectations set by the business and to support analytics. In particular, SmartClient helped with the following:
Binding to Datasources extremely quickly
ListGrid Expanding rows capabilities to allow additional information to be accessed without adding an unmanageable number of columns
FormItem was also a key feature, particularly since a class can be defined once and reused in both ListGrid and DynamicForm contexts. This meant that in their bulk editor, they can leverage multiple widgets to update the same data – saving much development effort and providing the scientists with the optimal UI.
The Mylo tool is for analytics to help scientists find and/or explore new design ideas with experimental data previously collected. This application required the depth of functionality offered by SmartClient components. The following were critical:
The Plate Layout tool came about when a scientist described an upcoming technical challenge to Ken. Ken then created a GUI in less than one day that the scientist could use to test a hypothesis.
For Ken, the ability to rapidly develop web applications makes SmartClient indispensable in the pharmaceutical research and development environment.
Many web frameworks have very advanced support for the so-called “CRUD” operations, that is, Create, Retrieve, Update, Delete, also known in SQL as Insert, Select, Update and Delete. Often, when developers see the CRUD features in these frameworks – like data grids that know how to perform CRUD operations, as in SmartClient – they react by saying: well, that’s great for CRUD stuff, but my application only has a few database tables and has a lot of non-CRUD operations. Most of these features don’t apply to me.
This perception is quite wrong, as we will come to see. The reality is:
Many operations that are perceived as “not CRUD” are actually CRUD operations: People confuse CRUD with “business objects stored in a database”. CRUD is actually far broader than that – it basically encompasses any operation performed on something that can be modeled in the object-oriented style. We’ll see several examples of this.
CRUD modeling almost always helps, and never hurts: CRUD-style modeling of seemingly non-CRUD operations is almost always beneficial. It can bring benefits in terms of automatic error handling, performance, monitoring, and in many other areas. It also makes your “non-CRUD” operations easier to understand because they are handled in the same way as normal CRUD operations.
The Myth: My application has lots of non-CRUD operations
The idea of CRUD originates in ER (Entity-Relationship) modeling. The first thing to understand about ER is that ER models simply reflect the way humans think. ER models are a natural representation of data, not an artificial one invented to make coding easier.
Specifically, humans naturally group things into types of objects (cars, people, orders, buildings, etc.), and those objects have attributes (cars have color and number of doors, people have name and height, orders have ship date and a status, buildings have total number of floors, architectural style, and so on). The core of ER is just this: there are objects, and those objects have attributes, and can be related to each other.
Because ER really just reflects the way people think, ER modeling really applies to almost everything, not just to a narrow range of classic “business objects” like People, Accounts, and Orders.
Further, ER modeling has nothing to do with how data is stored or even whether it is stored permanently at all. ER modeling is just a way of thinking about and describing something. ER modeling is not limited to SQL, and can even be applied to completely ephemeral client-side concepts that never have server storage (for example, outstanding requests).
ER is also the conceptual underpinning of object-oriented programming. This means CRUD can also be applied to anything you might create as a class in an object-oriented programming language such as Java. “Create” is calling the constructor, “Update” is calling some setters, “Delete” is explicitly or implicitly discarding the object, and “Retrieve” is filtering a list.
With this clearer and broader understanding of what CRUD really means, let’s look at some examples.
Supposedly “non-CRUD” operations that are absolutely CRUD
In my experience, it’s very common for a developer to incorrectly assume that a given operation can’t fit in an ER model, and then go off and implement something custom, throwing away the massive benefits that a framework can offer around ER models – not just performance, but simplicity: error handling, uniform code structure, and other benefits.
Here are several recurring examples that will help to understand just how often “CRUD” works as a modeling strategy:
1. Background processes
You need to kick off a long-running process on the server. Well, initiating the process is an “add” of a new BackgroundProcess record. Checking on the process is a fetch of a “BackgroundProcess” record by its unique ID (and/or userId for multiple such processes), and the status of the process is simply a field on the BackgroundProcess record.
Is there an output of the process, like a URL or file? That’s just a field in the record that is non-null once the process is completed. Want to cancel the process? That’s just a “delete” of a BackgroundProcess record.
2. “Documents”, “files” or other blobs containing non-ER content
You may have an OOXML document, binary image, XML/JSON blob, Java-style .properties snippet, or whatever. The interior content – the OOXML document, for example – may not be modeled in an CRUD/SQL style.
You may be storing it in a “NoSQL”-style DB. None of that stops you from representing each such document, image, or file as an entity/object/row in an ER model.
There are key metadata fields – lastUpdate, ownerId, dateCreated, etc. – that fit perfectly into an ER model, and allow you to leverage caching, validation, and error reporting features that are built-in to the ER model. The “special” field – the one containing the blob of content that is not an ER model – is just another field of the record.
3. Asynchronous messages & reliable delivery
Sending a message is an “add” on the Messages table. Use a subsequent “fetch” to check the Message status, whether it was delivered, had an error, etc. Want to cancel a Message that may not have been delivered yet? That can be an “update” to set status to “Cancelled”, and if it’s too late to cancel message delivery, then that’s a validation error on the status field.
4. Login/sessions
Logging in can be represented as just a “fetch” on the User table with hashed credentials. If login is successful, the active sessionId is returned as a field value. Then, retrieving session data is a “fetch” on the Sessions table with sessionId as criteria. Logout is a “delete” on the Sessions table.
5. Calculations, estimates, or quotes
Why not represent these as a “fetch” on a Calculations table, with inputs to the calculation expressed as criteria? Automatic caching can prevent duplicate calculations.
You can apply validators to inputs to the calculation, and you get client and server enforcement. Putting a quoteDate field on a Quote entity allows you to express validation rules, such as making sure that no save relies on a Quote that is too old. And so on.
6. Exceptions or error data
Perhaps something can go wrong in a long-running process or server workflow. Store these as “Errors” or “Exceptions” so you can look them up by the ID of the process, workflow, or whatever system may run into issues. Then you can later “delete” them or set status to resolved, etc.
How to find the CRUD way of looking at a given operation
Many developers have a kind of “reflex” to take any operation that isn’t a SQL operation on a business object and assume it needs to be represented as a custom, non-CRUD operation. The reality is that it’s rather rare to find an operation that cannot be understood as a SQL-like operation on an entity; almost everything fits into the CRUD model, and fits in cleanly (not as a hack!).
If you believe you have an operation that simply cannot fit into a CRUD model, first, simply try to describe what needs to happen as if speaking to a colleague. Doing this, you will often just trip over a natural CRUD representation: “I need to start a new background process.. oh.. that could be an add on a BackgroundProcess entity”.
If you miss the opportunity to represent an operation as a standard CRUD operation, you will miss out on automatic validation handling and/or intelligent caching that would be automatic if you used the standard CRUD approach, and worse, you will often end up building unnecessary, bespoke versions of capabilities that are built into the core CRUD model.
For example, multiple times, I have seen people build a form to kick off a background process, and once they realized there were error conditions to handle, they went and created a custom error reporting format and added custom code to the form to receive, process, and display the error.
This is all totally unnecessary – represent the operation as an “add” of a new BackgroundProcess, and all of the above is automatic. That includes client-side checks that can prevent an invalid request from ever needing to be caught by the server!
Use CRUD even when it’s really not CRUD
Let’s say you’ve found an operation that just really is not CRUD. There’s just no way to conceptualize this operation as an operation on an object, even with the above tools, which enabled us to think of something as abstract as a calculation as a CRUD entity.
This is a rare situation. And even in this situation, guess what: you still want to use CRUD.
Consider the core CRUD operations, forgetting for a moment that they are usually conceptualized as operations on sets of similar objects. Instead we’ll just look at the inputs and outputs in abstract form:
Create: Takes a series of inputs with specified types, returns something (typically an ID or the entire new record)
Retrieve: Takes a series of inputs with specified types (criteria), returns a list of similar objects
Update: Takes an ID and a series of inputs with specified types, returns something (typically a status, or the updated record). Alternatively, no ID, just a series of inputs with specified types (for multi-record updates)
Delete: Takes an ID, returns something (typically just a status, or the number of affected records)
These operations are so fundamental that they can used to model basically anything. In particular, “Update” and/or “Create” can model any method call.
So, forget about ER or object-oriented modeling for a moment, and just consider the fundamental inputs and outputs of the operation you’re implementing.
Does your operation take a couple of inputs that come from an end user typing something in, and can there be validation problems with those inputs? OK, use CRUD (“create”). Otherwise, you will reinvent validation handling.
Does your operation return an Array of Objects? Use CRUD “retrieve”. Then you don’t have to invent your own bespoke protocol for passing inputs and receiving outputs. Also, if you ever want to display things in a grid or drop-down, or ever want searching and sorting, it’s free – it comes as a free benefit of representing your operation as a CRUD operation of whatever type.
In short, if you ever have an error case that is relative to a specific input, it’s CRUD. If you ever get back a list, it’s CRUD.
Yes, CRUD really is that universal.
The benefits of applying CRUD
OK, you’ve been convinced that any operation can be modeled via CRUD. Let’s circle back and remember why that’s important: it’s because many frameworks offer a lot of really advanced features and optimizations that apply to CRUD.
If you make everything CRUD, you get to leverage all of those features. And, as we’ve discussed, CRUD modeling is a natural approach for virtually any operation – so you’re not using a hack if you model things as CRUD, in fact, in most cases, CRUD modeling adds clarity and uniformity, making your application easier to understand and easier to maintain.
As a final point, here are just some of the benefits you get when you use CRUD modeling in our technology, SmartClient:
An instant form for providing inputs to the service, with editors that match the specified types of your inputs (for example, a drop-down for an enumerated input, or a date editor for a date input)
An instant grid or detail view for showing the results from the server
Per-input validation and standardized error handling, including, for example, displaying errors for end users
Many, many built-in optimizations around caching of responses, or catching validation errors before the server is contacted
Built-in tooling, like being able to interactively test your operation with an auto-generated form for inputs, and auto-generated display of outputs (field by field, or a data grid). Also, that auto-generated grid gives you search/sort/pivot/grouping, and can export to spreadsheets, JSON, XML or other formats.
The ability to work with your operation in Low Code visual designers like Reify.
What’s not to like?
If you have any feedback on this article, I would love to hear from you! The best way to get in touch is to Contact Us.
About the Author
Charles Kendrick has been the head of Isomorphic Software for over 20 years. He is the Chief Architect of SmartClient and Reify. Both products are heavily used and very popular amongst the Fortune 500. He has successfully worked with and coached dozens of teams delivering high performance systems and is a pioneer in the field of web application optimization.
Recently, we talked to a prospect who was building an ETL (Extract, Transform, Load) front-end, and found out that they were doing it in an SSR framework.
This is insane. Truly and completely nuts.
To set the stage for this discussion, there are two basic models:
SSR (Server-Side-Rendering) and
CSR (Client-Side-Rendering).
An SSR framework renders the content shown to the end user on the server. A CSR only pulls data from the server, then renders all content inside the browser.
Just speaking in general of apps, a CSR offers the following benefits:
Massive scalability: anywhere from 30-90% of requests cause no server load at all, and provide instantaneous response to the user.
Rich, productive UI: huge suite of powerful components, well beyond SSR frameworks.
Radical productivity: simple programming model with drag & drop and low code design available.
Cacheable & offline: the entire application is cacheable, and almost all application functionality is available offline.
The app can be readily packaged as an installable mobile or desktop app.
Radical scalability, radical responsiveness, and extremely rich UI: this is what characterizes Isomorphic SmartClient’s CSR approach.
In comparison, an SSR architecture offers:
1. SEO
….
Oh wait, we missed one:
If you are accessing an SSR app for the first time ever,
and you are on a phone,
and the site involved doesn’t have an app it recommends you download,
and you happen to have never encountered the CSR libraries involved so you don’t already have them cached.
Then perhaps, on an antique smartphone, SSR might edge out the initial CSR render time by a nose: ~200-500ms. Maybe. All subsequent requests will be much slower with SSR.
Now, let’s examine CSR vs SSR in the context of an enterprise app.
Think of all of the enterprise apps you know: ERP, CRM, ETL, BPM, BI, SCM, PLM, IAM, DMS..
Do any of these involve SEO? Do any of these apps need particular screens to rate high on Google?
No.
So, let’s revisit the benefits of CSR vs SSR in the specific context of enterprise apps:
CSR:
1-5. same benefits as before (radically scalable, instant response, productivity, etc.), only more so. Long session times amplify all the benefits.
SSR:
1. …. well, crap!
That’s right – absolutely nothing.
So if it’s that bad, why SSR at all?
Imagine an app that benefits from SSR. What are its characteristics?
SEO is paramount – it’s trying to attract maximum traffic from consumer-level users.
Reducing server load is actually kind of bad: it’s actually better if there are more hits on the server, because the app’s success is gauged by views, not productivity.
Pages are very simple – there is limited benefit from client-side interactivity because we’re offering a “lowest common denominator” UI.
This rings a bell.. ah yes, that’s a social network. That’s Facebook! That’s Instagram!
It’s also (kind of) eBay, or Etsy, or maybe Amazon’s product listings – all sites that want to attract maximum attention from search engines and have limited interactivity (just buy and check out).
And that’s the #1 reason SSR is visible as an approach at all.
It’s because these social networks and large ecommerce sites have very good reasons to use SSR – all of it fundamentally rooted in their need to maximize SEO, and their very limited interactivity.
So, developers see these massively successful sites and their huge valuations and think: well, anything good enough for those megasites should be good enough for my ERP app.
But this actually makes no sense at all.
The #1 benefit of SSR (SEO) has zero relevance to your ERP, ETL, PLM, whatever app. Zero.
Indeed, people need to log in to view the data in your app.
If the confidential data in your app were to be visible on a search engine, guess what?? You’d be fired!
So why are you picking a framework that emphasizes appearing in search engines??
What you actually need are all the benefits of a CSR architecture listed above: rich, sophisticated UI, easily built. Immediate responses with no server load.
Reason #2 – Follow the money!
Reason #2 is a little darker.
I’m going to veer a bit off-script and tell you what’s really going on.
“Edge services” companies (companies with networks that extend into every ISP and every physical location possible) can make a lot of money from apps that need to get compute power as close to end users as possible.
In a CSR (Client-Side Rendering) architecture, what you need to deliver to the “edge” is just a static file – some JavaScript, maybe some SVG for icons – no compute power involved.
There are many “edge services” for this (CDNs – “Content Delivery Networks”), and it’s inexpensive.
Honestly, in the context of the costs of enterprise application development, the cost of maximally delivering your application to “the edge” in a CSR framework – it’s basically free.
It’s not a cost that even registers in the overall scheme of things. That’s not good for “edge services” companies.
SSR architectures are much better for edge services companies.
They want as many apps as possible to use SSR approaches, because then, many more apps will require their services in order to perform well.
This isn’t MKULTRA or COINTELPRO here, it’s just basic economics. These companies would like to promote this architecture. If people use it, they make more money.
“It’s scalable” – the zone is flooded with ****
If you Google CSR vs SSR, or if you ask ChatGPT for a comparison, you will, amazingly, in your first foray, be told that SSR frameworks are “more scalable” than CSR frameworks such as SmartClient.
It’s hard to convey just how absolutely insane, how gibberingly off-the-charts, how mad-hatter-snorting-mercury this is.
It’s simple to understand:
An SSR with edge services can try to make a given request very fast.
A CSR means the request never happens, at all, edge services or no. It’s instant.
Another way to come at it: you can spend as much money as you want on edge services. A CSR is still infinitely faster. Because the server request neverhappensatall.
If that still isn’t clear, imagine being offline on a hike where you (unfortunately) really need to access some data you were recently looking at. CSR: instant response. SSR: … waiting…
Need further confirmation?
Having asked about CSR vs SSR benefits, and having received the default response, raise the above points with ChatGPT.
It will immediately backtrack on its claim that SSR is “more scalable”, and you will see headlines such as “Does SSR ever make sense?”. Because that’s the reality.
Conclusion
When it comes to enterprise apps, there is absolutely no question: a CSR architecture (like SmartClient’s) is vastly, vastly superior.
Certain enterprise developers are, through pure naivety, picking SSR architectures because:
They are wrongly thinking that Facebook’s architecture is the right one for their BPM, ERP, CRM, PLM, etc. app – even though the requirements are opposite!
They have been bogusly influenced by marketing from edge providers, who literally want them to pick the worse architecture!
Don’t be naive.
Any competent developer should be able to see through the noise and make the right choice.
Join us and move faster than anyone imagines is possible!
There is an ongoing shift in the Java ecosystem from JavaX to Jakarta, which is creating real headaches for developers and software vendors. At SmartClient, we’re stepping up to help our customers navigate these changes with practical tools and clear answers.
We’re excited to share that our upcoming product lineup will bridge the gap between the older JavaX APIs and the newer Jakarta APIs. In this post, we’ll break down what this means and explain how SmartClient is adapting to make Jakarta API transition easier for you.
What happened to Java?
Oracle’s loss in a lawsuit against Google prompted a reorganization of the Java APIs. The reorganization moved classes from the javax namespace to the jakarta namespace. While the functionality remains the same, the reorganization has resulted in incompatibilities between pre-transition (javax) and post-transition (jakarta) APIs.
Teams upgrading to Spring Boot 3.x are hitting roadblocks due to SmartGWT’s reliance on javax imports.
Wildfly 27 users are stuck because it exclusively supports Jakarta APIs, leaving pre-transition applications unsupported.
Projects dependent on javax APIs face a tough choice: rewrite their code for Jakarta or stick with the old namespace and risk falling behind. Across the globe, organizations are navigating this messy transition, guided largely by their existing dependencies and long-term strategies.
How SmartClient supports the transition from JavaX to Jakarta
Some customers have been desperately asking us for a Jakarta (post-transition) version, and then other customers insist on sticking to the older JavaX (pre-transition) version. We can’t satisfy both needs with a single version of our product. Every vendor all over the world has the same dilemma right now (thanks, Oracle).
To address the needs of our diverse developer community, we’re releasing three separate product versions that cater to both API structures:
SmartClient 13.1 (JavaX APIs): Designed for developers who continue to use the javax namespace. This version maintains compatibility with pre-transition environments.
SmartClient 14.1 (Jakarta APIs): Fully aligned with the new jakarta namespace for projects adopting the updated Java APIs.
SmartClient 14.0NJ (JavaX APIs with 14.0 Features): A transitional release offering javax namespace compatibility alongside the feature set introduced in SmartClient 14.0. This version is available exclusively through a special support plan with Isomorphic Software.
By offering separate versions, SmartClient ensures developers have the flexibility to align with their project’s requirements while maintaining access to our latest innovations.
Hibernate and Spring Compatibility with Jakarta APIs
The transition to the Jakarta namespace has brought changes to widely-used libraries like Hibernate and Spring, which in turn have influenced SmartClient’s integration with these technologies. For Jakarta versions of SmartClient:
Hibernate: We’re discontinuing support for “beanless mode,” a feature that has consistently been outperformed by our SQLDataSource in terms of speed, simplicity, and flexibility. We continue to recommend SQLDataSource as the best choice for SQL database connectivity. Core JPA/Hibernate features, such as handling DSRequests with AdvancedCriteria, sorting, and paging, will remain fully supported.
Spring: Our focus is on supporting declarative calls to Spring-registered beans, which SmartClient simplifies and optimizes. Other Spring APIs, like Controllers, are being phased out because they add complexity without adding value when SmartClient’s built-in tools are used for REST and service layers.
If you rely on features that are being retired, our Feature Sponsorship program and migration support services can help you retain critical functionality or explore alternative approaches tailored to your project’s needs.
14.1 (Jakarta) builds are available now, but are still marked as “development” builds. These builds are production ready for anyone who is not using Hibernate or JPA, and the “development” designation will be removed in the near future
14.0NJ (JavaX APIs) builds are available by special arrangement
SmartClient’s commitment to developers
The transition to Jakarta APIs represents a disruptive but unavoidable chapter in the evolution of Java. At SmartClient, our priority is to ensure that our customers have the tools and support they need to navigate this change successfully.
For more information about how these changes affect your SmartClient integration or to arrange a special support plan for the 14.0NJ version, don’t hesitate to contact us.
ve been busy adding a whole new set of amazing features that will be available in the next release of SmartClient and SmartGWT.
