Good to see this is still maintained and a new version is planned which moves away from jquery.
We used to use this in a project few years back and it enabled us to quickly prototype low-effort admin interfaces. It is a nice package that provides commonly useful interface components like resizable panels, data grids, toolbars, tabs etc. which looked good out of the box.
We eventually moved away because RTL support was missing, and decided to use more specialized libraries which provided more control over form validation, and a more feature-rich datagrid. But it was a pleasant getting-started experience while our team was small, and speed of iteration was more important than featureset. The author is also quite helpful.
I’m a bit nonplussed how a library with thousands of stars can have a main README file that’s just littered with typos and inconsistencies.
To be clear, I'm not suggesting the original author should get it perfect. I just made a few typos when editing the readme. I'm just surprised it can be so popular and _nobody_ comes by and fixes this stuff in all the years.
(And I’m going to be the change I want to see and rather than just complain, I’m going make a PR.)
I think the world is just a lot smaller than we think. The amount of people who have done X or are willing to do X is smaller than we expect. The number of people who will see a typo and be arsed to fix it just isn't big.
Even in popular software, I have run into catastrophic bugs in rather entry-level cases that make me wonder if I'm the only person using the software.
It just makes me realize the world ain't that big. And that you can have a surprisingly larger impact on the world than you think.
I'm not sure if you already did the PR... I just see a few places where the word the is missing, which is fairly common for non-native English speakers.
In my experience since I'm a newbie even though I get get annoyed at inconsistencies and typos. People at work just ignore/say he's learning so he focuses on typos more rather than logic.
You just have yo understand it typos and inconsistencies doesn't matter as long as you understand the project. Which infuriates me but I can't anything about.
That stops me from doing this stuff online too cause don't want owners react same way as my example.
I am not familiar with this library, but if it does what it should then ofcouse is bigger, with react you just get a way to render divs and spans on screen, a GUI framework would give you say a DataGrid component with sort able columns and some advanced optimizations like windowing (aka a grid with 1 million rows will use same resources as a small DataGrid because it will only create enough DOM elements for the visible part and then recycle stuff).
JS devs that did not used Desktop or Mobile GUI tolkits have no idea what is missing in the browser.
Sorry I can't judge those, the thing is all the ones I used so far, including boostrap are really basic. You would need a library for a trully complete DataGrid, one for a real dropdown, one for a real listbox, one for a modal manager, one for menus etc.
This widgets appear to be simple but can have more advanced usage, like a dropdown where you can navigate with the keyboard arrows or PgUp/PgDown, you could type a character and the dropdown would instantly jump to the that item , you can specify if the dropdown popup up or down, have many items are visible at once, you can have items with different fonts styles , disabled items.
This classic frameworks are good for doing business apps or apps for working and not for simple apps that need to look cool to sell.
The Youtube Search box has a dropdown thing, sometimes that thing gets stuck open and you have to reload the page, so a giant like google with their expensive developers are not able to do a average complexity widget. But I seen worse, fancy input widgets where you could not use the Delete button (the Skype money amount input)
Tell me what I'm missing here - my project requires a download of N resources over N different hits to get them. Now in theory I host all my dependencies like css file, font-files, images and js files. Assuming I turn on gzip at my web server (nginx lets say) and I set up cache headers such that every resource file downloaded does not expire for 1 year, then the files download 1x for every initial page load. The first time is a hit not unlike downloading a decent sized image file which we all do without complaint on a daily basis.
Sure, I get it - a whole bunch of stuff has to come down before Document.onload() can be called and thats time from a JS perspective the user is looking at nothing. What I like to do is setup the default screen to be a fixed position blocking layer with my company logo on it and the last thing Document.onload() does is remove it. The initial load they see it for 1.4 seconds. Subsequent reloads from browser cache it's up barely long enough to notice.
So the problem of initial load is easily managed and not that big of a problem in the first place honestly. Simply setup caching on the web server to persist the files as long as possible ( I think a year is the max in most places now ) and problem solved right?
Now occasionally I run across some browser on some platform thats greedy about caching and refuses to pay proper attention to cache headers and replace them with newer versions when they come down. Its a little more of a pain but still well worth it to simply add a fingerprint to each remote resource fetched:
Now at build or deploy time I incorporate a little script that generates the current time in seconds and uses sed to replace FINGERPRINT with the current time in seconds (123888238823482834) such that browser sees:
This is a unique URL and forces the browser to pull down the new asset. This is easy to do with resources pulled down in the <head> section and more problematic with images however you just change the image name from "image" to "image_v2" on edits or changes and the problem goes away. Its easily enough done to iterate the image directory changing "*.jpg" files to a new version number and making the same replacements in html and js files if you really want to get tricky about it.
Now, new files are fetched one and only once per device and the page weight of a particular JS file becomes practically irrelevant.
> Subsequent reloads from browser cache it's up barely long enough to notice.
Are you measuring the time on your personal machine, or a machine that represents what your typical visitor is using? If you're using a recent Macbook, that's going to have very different performance characteristics than, say, an old Android phone. Something that's instantaneous on a Macbook could take ages on an old Android.
> Now, new files are fetched one and only once per device and the page weight of a particular JS file becomes practically irrelevant.
It's not just download speed -- it's the parsing and execution of the script that takes CPU and memory. 115KB of JS is much heavier than e.g. 115KB of JPEG.
Looks nice. I don't know much about modern UI development and often I want to just quickly add a nice looking UI to some of my throwaway/pet projects without having to learn all the modern concepts of React & Co. If this library allows me to declare the components I want with a few event handlers (with as little JS as possible) and it does the rest (I'm OK with the default UI if it looks nice enough), I'm certainly going to give it a try. And I also wonder, what's the opinion of professional frontend developers on frameworks like this, and why they're not more popular?
The home page [0] looks like something made with Bootstrap 2 (with all those gradients and Helvetica), and the browser logos at the bottom of that page are equally ancient. How is this UI library in any way useful today?
Yes, this, along with the README comments from others makes it look like it's pretty dated.
It's still impressive but it does seem to be largely one main contributor (plus one other reasonably significant contributor) and not much buy-in by the community to improve even fairly low hanging fruit such as typos, cleaning out old cruft etc.
JS UI libraries are very common. Yknow what I’d like? A proper JS key command library. Something that allows you to hook key commands into application state. There’s a new influx of keyboard focused web applications. It’d be nice if someone could make a framework for them.
> "Component oriented" frameworks are what people need 95% of the time.
Agreed! I'd argue that the technology doesn't even matter, whether it's this or something like PrimeVue, ready-made component frameworks/libraries are a godsend when you need to get something out the door in a reasonable amount of time!
It's a great indictment of the platform that nothing approaches Sencha(former ExtJS) in the platform itself or in the "rich UI" libraries that keep springing up like mushrooms after the rain.
For example, the declarative tabs looks nice. But the only property for the contents of a tab is "text". Is there a way to define a DOM element the place there? Perhaps one I've constructed beforehand? I couldn't find one on the site.
We used to use this in a project few years back and it enabled us to quickly prototype low-effort admin interfaces. It is a nice package that provides commonly useful interface components like resizable panels, data grids, toolbars, tabs etc. which looked good out of the box.
We eventually moved away because RTL support was missing, and decided to use more specialized libraries which provided more control over form validation, and a more feature-rich datagrid. But it was a pleasant getting-started experience while our team was small, and speed of iteration was more important than featureset. The author is also quite helpful.