> 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.
Except that the top bar covers about the top 2/3 of it on mobile safari. This glitch renders essentially the entire site useless.
(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.)
These components are not used inside any Jetbrains IDEs. Those IDEs are, of course, written in Java and cannot use a browser-based UI framework. This is for "our web-based products like YouTrack, Hub, TeamCity, and Upsource" (per the original release blog post for Ring UI). Those products support mobile.
JetBrains IDEs are not on mobile though. It doesn't matter if they're incidentally accessed on mobile if they're not actually designed to be used on mobile.
It's a bug that manifests itself on mobile, but it probably does the same thing on desktop too if you shrink the window really small, and even if it doesn't, it's just a CSS big that is triggered by mobile browsers. There's nothing big that is preventing it from working fine on mobile. Most of the pages do work fine.
I guess this is more desktop-centric than most other browser-based UIs - I mean, JetBrains is mostly developer tools, and most people don't use their phone for programming...
I don't but I do use, and am interested in, their software. So it's a bit disappointing to see a link to their site while using hn on mobile, only to get to a page that doesn't display anything useful.
You seem to assume that everybody on this website knows what Ring UI is. But I didn't know and judging from quite a few other comments here, I wasn't the only one. All we had to go by was the title "JetBrains Ring UI" and a comment stating that a date picker looks nice. Without any kind of description it's not that weird to assume a website with a datepicker works decently on mobile.
I'd totally use them on my mobile devices if versions for them existed. They're just too convenient even though they lack a keyboard. Wish I could use them to write software.
Yep. Scrolled into the 2100s and back into the 1800s in a few seconds, then decided to figure out which day of the week I was born, which took about three seconds. In most date pickers this would've taken O(year difference * month difference + day of month), here it took something like O(year difference + month difference + day of month).
Wow, that's gotta be the nicest looking and most functional date picker I've ever seen. Date pickers are normally so hit or miss imo but this one is a hit out of the park.
Ionic's is probably one of the best date+time combo (other examples are always strong in one and terrible in the other, time being the thing that often gets short shrift)
Interestingly it lets see both the iOS and Material Design versions of the component.
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.
Almost no contrast on the year. Clicking the year doesn't change the year in (either) textbox but scrolls a different section. Month 'highlighting' overlaps with adjacent months including picking January which highlights both January and December. If you type a text date (which is in a different edit box for some reason) and then click outside the box it won't 'save' the changes because you have to hit enter. If you open up the picker again it will at least remember what you typed before which is now different from the text date above itself. Mousewheel scrolling individual items like months doesn't actually go to the next month it just scrolls the calendar a bit, but sometimes skips around: while scrolling down it went from 11 Aug 2000, 2 Jan 2002, 22 Sep 2000 (I think because in some states my cursor was over an item). What did you like about it?
It's not bad, but I have grown really fond of Grafana's date/time picker and can whip up a clone of that using React-Bootstrap and React Datepicker (https://reactdatepicker.com) in about ten minutes :)
For what it's worth, the Grafana date picker[0] is "just" react-calendar[1]. The time range picker you see on a dashboard uses that and a bunch of other (custom) stuff.
I am assuming that you're judging the behavior by the minimal example in the top 1% of the site. If you scroll further, you will notice how extensible it is to support not only month and date navigation but many other customizations.
I also assumed it was limited in such ways. Mostly because it is extraordinarily rare that anyone bothers to enable those. I'd much, much, much rather have a singular, consistent full UX available to me instead of defaulting to some "simple elegant" artificially stunted version.
Funnily enough I have a pet peeve with Grafana's picker (which is overall quite nice) - I can't copy and paste the whole date range from one window to another in one go. I'm often punching in varies specific datetime ranges across multiple dashboards so this comes up all the time every day. Sure I've added data links for the cases that I use most frequently but I can't do that for everything. The "recently used ranges" (which is a neat feature) doesn't seem to work across dashboards and seems to require a page reload which baffles me a bit.
We tend to go dogmatic on date pickers. Gotta use them everywhere someone asks for a date. That's the problem right there.
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.
It's incredible they basically built it with a completely different design in mind. Making use of scrolls/swipes for months and years on the same screen.
It looks good though took me longer to pick my birth date. I don't care how many days a month in certain year has, or day number is at which day of week. I guess it comes down to each own preference. One thing at a time is more focus.
Component UI libraries have converged towards providing the most basic building blocks instead of creating higher levels of abstraction, which I personally think is a bad trend.
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.
Supplying the building blocks is how you're able to compose them into something different.
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.
What's shifted is that product/design want the UI to be distinctive to the company and its brand. So each company needs its own foundational UI library, or at least a highly-customizable third party one
For some apps. For internally-facing admin for example tools we want a minimal learning curve and readily recognisable, sign posted models. It needs to look like stuff you already know, down to icons and ux behaviour.
Being limited to highly abstracted libraries leads to worse UI because you have to shoehorn your app into the limited set of forms the library allows you to express.
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 web is exactly a bad argument, it composes terribly. You can make n*m divs for the days for a calendar widget, it won’t be recognized as a date selector. While swing, or even earlier GUI iterations realized that inheritance is a very sane model for GUI frameworks.
An approach I like is to provide basic components (i.e. a toolkit) and higher order components that can be copied into the project as required. This allows maximal flexibility while also providing the possibility to DRY things up in your own codebase.
Tailwind and Tailwind components achieves this for example. Web components also come to mind.
"You could build a very complex UI with Ext.JS back in 2010 with a lot less code and very little time" I have not encountered a more complex and verbose library than ExtJS. I would never in a million years say "very little time" with ExtJS. I did not enjoy my time with it at all. And that was a whole lot of time, since it took forever to do the simplest of things.
I've had the same frustration. I want to go from intent to a UI as quickly as possible.
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.
The linked webpage is generated with Storybook.js, a generic web component display framework, and is not itself en exemplar of the showcased UI library.
I really hate when a dev makes excuse blaming an external library for lack of integration. It is them that chose whatever the library and didn't care to fix.
Note to readers: you need to view this on a desktop (or maybe a tablet would work?). At least on my phone a considerable amount of the functional UI is completely cut off and rendered inaccessible even with scrolling. (Hopefully they are not dogfooding and this has nothing to do with the tech they’re touting!)
Probably some storybook-related issue, we also use it at work, and while it's a joy to use when it works it can be a pain to set up, and it does tend to need a bit more effort to keep it stable than one would wish for unfortunately.
Every company has a frontend team, and all of those frontend folks want to get promoted. Building an in-house component library is a straightforward card to play.
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.)
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?
>Who do you feel React is hurting, and in what way?
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.
This is exactly why I use React after using libraries like Vue. The ecosystem matters, and non-React libraries are simply just not there. I want to make stuff, not wrangle around with poorly-supported dependencies.
My biggest issue with React is how it mixes HTML in Javascript. Like putting HTML inside strings or whatever they are doing. Without proper tooling and an editor which supports it, you won't get anywhere. At least that's my amateurish feeling on React, my reason for avoiding it. I may very well be wrong, but I wouldn't know.
Of all the ways to write how your HTML is supposed to look from JavaScript, JSX is probably the closest to Javascript there is. It's a very simple syntax translation to JS function calls, and all code / logic is still plain JS. Every other template language that invents their own loops / conditionals / ways to insert variables is waaaaaaay further away from JS (and also still needs tooling and editor support).
... or don't write how your HTML is supposed to look from JavaScript.
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.
Do you genuinely think Angular's template language and all the complexity it comes with is better than JSX just saying "anything between {} is plain JS"?
You'd be wrong. JSX is just syntax sugar over manipulating nested JS objects which represent the state. Try React sometime, their docs are great: https://beta.reactjs.org/
Agreed. React reminds me of early days PHP. Which I supposed makes sense from an engineering org that was birthed on PHP. Separation of concerns?? NAHHH!!
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.
Shoelace looks great, thx for posting! If you can think of any more in that vein- that is clean looking vanilla web components without adding a ton of ‘framework’- feel free to share.
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…
Thank you for sharing the shoelace link. Looks like it behaves well on mobile, unlike many other frameworks. I'm using Quasar, but I want to try something else.
Weird that a framework created by Adobe, the creators of Flash, one of the most non-standard web ever created, would be cited as a web standard friendly alternative to React. Such is the way when a company loses its competitive advantage /shrug.
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.
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.
First, dev dependencies don't count. There two are from shoelace. Color's main features will eventually be in one of the CSS Color Module's specs. Floating UI's main features will be in the CSS Anchor Positioning spec. Lit is used for building the web components. Lit React can be removed when React supports web components better. The QR library can probably only be installed if needed.
The less thing people know, the high risk, the more defensive. Like losing the entire basket of egg. In traditional way, they dedicated the whole life to one thing, and that was called a cult.
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.
Angular is an option from a high level but I would argue against it on merit.
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.
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.
> JSX doesn't end up bringing much value over vanilla html
> 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 think the Context proposal is rather "send function to data" style data flow. (there's another one, more like plain client-server data flow; req-res) Not really "prop drilling" like its docs say.
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.
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.
This depends on the use. For a complex web app, React may be a good choice. For a web page with interactivity (There is a grey area between), native HTML/JS/CSS provides a much more responsive experience to the user. Faster load, lower latency, and reduced RAM use. It also makes it easier to develop and maintain, due to not relying on a build process or DSL.
This is very very good. Clean, simple, extensible. The death of Material UI patterns can't come fast enough IMO, and I'm glad to see people moving away from it toward a more functional aesthetic.
It looks impressive in terms of features, but it feels like it was done solely by developers and there was no thought put into looks.
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.
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?
Literally every company I have worked for builds a component UI library. They are boring and catered specifically to the company's branding and needs.
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 think it's more likely this grew from a single developer who knew what he's doing, to a small team, organically over time as they expanded.
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.
Why are you multiplying yearly salaries with months? :)
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)).
50k per month (600k per year) is an extraordinarily high salary even in the US. I assume the parent poster meant 50k per month for the team of 5, so each dev is getting 10k per month/120k per year.
Does anyone has thoughts on what's the best datetime picker that works sanely in mobile, first to pick an olde date (Say birth date) and user date/time can also be somewhat typed in on the text field?
The main reason you would want to pick such a proprietary library is to achieve a homogeneous look and feel (often behavioral UX as well) when your app must work within another product - this product/organization is usually the one that also provides the library in question, and more often than not, uses the same design system if not the library itself.
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.
That doesn't answer any of the questions. What am I supposed to be admiring, thinking about, using this for? Is this a tool I should adopt or test? Is this a new UI pattern to think about? There's no obvious context.
As a FE developer I appreciate the updates from HN when a bigger company releases something as OSS. It's nice to know what approaches others are taking to solve similar problems.
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.