JetBrains Ring UI
jetbrains.github.io
jetbrains.github.io
From https://github.com/JetBrains/ring-ui:
> This collection of UI components aims to provide all the necessary building blocks for web-based products built inside JetBrains, as well as third-party plugins developed for JetBrains' products.
From https://blog.jetbrains.com/blog/2018/09/25/ring-ui-1-0-is-re...:
> At JetBrains, we use Ring UI components for our web-based products like YouTrack, Hub, TeamCity, and Upsource.
https://jetbrains.github.io/ring-ui/master/index.html?path=/...
I also quite like Quasar's date picker https://quasar.dev/vue-components/date
Though do not even look at their time picker... It's a mess, I roll a custom component for time when I need it.
It's good to finally see some innovation in the datepicker space.
iOS has a strange combination of arrows to handle the month: right to expand the months dialog, down to close it. It took me a while to understand that the down arrow would bring me back to the calendar. Why not right and left? Maybe it is how it works on a Mac too.
MD and anything else I remember has a down arrow to expand and an up arrow to close.
(I work on grafana frontend)
[0]: https://github.com/grafana/grafana/blob/4b2a9406596ba63a6945...
(What’s up with floating top bars? Either just make them be a real part of the page, or move them to the bottom, or, if absolutely necessary, keep them floating and test the heck out of them. Because that floating element that can’t be dismissed will result in a near 100% reduction in your conversion rate all by itself.)
Impressive.
Otherwise, the design is really nice. Date pickers are generally pretty "meh".
I refreshed the browser and came back, now I can select the date.
It's like the classic "text field versus dropdown for state abbreviation." There are a lot of dates people prompt for that the user KNOWS and can type faster than they select. The obvious one being "enter birthdate" as part of account creation processes.
The "comprehensive" date pickers with mini calendars and things are more usable, IMO, when you're interested in a relative date. What you really want is "next Tuesday" and you need the mini-calendar to convert that to "2022-10-11". Maybe they can be bypassed by figuring out purpose-built specific solutions to the prompt. Appointment scheduling, for example, might be better suited by showing a list of available slots rather than prompting for an arbitrary date.
???
https://files.catbox.moe/4yykhw.webp
My grandmother can program better than that.
You could build a very complex UI with Ext.JS back in 2010 with a lot less code and very little time, while it takes a while lot more work to produce even something relatively basic with modern UI frameworks.
I really don't care about how customizable your spinner is. I want to use it in common contexts with as little code as possible. Heck, at least provide me with a kitchen sink so I can copy and paste common patterns.
Designers care about uniqueness.
Tailwind and Tailwind components achieves this for example. Web components also come to mind.
What's stopping you from doing that now?
If all the UI libraries just gave you highly abstracted prebuilt components with little to no customisability, then you wouldn't use them. Because as soon as you want to do something different, you'd have to write your own or find someone else's.
If you just want some boilerplate UI in a hurry, this is fine (it’s actually better) but it sets an upper bound for how good the UI can ever be and that’s a problem for serious professionals.
Of course most UI is horrible but that’s true no matter what framework you give them. There’s always somebody using checkboxes as radio buttons.
The HTML is an excellent exemple at that.
You are never "limited" by highly abstracted librairies since at any moment, you can write your fully customized one.
And no, a customized components is not immediately better.
Good Library UI components have, i18n, accessibility, and good mobile UX.
The comment "I can do a decent calendar in react in a few minutes" shows exactly this: it's infuriating to use on mobile.
... right ?
https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
> Customized built-in elements inherit from basic HTML elements.
My intuition about solving this is to create components where instead of a select and a radio button being separate components, they're the same component with basically the same API.
And instead of deciding on a spacing between components, you just get spacing more or less automatically so everything looks good by default.
They have AppCode and Android Studio targeting mobile as well.
It’s when you rely on a webpack config you can’t see that it’s hard to keep storybook’s config and your app’s config in sync.
- Adobe spectrum: https://spectrum.adobe.com/
- Radix UI: https://www.radix-ui.com/
- Tailwind UI: https://tailwindui.com/
- Reach UI: https://reach.tech/
It's basically the natural outcome of reasonable people responding in reasonable ways to seemingly-reasonable incentive structures.
(I do agree there's probably a more efficient way, but I think it might also be one of those slippery-slope situations where there's a lot of gravity pulling sufficiently-large teams to eventually have their own component library. In other words: Suppose they start off with the best of intentions and repurpose an existing library. Then come the inevitable months of customization, forking, racing to integrate upstream updates, etc. Finally, someone pipes up and says, "Hey, why don't we build our own so we can control our own destiny?" Stakeholders get excited, and then it's off to the races.)
or even
https://opensource.adobe.com/spectrum-web-components/
are simply much better as they just work with native web standards. React is just another way FB/Meta hurts people :)
Sure, and all you need are 50+ dependencies to work with those "standards": https://www.npmjs.com/package/@shoelace-style/shoelace?activ...
If you're doing JS development, just use React. There's really no good reason not to, and I would argue that in an enterprise environment it would be negligent not to.
If anyone can give a non-ideological reasoning for a better choice, I'd love to hear it.
That said I am also against choosing libraries based on political/ideological concerns. React is MIT anyways.
The vdom and batching updates is slow, the theory behind it that direct manipulation of the dom is worse has been pretty conclusively shown to be incorrect, especially with css "contains".
JSX doesn't end up bringing much value over vanilla html, but can lead to a lot of strange and difficult to reason about states.
The "execute everything on every render" style ends up being extraordinarily costly and not particularly beneficial, especially when you add something like redux to the mix.
Alternately, web components have a simple, lightweight and easy to understand life cycle.
Reactivity is trivially implemented via property setters and a call to a render() method.
Tiny, fast rendering libraries like lit-html work great, and for other components you can do without them completely, depending on the needs of the component.
React needs at least one build step, which distances the developer's code from what executes.
Vanilla web components are simple to wrap into framework components for pretty much any framework, and can be used natively by most.
React components are limited to react things, unless you want to include an absurd js payload size.
And "just use react" doesn't really mean anything. What version? With what methodology? Hooks? Class based? Look at how much it's changed. It's very costly for organizations to get caught up in the framework upgrade cycle.
There's a reason why Ionic chose to base their components on native web components. I recommend you read about it.
This is just plain wrong. Like, unbelievably wrong.
> Tiny, fast rendering libraries like lit-html work great,
It's always funny to me how people bash JSX and then praise lit-html that literally has things like ?value and .click that it parses from strings using regexps, but it's somehow "better than react because native web standards".
And lit in general is busy re-inventing react (working on context API as we speak).
I guess `.value` | `@click` is pretty much all tag template literal based libs do. The static parts need parsing, right? Though regex would be slow (if they do), a tiny parser would suffice.
Context is a way to avoid prop drilling.
> The static parts need parsing, right?
You either provide a custom DSL and embrace it or you claim to be "native standards" and bash JSX.
As far as I understand it's no longer just static parts either. Can't properly test this on mobile, but it looks like function calls like classMap or styleMap are only allowed in certain locations of the code, so it's already JSX-level (or more) manipulation.
I totally agree with your sentiment, but there are more frameworks out there with sufficient maturity to be considered enterprise-grade on the scale of react. Angular is certainly there, Vue as well at least in my book.
Vue is off the table. If you’re not prioritizing “ability to hire” with your tech choices you’re in for a bad time. Angular is popular enough that you would get a lot of candidates.
Where I work uses Vue rather than React, and we're _very_ happy with that choice. There's many reasons why (specifically the Composition API is similar to React Hooks, but in my opinion _much_ better thought out, and so is the fact that the state-management story is much more opinionated/first-party), but rather than start a framework war, I will say that every FE engineer we've hired who preciously worked at a React shop (which is all of them) has gotten the hang of Vue within a week and finds Vue a refreshing breath of fresh air. Me included.
I think React without a doubt has the largest ecosystem. And I also think Vue is more than a valid choice, and definitely not a problem in the hiring sphere.
2. Shoelace has far fewer dependencies than Ring.
Let us see,
Shoelace: https://www.npmjs.com/package/@shoelace-style/shoelace?activ...
7 user dependencies
46 dev dependencies
VS
Ring: https://www.npmjs.com/package/@jetbrains/ring-ui?activeTab=d...
60 user dependencies o____O
100 dev dependencies o__O
Also the person building Shoelace has consistently been an early adopter of best practices/standards.
I believe a single person with taste and knowledge can build better components than yet another team chasing after latest 'trends' under time pressure.
npm install @shoelace-style/shoelace => 19MB, 17 packages
npm install @jetbrains/ring-ui => 189MB, 560 packages
There's an entire open source community that revolves around "React alternatives that exist because they're not React". For better or worse, people have ideological reasonings for their choice of JS framework. I've seen it play out countless times at multiple jobs between people who just want to get their work done with the industry standard tooling, and people who have a bone to pick with FB and become fanatical about using Vue/Svelte/*whatever instead of React.
The contrarians usually win out, because the people who just want to do their job and go home don't care enough to fight that battle over and over again. The result is a patchwork of forgotten projects and frozen dependencies that no one knows how to maintain, and a security nightmare where everything is pulling in tons of random unmaintained NPM packages with 4 GitHub stars, rather than the battle tested 5 year old React equivalent with 2k stars.
To be fair, this happens with React too (all the time). It has more to do with the JS ecosystem than with the framework of choice.
That's exactly what they're not doing
I like Angular's approach the best. You have an HTML file, a SCSS file, and a TS file. The TS file is essentially your model and handles all the thinking. HTML/SCSS are kept declarative like god intended.
React itself is just function calls. JSX makes the function calls look like HTML. HTML is generated from these function calls at runtime.
Anyway, what editor are you using that doesn't support JSX? It has support for it in the major IDEs.
---
EDIT: add links of evidence
https://github.com/adobe/spectrum-web-components/discussions...
https://github.com/shoelace-style/shoelace/issues/525
I've seen many people in this space often forget to utilize `import` and `export`, that is not trying to write composable modules so that it's treeshake-able.
2. Have the "non-hurting" web components solved all the issues that literally no other "no -native-standard" frameworks have? https://twitter.com/Rich_Harris/status/1198332398561353728
3. Why is it that all the issues that arise from Web Components merely existing are "solved" by throwing more and more Javascript at the platform (anything from form participation to anything else, really)
4. Could it be that it is Google as the main driving force behind web components is the one hurting people by making the platform ever more brittle and unimplementable?
Personally, I’m of the believe that the bumbled mess that web development has become can only be fixed by peeling away layers (or perhaps starting from scratch) not adding more. I seem to be in the minority on this though…
hermione: {skip: true}
Edit:
No, it's about this:
The typography looks awful, spacing looks all over the place - elements are difficult to read. I can't see much consistency as if it was developed by disjointed teams.
Not something I would use unless there are good looking templates available.
YouTrack specifically comes to mind here. It's a fantastic bug tracker, but the UI is missing a certain... jeu ne se quoi
I wonder how much money it must have cost and is it worth it for JetBrains?
How much time would it take for a team of 5 to make a UI library at this level of sophistication (tests, accessibility, response, etc)? 6 months? 1 year?
But let's say 5 people working 12 months x 50,000 USD = 250,000 USD.
Even considering non US payrolls at 50k per year, that's a significant expense.
JetBrains devs likely cost around 100k/y year here in CEE by the way. But I think 3M is a reasonable guess, 30 FTE years (7 devs, 1 PM, 1 UX, 1 "overhead" (other management costs)).
I would imagine a good React dev in the US would make (on average) closer to 100k? SV salaries will probably be higher than 100k, no?
The competitive advantage is that it's bespoke and designed exactly for their own needs. It also provides a look+feel that is distinct from the typical Material UI fork, which could be considered a savvy move.
They also grow with every feature iteration. It starts with `<Text />` and `<Button />` and then grows to include `<Toast />`, forms, modals, etc.
If the company is big enough they can make it public and get some attention but I don't see why anyone would use them for their own personal projects outside of the very limited scope of the company itself.
I don't know but I don't think many companies can afford to do this.
This reminds me of older UI libraries like jQueryUI that are equally painful on mobile.
Storybook can work fine on mobile so I think they must be doing something to hose the built storybook file.
The main concern is whether to stick to "proprietary" design framework, either it's Jetbrains Ring UI, Atlaskit, and so on.
There are _lots_ of community-driven alternatives, and it feels much safer to pick something that doesn't belong to a corp.
I'm willing to hear pros for choosing such UI framework.
We built https://github.com/freshworks/crayons for the same reason - apps published to the Freshworks Marketplace can be built using Crayons. We also ended up building our own user facing SaaS applications using Crayons.
>Open landing page >Force token update >Log out
I guess not.
This means Amazon is going to sue JetBrains, right?