[HN Gopher] JetBrains Ring UI
___________________________________________________________________
JetBrains Ring UI
Author : gjvc
Score : 287 points
Date : 2022-10-07 16:57 UTC (6 hours ago)
(HTM) web link (jetbrains.github.io)
(TXT) w3m dump (jetbrains.github.io)
| varispeed wrote:
| 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.
| dglass wrote:
| The date picker is pretty impressive. Well done.
|
| https://jetbrains.github.io/ring-ui/master/index.html?path=/...
| harikb wrote:
| I tried selecting a particular date. I couldn't. The selection
| (and the resulting date value in the text column) remained in
| the previous year.
|
| I refreshed the browser and came back, now I can select the
| date.
| yyyk wrote:
| It looks nice, but that's it. Usability is pretty bad. e.g.
| keyboard use completely breaks it on Firefox (didn't test other
| browsers).
| princevegeta89 wrote:
| 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.
|
| Impressive.
| kevingadd wrote:
| Very stylish, but also randomly resets to 2018 when I
| mousewheel scroll, which is kind of unfortunate. The
| fundamental UI design for it is great.
| LeonenTheDK wrote:
| 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.
| dev_snd wrote:
| Looks great in theory, but does not work on Android Firefox
| unfortunately.
| Kiro wrote:
| Not supposed to be used on mobile. These are components to be
| used for building stuff inside JetBrains.
| yesimahuman wrote:
| If you want mobile-enabled components like this Ionic has
| many. Here's the datetime:
| https://ionicframework.com/docs/api/datetime
| joshstrange wrote:
| 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)
|
| 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.
| pmontra wrote:
| 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.
| javier2 wrote:
| Damn that is good. Even with the swipe gesture on mobile. I
| think we are webscale now
| [deleted]
| aka878 wrote:
| Funny enough, it doesn't work is Desktop Safari.
| mardifoufs wrote:
| Does not work on android chromium either
| hooverd wrote:
| Please, just let me type dates.
| throwaway0x7E6 wrote:
| this. please.
| l0b0 wrote:
| 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).
| azinman2 wrote:
| It doesn't scroll on mobile safari.
| sr_impostor_eng wrote:
| This is the first time I see big O notation applied to user
| experience and it's genius, I'll use it in my work from now
| on
| craigching wrote:
| 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 :)
| makmanalp wrote:
| 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.
| paxys wrote:
| Not being able to go back months or years without pressing
| the back button 3000 times is the worst possible design for a
| date picker.
| geekrax wrote:
| 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.
| craigching wrote:
| Exactly. There are tons of different ways to solve that
| problem in react-date picker, this being one of them:
| https://reactdatepicker.com/#example-year-dropdown
| stoplying1 wrote:
| 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.
| matsemann wrote:
| A hundred more clicks than JetBrains' one, though.
| madeofpalk wrote:
| 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 work on grafana frontend)
|
| [0]: https://github.com/grafana/grafana/blob/4b2a9406596ba63a
| 6945...
|
| [1]: https://www.npmjs.com/package/react-calendar
| amluto wrote:
| 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.)
| Kiro wrote:
| Do you use JetBrains software on mobile? This is for building
| stuff inside JetBrains.
| tbcj wrote:
| JetBrains has web applications which is where these are
| used - YouTrack, Space, TeamCity.
| pmontra wrote:
| So, these are components for building their IDEs? They
| can't be used for anything else?
| wartijn_ wrote:
| 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.
| Kiro wrote:
| But the components are not supposed to work on mobile so
| what is there to see?
| wartijn_ wrote:
| 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.
| nsxwolf wrote:
| I wouldn't be investing effort improving the mobile
| browser behavior of desktop oriented controls for the
| benefit of making it a better HN submission.
| [deleted]
| robertlagrant wrote:
| I think you've missed the point of the previous comment.
| mey wrote:
| This is true in Firefox and Chrome on Android as well.
| rob74 wrote:
| 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...
| Kuinox wrote:
| You hope...
| Bilal_io wrote:
| What's broken is the Storybook UI which is only used to
| demo the components. The components themselves should
| work fine on any modern browser.
| cercatrova wrote:
| Storybook is not supposed to be used on mobile, it's a
| desktop optimized UI.
| IshKebab wrote:
| Ok but the reason it is broken really has nothing to do
| with mobile vs desktop.
| CodeSgt wrote:
| It sure seems like the only issues are those on mobile
| danpeddle wrote:
| But then, how do you test components on mobile? Or are we
| not supposed to ask that?
| [deleted]
| Kiro wrote:
| Why would you test components that can only be reached on
| desktop on mobile? These are components to be used inside
| JetBrains IDE.
| fragmede wrote:
| It sure seems like people are reaching this on mobile
| ssalka wrote:
| I wasn't expecting much, but I got a whole lot. Probably the
| best date picker I've ever seen
| palebt wrote:
| What's the relation to the Compose Multiplatform (another UI
| toolkit from JetBrains)? https://www.jetbrains.com/lp/compose-
| mpp/
| pier25 wrote:
| This is such a huge effort.
|
| 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?
| sz4kerto wrote:
| I'd be very surprised if this took 5 FTE years, I'd assume way
| more. Especially including all the non-devs necessary
| (designers, managers, etc.).
| pier25 wrote:
| Honestly I was thinking more like 18-24 months total (for a
| team of 5). 1 UI designer, 1 UX designer, 3 React devs.
|
| 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.
| 4O4 wrote:
| I don't know US market. How common is it to get 50k a month
| as a React dev or UX/UI designer across the USA? Or do you
| mean Silicon Valley only?
| Merad wrote:
| 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.
| pier25 wrote:
| I don't know the US market that much... but here in
| Mexico that's what a decent dev makes when working for a
| US company.
|
| 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?
| cercatrova wrote:
| That's pretty low, I'd expect twice that at least.
| sz4kerto wrote:
| 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)).
| [deleted]
| pier25 wrote:
| Jesus you're right... I'm such an idiot.
| cachvico wrote:
| 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.
| qudat wrote:
| 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.
| pier25 wrote:
| Sure, but at this level of polish?
|
| I don't know but I don't think many companies can afford to
| do this.
| dagmx wrote:
| The top heading bar hides a bunch of the UI elements on mobile.
| Not the best showing for what otherwise seems like a nice project
| from Jetbrains.
| gavmor wrote:
| 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.
| hbn wrote:
| I imagine JetBrains isn't too concerned with mobile interfaces
| considering desktop software is their bread and butter
| MrRiddle wrote:
| jen20 wrote:
| TeamCity has had a web based UI for at least 15 years, so I'd
| imagine they are very much concerned with it.
| jm4 wrote:
| This is not a general purpose responsive web UI toolkit.
| It's a toolkit for their IDE products. Nobody is using
| those on mobile.
| Kwpolska wrote:
| Well, not for IDEs, but web-based developer tools.
| colejohnson66 wrote:
| Even then, YouTrack (at least the one for JetBrains products)
| is extremely slow and annoying to use
| ramesh31 wrote:
| 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.
| dsissitka wrote:
| I'd never heard of it so I did some quick googling.
|
| 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.
| NonNefarious wrote:
| [deleted]
| [deleted]
| vosper wrote:
| > Still doesn't explain what this is doing on here
|
| Because someone posted the link. It's not off-topic, and
| design systems are posted here fairly often.
| NonNefarious wrote:
| Kiro wrote:
| What are you even talking about? Yes, this is exactly the
| type of stuff you will see on HN.
| NonNefarious wrote:
| Mere seconds for some shills to downmod those facts. Go back
| to Reddit, children.
| dang wrote:
| We've banned this account for repeatedly breaking the site
| guidelines. Please don't create accounts to do that with.
|
| https://news.ycombinator.com/newsguidelines.html
| cercatrova wrote:
| Thank you, we appreciate it Dan.
| jbverschoor wrote:
| All these things end with Ng..
|
| So maybe it's React Interface Ng (next gen)?
| NonNefarious wrote:
| pc86 wrote:
| You've used HN before. None of the things you're
| complaining about are unique to this post, or
| particularly new in HN. Why the vitriol now?
| Foobar8568 wrote:
| ng used to be angular stuff.
| https://stackoverflow.com/questions/14669322/what-does-
| the-n...
| Shacklz wrote:
| ng is usually used in an AngularJS-context, which is the
| case here given the displayed code in their "Ng"-legacy-
| components
| ole800 wrote:
| This doesn't work on my fridge, I feel intense discomfort
| tim-- wrote:
| The individual components are really nice, but mixing and
| matching them seems to make a user interface that is condensed
| and overly complex.
|
| YouTrack specifically comes to mind here. It's a fantastic bug
| tracker, but the UI is missing a certain... jeu ne se quoi
| bilekas wrote:
| All I see is :
|
| >Open landing page >Force token update >Log out
| ole800 wrote:
| This doesn't work on my fridge! I feel sad
| cetinsert wrote:
| https://shoelace.style/
|
| 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 :)
| qwertox wrote:
| 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.
| whoisthemachine wrote:
| 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.
| nfoz wrote:
| Adobe didn't create Flash. They bought out Macromedia.
| whoisthemachine wrote:
| Ha very true, the cobwebs of time had erased that from my
| memory.
| runlaszlorun wrote:
| 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...
| ramesh31 wrote:
| >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.
| Existenceblinks wrote:
| 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.
| Karunamon wrote:
| I would argue that dev dependencies do not really matter.
| That leaves a mere 7, 2 of those belong to the same namespace
| as the style.
|
| That said I am also against choosing libraries based on
| political/ideological concerns. React is MIT anyways.
| claytongulick wrote:
| Sure, I'll bite.
|
| 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.
| dimgl wrote:
| > 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.
|
| This is just plain wrong. Like, unbelievably wrong.
| dmitriid wrote:
| > 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).
| Existenceblinks wrote:
| 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.
| dmitriid wrote:
| > Not really "prop drilling" like its docs say.
|
| 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.
| huksley wrote:
| It is not like I endorse (or don't appreciate) one or
| another, just a bit of stats
|
| npm install @shoelace-style/shoelace => 19MB, 17 packages
|
| npm install @jetbrains/ring-ui => 189MB, 560 packages
| cetinsert wrote:
| 1. You are not reading those numbers right!
|
| 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.
| [deleted]
| megaman821 wrote:
| 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.
| withinboredom wrote:
| I've got a feeling this comment won't age well...
| the__alchemist wrote:
| 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.
| Shacklz wrote:
| > If you're doing JS development, just use React.
|
| 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.
| geraldwhen wrote:
| 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.
| thebradbain wrote:
| Why is Vue off the table?
|
| 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.
| wbobeirne wrote:
| Who do you feel React is hurting, and in what way?
| qwertox wrote:
| 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.
| Ambroos wrote:
| 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).
| itslennysfault wrote:
| ... 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.
| Ambroos wrote:
| 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"?
| itslennysfault wrote:
| 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!!
| cercatrova wrote:
| 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/
| woah wrote:
| > Like putting HTML inside strings or whatever they are
| doing.
|
| That's exactly what they're not doing
| ramesh31 wrote:
| >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.
| bornfreddy wrote:
| > ...and a security nightmare where everything is pulling
| in tons of random NPM packages with 4 GitHub 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.
| cercatrova wrote:
| 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.
| dmitriid wrote:
| 1. What "non-native" web standards does React work with?
|
| 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?
| Existenceblinks wrote:
| I don't love React but the examples you mentioned make web
| component look bad. It's as bad (bloat) as React.
|
| ---
|
| 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.
| rapfaria wrote:
| Thought web components were dead
| brailsafe wrote:
| Ironically I had I no clue what I was looking at on mobile
| RomanPushkin wrote:
| I like the initiative.
|
| 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.
| MarathonSeeker wrote:
| 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.
| Mikeb85 wrote:
| Android Chrome right now, the navbar elements are squished and
| the top of the body is hidden by the navbar.
| blantonl wrote:
| Here I am thinking this was a web based IDE for developing user
| interfaces for Ring cameras.
|
| I guess not.
|
| This means Amazon is going to sue JetBrains, right?
| manigandham wrote:
| Lots of UI frameworks by various companies - I keep track of the
| big ones here:
| https://gist.github.com/manigandham/34154e63dc3c1b8747fab40d...
| autoconfig wrote:
| Just FYI a couple of heavy hitters you might wanna add to the
| list:
|
| - Adobe spectrum: https://spectrum.adobe.com/
|
| - Radix UI: https://www.radix-ui.com/
|
| - Tailwind UI: https://tailwindui.com/
|
| - Reach UI: https://reach.tech/
| eddieh wrote:
| Adobe has http://topcoat.io too. How many companies have
| multiple component libraries/frameworks? Seems like a lot of
| wasted time and resources.
| [deleted]
| jbirer wrote:
| So when is the JetBrains operating system coming through? I will
| switch to it if it's as feature-full as other JetBrains products.
| NonNefarious wrote:
| mattmcknight wrote:
| It's a design system. https://www.invisionapp.com/inside-
| design/guide-to-design-sy...
| kyawzazaw wrote:
| People share things they find interesting on HN. Should there
| be a reason?
|
| Why it got on the front page is definitely not the work of the
| OP alone.
| grardb wrote:
| There is a list of components in the sidebar on the left. If
| you click those, you will see those components instead of the
| alerts.
| yCombLinks wrote:
| 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.
| notsrg wrote:
| 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.
| slowmovintarget wrote:
| What you're talking about is advertising and advocacy. I
| personally don't mind less of that.
| hoten wrote:
| Thanks! The initial selection being an alert module had my
| thinking the page was broken...
| tmd83 wrote:
| 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?
| pier25 wrote:
| The Loader component has this parameter:
| hermione: {skip: true}
|
| Is that a reference to Harry Potter or maybe I'm missing
| something as a non native speaker? :)
|
| Edit:
|
| No, it's about this:
|
| https://github.com/gemini-testing/hermione
| ulimn wrote:
| Is it me, or are the labels totally not vertically centered in
| the buttons? I'm using firefox.
| varispeed wrote:
| I am on Chrome and the styling looks messed up or there was no
| UI designer in the team.
| lxe wrote:
| 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.
| savingGrace wrote:
| "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.
| josh_p wrote:
| Component libraries like Telerik and Infragistics still seem to
| be going strong in 2022.
| manmal wrote:
| 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.
| brundolf wrote:
| 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
| jcz_nz wrote:
| 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.
| Philip-J-Fry wrote:
| 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.
| dustingetz wrote:
| datasync / backend-for-frontend problem
| woah wrote:
| > You could build a very complex UI with Ext.JS back in 2010
| with a lot less code and very little time
|
| What's stopping you from doing that now?
| lxe wrote:
| Hype
| jahewson wrote:
| 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.
| Kuinox wrote:
| Funny how this argument was opposed against libraries in the
| early days of programming.
| ethbr0 wrote:
| Developers care about functionality.
|
| Designers care about uniqueness.
| yellsatclouds wrote:
| and their bosses care about both developers and designers
| being replaceable cogs in their company... else the bus
| accident test fails
| RockingGoodNite wrote:
| Where are they based out of these days?
| ComputerGuru wrote:
| 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!)
| api wrote:
| I think this is a desktop-oriented toolkit. It seems to be.
| Shacklz wrote:
| 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.
| geraldwhen wrote:
| If you manage your own web pack config it's pretty
| straightforward to keep updated and working.
|
| 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.
| gedy wrote:
| It's actually the tool they used to host the design system
| (Storybook), it ironically has its own UI, not using the
| Jetbrains components.
| joenathanone wrote:
| Completely locked up my phone, Galaxy S10+ Chrome.
| joenathanone wrote:
| Completely locked up my phones browser, Galaxy S10+ Chrome.
| klabb3 wrote:
| Firefox on iOS here. Crashed the browser, impressive!
| dheera wrote:
| Not only is this website a massive fail on mobile, but simple,
| common gestures like swiping between tabs don't work.
|
| This reminds me of older UI libraries like jQueryUI that are
| equally painful on mobile.
| geraldwhen wrote:
| It's a storybook site. It has nothing to do with the hosted
| components.
|
| Storybook can work fine on mobile so I think they must be doing
| something to hose the built storybook file.
___________________________________________________________________
(page generated 2022-10-07 23:01 UTC)