In case anyone wonders if this is actively beig used, Lion currently powers the internal ING web component library that applies our own design system on top. It is the foundation of the "next generation" web platform for all our web programs internationally. In some countries, it also powers our mobile offering through webviews/Cordova.
Many hundreds of web developers at ING use it for their projects, and all active web development is using powered by it. Lion is a core component of our web strategy. At this time, over 10 million customers are using products built with it, on a daily basis.
Hi Ruphin. I guess you are a developer at ING -- may I ask you something Off-topic?
I have a simple giro account at ING and just would like to query the balance regularly with a script. Nothing fancy at all. Is there some API you offer? I've seen your website https://developer.ing.com/ but it seems that developer access is only intended for developing activities and not intended for "productive" usage, even if it is with the giro bank account of the developer.
As far as I know it is currently difficult to get API access as an individual. The APIs are available to third party developers as is required by European regulation, but they have to go through a procedure to receive access to production data.
We have several teams working on improving our open APIs, including availability. If you reach out to me by email I will ask one of the teams and let you know when we expect to be able to offer what you're looking for. You can find my email in my profile.
Hello ktpsns! Many thanks for your feedback on https://developer.ing.com/. For the moment, the "Account Information API" is indeed only available to companies with a PSD2 license.
But, there are discussions to open the API to individuals so they can programmatically consult their accounts only.
This is the first truly white-label web component set that I know of. It's intentionally not a design system, and looks pretty ugly out-of-the-box until you customize it with your own styles.
I think it's a really interesting approach, and has the possibility to be a Bootstrap-like foundational layer.
I work on lit-html and LitElement, which Lion uses, and we're working on new userland theming systems (and standards too) that will make using and theming a set like this easier.
It's an impressive sign of the times that a traditional bank publishes free & open source software. Banks are extremely risk averse by nature, and publishing open source is risky in all kinds of ways.
What if a developer copies&pastes some GPL code? What is some open source dev work gets done on a big project billed to a client? What if an external contributor contributes some code that gets merged, but it turns out to contain an obfuscated backdoor and this ends up inside our online banking apps? What if a company uses our open source code and it's broken and they sue us? (they'll have no leg to stand on, but it's still a worry for management not used to open source).
Really there are all kinds of complicated stories (sensible and not) about ownership and responsibility that need answering before an organisation like this will give off the green light to publish open source. I bet this was not a few developers asking the boss and the boss going "oh yeah sure, go ahead". Hats off.
When working at one of the other big banks in the Netherlands I had a security officer ask me: “So are we using any open source software?”
I had the pleasure of seeing his face go white after I told him pretty much every bit we had from OS to framework, compilers, languages and everything in between was open source software...
It wasn’t a surprise that we couldn’t open source some of our stuff “because security”
ING has always been a pretty open/modern/progressive business on a number of fronts. I wouldn't take this as typical. (In other words - they aren't Chase and vice-versa, not anything against Chase in this claim)
It certainly wasn't modern enough to institutionally facilitate releasing open source software though, si it's great that they made progress on that front.
I went through the hoops of open sourcing some code in a global 50 company. The development team push for it restlessly for a year. The reality is that the culture in not there yet and I had to go through security, compliance and legal. We had to rewrite some code as one of our apache 2.0 dependency had some GPL dependencies.
We finally get the go when we cornered an exec during an off site event and he finally agreed to let us do it.
Big company are unfortunatly not ready by default to contribute back, it s not in the culture, and you get pushback from internal IT team thinking the code / architecture / documentation is not good enough yet to open source (hint : it never is) once you have clear the compliance / legal / branding / security side of things.
Hats down for the tech lead / dev / manager that convinced ING to open source this one. I hope that getting in front of HN will allow the dev team to get a little more budget to maintain this project a little longer.
hey, one of the devs that pushed for it here. Fully correct - getting everyone on board and then to actually approve it took a long time and a huge amount of effort. Even then although the code was open source we had been in a pilot phase where we have not been allowed to promote it.
But now it's share it is much as you can
And yes we hope to get a big community externally and internally which will improve the components overall
Given the amount of work and legal risks involved do you really blame them for being reluctant though? How many man-hours were spent on sorting out all the legal issues, doing the rewrites you mention etc?
Mostly worth it for the team. Its good to be working on opensource project full time.
Also as an internaly, explaining this project have N star buy you political capital and facilitate access to extra funding to pursue the project longer.
The problem with Web Component libraries I've seen (including this) is that the moment you use any external libraries, you lose the entire point of Web Components. That is, to have fully native reusable bits of code that can be built upon and used interchangeably with any other tech stack just like an <a> tag or an <input>. As soon as you start using libraries with a build process you might as well just use React or Vue or whatever else.
The benefit of web components is interoperability. It doesn't matter what build tools you might or might not use to make web components, you consumer them the same way:
1. Load the definition
2. Create an element with any DOM API or HTML.
Nothing about web components says you shouldn't use dependencies or build steps.
>Can you elaborate a bit on what you mean plz? What's the link between "interchangeably" and having a build process?
My point is that as soon as you introduce a build process, imported dependencies, etc. then you might as well just use React components. The power of web components is that you can just drop them on a page and use them with zero dependencies or proprietary APIs to learn.
But a build process ensures you can use imported dependencies internally AND use them with zero dependencies on your page (other than the JS component definition itself). Even if you don't have a build process and just use ES6 modules, the Web Component manages its own dependencies such that you don't have to worry about it (the only friction there being if folks use bare import modules). Whereas with React components, you'll always be dependent on a React runtime.
There are various techniques you can apply in these cases. Like deduplicating dependencies or apply a build/babel plugin that makes sure the names are unique.
Imho scoping elements at the template/element level sounds more promising. Here is an experiment archiving exactly this https://open-wc.org/scoped-elements/
There are still some improvements to be made but it's actively been worked on - so something lion might consider in the future.
That's great, that would've saved us so much trouble back when I worked with Web Components with many different teams. The problem it describes are exactly what we ran into, and solution 2 was extremely painful in terms of overhead and being demotivating:
> Synchronizing updates of shared dependencies - e.g. make sure Team Blue & Team Green always use the same version when releasing. This can be a viable solution however it comes with a high organizational overhead and is hard to scale up (for 10+ teams)
I'm not sure whether it's still the case with lit-html, but back when Polymer was a thing, you'd better make sure all Web Components on your page were compatible with the same version, and also didn't build on top of incompatible versions of the same shared component. This really made it a pain in the behind to integrate many different components built by many different teams into the same application, especially if there also was a library of shared components used by all teams.
Anyone from ING present who can share whether this is still the case?
I think you mean you can't have same element redeclared? Then yes this is still the case, and at least for now it will be - for any library that can output custom elements. Every component is a real interactable HTML element, imagine <div> or <p> would work differently. I believe there is some work for multiple component registries but I'm not tracking the progress on that. This is HTML thing - it is not a library specific problem. It might get solved eventually https://github.com/w3c/webcomponents/issues/716.
I come from python world where you have same restriction for all packages so it never occured to me as a serious problem :) We just pin ranges in libraries. And application itself pins specific versions in place.
Yes. I come from React, and if two components I depend on each depend on different versions of the same component, I can load them both no problem. When I worked with Web Components, that required that I contacted the authors of both components to get them to upgrade to the new version of the same time - which of course became exponentially more effort as we used more components.
They also get to demonstrate their way of doing things in public, which in a field as active and mercurial as frontend web development has value in influencing where changes go. If they have a particular solution to a problem that's not well-solved elsewhere, they can influence the world to follow their approach to solving it (or at least not pull the rug out from under them) instead of going a totally different way and turning their code into technical debt.
I've been looking for something framework-agnostic like this to make a fresh implementation of pie menus.
Here's the documentation and source code of my old jQuery pie menus, which are getting pretty long in the tooth, and which I need to reimplement as Web Components in TypeScript.
The challenge is how to design widgets that developers and designers can easily skin, and totally customize the presentation and feedback by mixing and layering different technologies (like css, html, canvas, and WebGL, for example), independent of the tracking behavior.
And how to design a complete set of callbacks and tracking notifiers and hooks that enable developers to provide rich feedback that's deeply integrated with their application (like drawing the feedback based on application state, or previewing the effects of the pie menu gesture in the app, while the menu is still tracking).
You can do some kinds of simple styling with CSS, and more kinds of deeper designs with html templates, and all kinds cool customization with JavaScript code and dynamic HTML.
And you can define and configure trees of menus/slices/items with JSON, XML, or HTML structures, including graphical and layout properties, and event handlers.
Or you might want to procedurally draw some or all of the widget with a canvas (while using html text for the labels, which is much easier to deal with and more accessible than drawing text in a canvas).
Or you might want to draw the menu items or background or even the labels in 3D with WebGL.
How can one web component handle all these different ways of mixing and matching rendering and feedback?
For example, these Unity3D pie menus can display text and image feedback in the 2D overlay, mixed with 3D objects (drawn in an overlay camera, not actually drawn directly in the world, or objects in the world would occlude them).
>Unity3D Pie Menu Demo: I've made a general purpose pie menu component in C# for Unity3D, which supports text items, image items, and 3d object items too!
Another hard question is how do you define and configure these widgets? There's a whole spectrum of different people with different use cases, from downloading dynamic JSON menu trees from a web server, to writing annotated html trees that degrade gracefully to usable menus with JavaScript disabled, to building and styling menus in an interface builder at design time, to procedurally generating them with an api at runtime, to integrating with an existing tool's editors like Unity3D at authoring time, or even to enabling game players to build and customize their own menus at playtime.
The Unity3D editor makes it possible to construct trees of menus/slices/items out of 3d objects in the world, and edit their properties with custom editor control panels, and configure callback handlers that can modify the menus and 3D objects during tracking to provide feedback. (Like making the 3d menu items spin and scale and fly around, or mapping your face from the camera onto a mesh in the center of the menu, and tilting the mesh in the direction of the selected slice, to simulate the pie menus in The Sims.)
The Coral Menu and Trace Menu from Simon Schneegans’ Bachelor Thesis are perfect examples of the kind of fluid dynamic layout and feedback that I'd like to implement with HTML components and the canvas 2d api:
>The first prototype is targeted at users who often search for items due to their manifold menu usage. It displays hierarchies with ease. Even very deep hierarchies are easy to explore. Many items are displayed by increasing the pie’s radius and stacking the labels which are displayed next to their sector on top of each other. The following clip demonstrates the behavior. As you can see, the items of sub-menus are indicated by little dark blobs at their parents. This menu is quite fast to use because of the mouse making a smooth movement.
>The second prototype addresses itself to users who often make use of the same menus. Thus they know where to find an entry and want to select it blazingly fast. In contrast to the Coral-Menu each sub-menu is a complete 360-degree-Pie-Menu with one entry being the parent menu. The hierarchy is visualized by a path between the visited menus. This menu features a so-called “Marking-Mode”: The user may draw the path (the “trace”) to the desired entry with one continuous gesture. Watch the following clip and you will understand this behavior — the Marking-Mode is used for the very last selection.
That makes no sense, they are compatible with react, you just need to write more code to use them. https://custom-elements-everywhere.com/ I find it interesting that you blame WC not react devs for the fact they don't want to improve your experience.
Ah sorry, I meant to say "Web Components can just be dropped into any framework" isn't true. Note that you can also use React components in Angular or whatever if you just write more code to use them, but that just doesn't provide enough value to me to overcome the downside.
Also note that I'm not "blaming" anyone; just explaining why it's not worth it for me at this point in time to adopt Web Components in my React applications. I very much like the idea of Web Components no longer making us reliant on the web standards process to finally add things like date pickers or typeahead components, but I just don't think it's there yet.
It's still pretty early, and this won't be anything close to the last one. But with an emphasis on small size and white-label features, it's pretty close to the holy grail.
All N component sets usable in any app, w/o respect to some would-be-platform. Nice problem to have.
React and friends are looking more and more like oversized polyfills, every day.
Many hundreds of web developers at ING use it for their projects, and all active web development is using powered by it. Lion is a core component of our web strategy. At this time, over 10 million customers are using products built with it, on a daily basis.