lapusta

Huh! I see stlc option is added now mentioning "eligible customers", which is great news. I'm curious if we would also get GitHub action?

I don't think the generators themselves were open-sourced (only the generated SDKs were already open-source). That leaves three main (recommended) options:

* Manual Maintenance: Returning to the pre-Stainless era.

* Agentic Coding: Works to an extent, but you lose the deterministic, review-free output required to keep an SDK perfectly structured and coherent.

* Open-source Generators: Helpful for basic use cases, but they lack Stainless's full-stack features like multi-language generation and publishing, MCPs, and documentation.

Red Hat effectively killed their JBoss/Middleware team and the rest of it moved to IBM https://www.redhat.com/en/blog/evolving-our-middleware-strat... Quarkus and other tools were pushed to CommonHaus/Apache. I believe Vert.X was also mostly developer by RH team, although moved to Eclispe Foundation a decade ago.

Oracle also ended up somehow sponsoring 2 frameworks: Helidon & Micronaut.

I'd bet Spring is still the safest choice next to Jakarta EE standards that all are built on top of nowadays.

I could really recommend Encore https://encore.dev/ that works best when you use their PaaS offering https://encore.cloud/ (think of NextJS & Vercel combo).

One can argue it goes against some of the Go principles, but it's a really nice stack for solos or small teams without dedicated SREs. And as you grow you can BYOC & deploy it yourself or completely rewrite your API layer using Go stdlib.

You would still need NextJS or Remix/RR7 for the front-end, but one nice thing is that it would auto-generate the client SDK in TypeScript which makes integration a breeze. And while I personally prefer Remix/RR7 for frontend, Encore has integration with Vercel PR feature which is really hard to beat.

We've recently evaluated all four platforms—Stainless, Fern, Speakeasy, and Liblab—and here are our key takeaways:

Stainless: The standout for maturity and idiomatic code generation. While method signatures across products may look the same, Stainless shines during developing & debugging - making their codebase easier to navigate. They have a practical separation of SDK configuration from OpenAPI specification, setting it apart from others reliant on OpenAPI overlays. The Stainless Studio also proved invaluable for refining our OpenAPI specs during our exploration phase.

Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs and documentation to Postman collections. Fern uses an internal "Fern Definition" language (~ think Smithy), it's optional and enables capabilities like merging multiple specs, but is adding another layer to navigate in our view.

Speakeasy: Moves at a fast pace, which could be a double-edged sword. Rapid iterations may lead to frequent, potentially disruptive updates for customers. A minor gripe was the inclusion of "Speakeasy" in class names, which felt overly branded.

Liblab: Initially limited in language support, they've expanded but still lag behind in establishing a strong customer base, which might be a red flag for some adopters.

BTW all folks are very approachable and collaborative!

Many systems have concepts of booking date & value date https://support.mambu.com/docs/booking-date-vs-value-date

You may also have suspense accounts for certain types of use cases: https://gocardless.com/en-us/guides/posts/what-is-a-suspense...

For business:

- Google Meet (~Zoom)

- Google Chat (~Slack)

- Google Currents (~Yammer)

For consumers:

- Google Duo (~Facetime, but cross-platform)

- Google Messages (~iMessage, but non proprietary: SMS, MMS > RCS)

Everything else is on the retirement schedule.

You are right, although Plaid has quite a critical view on OFX https://plaid.com/documents/Plaid-Financial-Data-Access-Meth...

Why 'would be' just out of interest?

The scenario is typically the following. After the EU Commission approves the directive, each country has to transform it into the national law and define the authority/approach/timelines. In the case of the UK, it's indeed the way you've described.

As AFAICT this would be explicitly disallowed unless all the users of said APIs are themselves accredited.

In UK Plaid would have to follow the OpenBanking regulation indeed and provide access according to the consent of the account owner. In the US they are just storing your password and using it according to their privacy policy.

Open Banking is a big buzzword at the moment. It is good to distinguish different aspects of it:

1) Regulation. What you heard as "PSD2" - is essentially a directive by European Commission and EBA demanding banks to open up access to accounts data and payment initiation. Neither it defines by what means this access should be provided, nor when it should be available - each European country Central Bank can decide on its own.

2) Technical Specification. Examples are OpenBanking UK specification or The Berlin Group - would be groups of banks or local regulators trying to define common standards. Think of interface definition that describes both APIs as well as journeys/workflows.

3) Compliance. In the EU some of the banks (mostly large ones) are now required to be PSD2 compliant, which means they would need to expose their APIs through the standards described above. In the US, where there is no such requirement - the only way to access the bank account is to emulate a browser.

4) Third-Party Providers or Aggregators (Plaid, Teller, Tink, SaltEdge, Bud...) - would essentially provide access to the accounts of multiple banks via APIs. If you look at Plaid in the US - their codebase is probably 50%+ screenscraping/user emulation scripts in order to retrieve your accounts from e.g. Bank of America. For the EU fin-techs its a bit better, but still depends per country (remember Berlin Group vs UK OpenBanking?).

Thanks @cromwellian!

We are currently looking on what to do with our quite massive GWT app. Already in the process of RPC to REST switch, with Angular, AngularDart and GWT3 (depending what it would end up to be) as options.

Just wanted to check if we are missing an alternative

Hi,

I work at Mambu and our clients are predominantly Startups - https://www.mambu.com/clients Feel free to drop me an email at alexey.lapusta@mambu.com

Although we do not provide payment services to businesses, rather a SaaS platform for Financial Institutions (e.g. WireCard may use Mambu as their Core Banking when providing banking services to their customers).

Does that mean internally Google would be using Closure Library for UI with J2CL? And other GWT applications were migrated to Angular or Dart?

Been doing sales/solutions engineering for the last 5-6 years. You can find how some companies describe the role:

https://careers.google.com/stories/google-sales-engineering-...

https://www.facebook.com/careers/life/solutions-engineering-...

https://builttoadapt.io/a-day-in-the-life-of-a-pivotal-platf...

Pros:

+ A lot of customer interaction. Could help you boost communication, presentation and sales skills if you want to start consulting

+ Quite a dynamic role, your agenda is not planned for next weeks but gets filled pretty fast with RFPs, Workshops, Demos, Proof of Concepts, etc.

+ As you are working in between of Sales, Product and Support/Delivery teams - that gives you a good perspective to provide valuable feedback across the company

+ Travel (can get boring after couple years though, and check with your partner if he/she is ok with that)

Cons:

- Some organizations are doing (Enterprise) Sales in old school way, in that case, Sales may just dump on your work they don't want to do like filling RFPs (Excel file with 100+ line of questions) or doing standard demos

- Your technical skills may stagnate as you would be less hands-on, but that depends on the type of the product (e.g. SaaS vs SDKs, Platforms)

- In terms of career development, you actually would have to choose if you want to go back to tech focusing on Solutions Architecture, or to Sales/Management roles

Before agreeing to the role - discuss the actual responsibilities (and ask those to be put on the job description), as well as the percentage of travel.

Can you tell what is current status of extension - is it still supported or packaged app is the way to go nowadays?

Are you planning to go more native with something like Atom's Electron platform?

BACKBASE (visionary UX & Bankning platfrom)

Location: Amsterdam(we do sponsor work VISA), London, NY/Atlanta - FULLTIME

* Want to work in an international company travelling over the globe & work with clients?

* Or you prefer creating a solid platform for millions customers in our R&D dept in Amsterdam?

* You are a skilled frontend(Javascript, AngularJS, ReactJS), backend(Java, Spring, REST, Camel) or mobile(iOS, Android) engineer?

* We do have UX/BA/QA/Manager/Cloud positions too!

Check out our jobs at http://www.backbase.com/about/careers#jobs or drop a mail to alexey@backbase.com

IntelliJ platform runs on top of JVM, Nitra runs on top of CLR.

It's written in Nemerle, that runs on top of CLR. I believe it's targeted to .NET, VisualStudio & Resharper audience.

Backbone is an opinionated software, so it's hard to say if binding would be ever included.

For developers I suggest to try some of plugins, which are listed on GitHub wiki in the binding section and also take a look at Knockout/Ember/Angular so at least you would know what other frameworks offer.

Backbone is a great framework and moved the industry forward a lot in terms of code quality. But there are definitely couple things broken, like Zombie/Ghost views - everyone(!) is making their own workaround.

View part is too much DIY. Seriously, _.template is okay for views with no input and simple updates, but if you have heavy IO views become bloated. Check the wiki, there are 7 "yet another binding plugins". Make default one, and make it an option (view binding can be slow and not needed sometimes).

Another DIY are models relations & nesting. These two additions wouldn't be big for the core, but they could really improve the ecosystem. Now you have to take in mind those third-party plugins people are using for these covering basic gaps.

Best one is in JetBrains products - http://www.jetbrains.com/editors/javascript_editor.jsp

Eclipse & VS suck with JS. There is also Dart Editor which Google is building for their new language. I think they are aiming to what you currently can do in Eclipse with GWT's Java code.

Their new platform (BB 10) is incompatible with old apps. And Bada was merged into Tizen, so it's future looks uncertain for me.

It pretty much depends on industry. Look at mobile, 2007: J2ME, Symbian, Windows Mobile, BlackBerry -> 2012: iOS, Android, Windows Phone. Now look at the web: it was more of a evolution than revolution.

What happened at back-end, like server-side functionality of business apps? They didn't really change and probably won't change for a longer period of time. Even stuff like Hadoop for big data or Groovy for DSLs were built upon the existing JVM.

It's hard to say what devices we'll have in 5 years, or what internet would look like, but i'm pretty sure servers would run good old Java.

Will we see SuperDevMode in GWT 2.5?

Why was GWT team reduced? Developers were moved to Dart project?

Is there any schedule for 2.5? We are waiting for SourceMaps, since debug mode is working slow in Chrome & IE, and with Firefox there always is a version gap. Safari plugin is also broken since version 5.

Main Twitter UI is JS talking to api.twitter.com written in Scala.

They use Rails for pre-rendering the first page and some non-js pages like user settings & company info for what I can tell looking at their server responses.

They were switching from hashbang routing to pushstate, not from client to serverside rendering. Although they might to pre-rendering for IE, which will get support of pushstate only in version 10.

http://storify.com/timhaines/hashbang-conversation

Google? http://support.google.com/a/bin/answer.py?hl=en&answer=3...

SE planned to stop producing non-Android phones in 2012

Switch to the new UI, open source code and search for __gwt_historyFrame, com_google_blogger_b2_gwt_dashboard_DashboardGwt etc.

Actually markup/generated script is pretty common for ones who worked with GWT, so it's very easy to distinguish such sites.