cappuccino/cappuccino

Web Application Framework in JavaScript and Objective-J

David Richardson

@enquora

@udoschneider SproutCore was, of course, forked internally by Apple for the web versions of their iCloud apps. Some of which are non-trivial

daboe01

@daboe01

@udoschneider html/css is not a bad thing per se. to be honest, it is the future because it is device independent, animated and highly performant. @didierkorthoudt is working on aristo3, a modern look for cappuccino, based on css instead of pixel artwork.

David Richardson

@enquora

@udoschneider @daboe01 The difference is not, imo, in the drawing model, but the code organization one, and the available UI controls. The others, excepting perhaps ExtJS, are focused on augmenting raw html/css, rather than providing a truly robust event management mechanism and controls to go with it. They all hit the wall eventually - at least for small teams.

Apple, of course, has unlimited resources to tweak and extend SproutCore. Most do not.

Having said that, I would prefer we use SVG/css as our drawing model rather than html/css. That's not in the cards anytime soon though.

David Richardson

@enquora

As an example, our own app is now in the neighbourhood of 125,000 L.O.C. The one it is replacing was begun in 2003 using hand-rolled html/css. It reached 25,000 L.O.C., then became a chore to extend maintain and extend.

Udo Schneider

@udoschneider

@daboe01 @enquora From my point of view "desktop caliber applications" is not a drawback. The usecase I had more times than I like to admit were apps which were 99%+ used on desktops and whose models and views were very complex. This complexity could be handled with a desktop-style ui (e.g. Drag&Drop from complex widgets like views in table cells or Copy&Paste of real objects - not just text). Doing the same with a mobile/touch paradigm is either impossible or very complex in terms of interaction. I'm not "against" HTML/CSS - although I'm not sure if this is the future. IMHO the abstraction level of HTML/CSS - even with current JS frameworks - is still way too low for handling complex user interactions. And adding those abstractions is something I don't want to do on my own as a throw-away "side" project. That's were I see Cappuccino shining ...

daboe01

@daboe01

@udoschneider i fully agree.

Martin Carlberg

@mrcarlberg

@daboe01 There is a team on that link but it looks like Github has changed the behaviour for this page so it might not be visible for all. I will check.

@udoschneider Yes, this is what Cappuccino is really good at. Nice summary :smile:

daboe01

@daboe01

@udoschneider Yes, this is what Cappuccino is really good at. Nice summary :smile:

can we have a nice short wording for this to put on our website?

Martin Carlberg

@mrcarlberg

The website is available at https://github.com/cappuccino/cappuccino.org. Anyone can do a pull request.

David Richardson

@enquora

@daboe01 @udoschneider The phrase 'desktop calibre applications' has become a negative for myself. With the rise of Electron apps it makes me think first of something with a clumsy and incomplete user interface. As more of macOS's minor apps are converted to Catalyst or SwiftUI this is increasingly true of those too.

Cocoa excels in providing tools to create efficient user interfaces which don't get in the way of the task at hand, in my experience — and this should be our value proposition.

Abstracting away html and css will turn away a significant number of people who know nothing else, but that's no reason to change our focus. It is an (essential) implementation detail, but nothing more.

David Richardson

@enquora

Having said that, we have edge cases almost everywhere which break that promise to some degree. My hope for Aristo3 lies not in new visuals but that the rewrite process will fix most of these edge cases. My fear is that it's too much for a single person, isn't amenable to others pitching in to help finish, and will stall. The same is true for autolayout, which is also badly needed.

Udo Schneider

@udoschneider

@enquora With the rise of Electron apps it makes me think first of something with a clumsy and incomplete user interface.

Funny that you mention Electron. From my point of view many Electron "Apps" rebuilt a lot of a more complex desktop-like UI behaviour on top of HTML/CSS ... and it still feels/look foreign. You could give it a Marketing "looks modern" spin though. However I'm not quite sure if using platform agnostic HTML/CSS to emulate a native UI running in Electron to provide a "native" app is actually worth the effort compared to using a native toolkit directly (e.g. Qt if you really want to be platform agnostic). This kind of reminds me of my Smalltalk times where (at least the commercial) Smalltalk dialects were drawing their complete UI on their own. Sometimes even with different themes for Win9x, Motif, CDE and so on. But back then at least the level of UI complexity was comparable/above what was given on the underlaying OSs. With Electrom you get the worst of all worlds IMHO .... maybe except for the "built with modern web technology" buzzword bingo and the (on first sight) better availibility of developers ...

David Richardson

@enquora

It’s quite possible to build an Electron app with good performance and even an effective UI, but approaching the task from an html/css/javascript perspective is a prescription for disaster. VS Code is an effective editor (although having a hideous UI, imo). Numbers, KeyNote and Pages for the browser are also excellent apps which could be delivered wrapped in Electron. The counterpoint is Slack (and Gitter), which is a masterclass in bad UI design.

The key, imo, is people coming at the task from a raw html/css/javascript perspective either don’t have the experience to properly implement clipboard, control tabbing order, keyboard shortcut, drag-and-drop support, or are restricted by resources and directives from doing so. Cappuccino makes these things orders-of-magnitude easier to implement.

David Richardson

@enquora

From the broadest perspective, fashion and industry imperatives are against this. We had this discussion a year ago, initiated by @didierkorthoudt and confirmed by @Dogild, that the lowest common denominator is favoured in most programming situations. This shouldn’t dissuade us from focusing on what our strengths are (apps with complex user interaction requirements). A small piece of a cake can be very large when the whole itself is extremely large.

Monterey hasn’t fixed the macOS UI problems first seen in Big Sur (the notification center and second tier Catalyst apps particularly Reminders and Feedback Assistant. It’s safe to assume this is part of a larger trend.

Udo Schneider

@udoschneider

@enquora I full agree that you can built an efficient and effective in Electron - and the VSCode example is a good one. I just think that most devs simply underestimate the effort and experience needed to uplift plain HTML/CSS into an application framework. And I for myself decided that I neither have the time nor will to built a half-baked framework. Hence Cappuccino. I'm still wondering though that Cappuccino & ExtJS seem to be the only projects aiming for this. I'm asking myself why the UI/App Framework in Atom/VSCode is not really a project for "native" UIs on its own.

David Richardson

@enquora

@udoschneider Almost all organizations view software as a cost rather than an asset. The natural outcome is to hire fungible lowest-common denominator people to create/maintain software. Not a prescription for good outcomes. When Apple itself continues to promote design awards for what it considers to be outstanding UI examples, yet allows its own design teams to commit what amounts professional to malpractice (macOS Notifications and every Catalyst app and most SwiftUI ones they've created), it's a trend not likely to change.

We should concentrate on identifying and reaching those who view software as an asset.

Udo Schneider

@udoschneider

@enquora Very good point ... it also explains (to me) why I personally don't like it. The stuff I'm doing is mostly done in very small teams (more often than not it's just me) but on the other hand used with a very high frequency for a long time. So I'm not interested in a "fancy" UI ... but in something that a) works and b) looks familiar to even a new user. Given the high frequency of usage every user stopping to think about how the UI actually works ... event for just a second ... sums up at the end of the day. So I'm more for a functional UI w/o any fancy surprises. Might not be worth an Apple Design award though.

Also UI/UX design is very hard IMHO. Relying on established patterns might not be considered "good" or "leading edge" design. But at least it leads to something usable. Designing a completly new way to interact/present a UI is very hard and not easily done. Apple did this for Mobile with UIKit ... whether the avarage dev is able to pull this off while doing is main project is something I doubt.

David Richardson

@enquora

@Dogild was a member of a small team which created the most complex Cappuccino app to date, imo. He dropped in a year or so ago to discuss the reason the project switched to a far less capable foundation at increased development cost and reduced functionality - they couldn't hire junior devs interested/experienced enough in non html/javascript/css approaches to ensure long-term viability (if I understood him correctly). @didierkorthoudt echoed this.

UI/UX design is very difficult, and fundamental to software usability. It's a mistake to treat it as an afterthought. Our biggest asset is a three-decades tested UI implementation.

This is what our landing page should reflect and emphasize, imo.

With the Oracle v. Google problem out of the way, perhaps we can be less shy about this.

For context around my perspectives, my first software was written in Fortran on punch cards. It was engineering software with a high penalty for failure. I've seen most fashions come and go. The current one for html/css/javascript is driven by very real needs for improvements in distribution, but it's just that - a fashion. I suspect wasm approaches such as Blazor are what is next. No reason Cappuccino can't follow, when appropriate. Without direct access to the DOM from wasm it's a bit early, though.

Udo Schneider

@udoschneider

Was this the stuff created at Nuage Networks?

David Richardson

@enquora

We probably need a simple demo app which comprehensively demonstrates things like control tab order, undo support, clipboard management, drag-and-drop, TextKit.

Yes, it's Nuage Networks I'm thinking of

Their core team was just three or four developers

Udo Schneider

@udoschneider

I like the idea of the demo app. Just trying to think of all the things that are built-in/easy in Cappuccino but very hard in non-desktop frameworks now :-)

daboe01

@daboe01

we have this on our website: https://cappuccino-testbook.5apps.com

David Richardson

@enquora

We have several demo apps, but the effect is much diminished by spreading the examples over several apps

Udo Schneider

@udoschneider

However I have to admit that a demo app should do sth. usefull. If not it tends to a) feel fake b) fall into non-maintenance pretty quickly.

Love the testbook by the way! Same for the cookbook!

David Richardson

@enquora

@daboe01 While it exhibits almost all our capabilities, it's not an exemplar of good UI/UX design, imo

daboe01

@daboe01

something like a gitter client :-)

David Richardson

@enquora

The use of iframes to load individual apps leaves me cold and detracts enourmously from the overall effect, imo

The Gitter app is right at the top, along with Slack, of bad UI/UX examples, imo ;-)

No point in fixing it now that Gitter is moving to Matrix though

The testbook app could be finished and made a good example by merging the navigation portion of the app with the loaded sub app, rather than taking the shortcuts it does now

Udo Schneider

@udoschneider

I was just thinking of a frontend to a Infrasstructure as a code backend (e.g. Terraform) or a CI/CD pipeline. But at least the first thing would pretty much be in Nuage territory in terms of complexity ... and not just for the frontend.

Is there maybe something with an existing backend and an API (REST, GraphQL ...) that's waiting for a UI? :-)

daboe01

@daboe01

i think this one may be a starting point: https://github.com/saikat/DrawTogether

David Richardson

@enquora

Perhaps it's enough of a start to update the website slightly to reflect all this. With individual apps highlighting specific features which are difficult for others to replicate.

This should be, imo, just a part of a dedicated plan/schedule for the next release - which, by default, is already focused on Aristo3. If it is necessary to divide the task to help @didierkorthoudt that should be considered. Another thing in need of attention is a workflow which updates our PR testing pipeline, making it easier for @mrcarlberg to have confidence in merging specific patches. He mentioned chokepoint last year, and the problem isn't going away or resolving itself. Perhaps two branches, with one accepting merges much more quickly, thus making it easier for testing on our own apps - as a precursor to merging into the main branch?

David Richardson

@enquora

It doesn't help having a backlog of PRs when newcomers are looking at the repo to make decisions. I suspect many in the pending PR list are interdependent Aristo3 merges, but that relates to my other comments.

From the perspective of newcomers considering Cappuccino, incremental but regular changes are an important indicator of a project's health

daboe01

@daboe01

i second that. we have a lot of old PRs that should be either merged or closed for good.

Where communities thrive

People

Repo info

Activity