W2UI is a JavaScript UI library for building rich web applications
github.com
github.com
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.
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.)
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.
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.
That's more than most JavaScript frameworks, not taking into account tree shaking, how is this "a small footprint"?
JS devs that did not used Desktop or Mobile GUI tolkits have no idea what is missing in the browser.
react-data-grid is 13.8KB gzipped[1]. React itself is ~45KB gzipped, so that's ~60KB total, nearly half the size of W2UI.
edit: And if you want a full-fledged component library, you could also throw in react-bootstrap, which is <40KB gzipped.
[1] https://bundlephobia.com/package/react-data-grid@7.0.0-beta....
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)
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:
<link rel="stylesheet" href="/foo/bar.css>
becomes:
<link rel="stylesheet" href="/foo/bar.css?id=FINGERPRINT">
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:
<link rel="stylesheet" href="/foo/bar.css?id=123888238823482834">
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.
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.
> Latest Chrome, FireFox 7+, Safari 5+ and IE 9+ and Latest Edge are all supported browsers.
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.
Shows how dated this modern UI framework is
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!
What's rich about it? Here's rich: https://examples.sencha.com/extjs/6.2.0/examples/kitchensink...
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.
At first I thought there was no column sorting, but it's just not enabled on most examples - click the "Virtual Scroll" section to see it.
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.