W2UI is a JavaScript UI library for building rich web applications(github.com)
github.com
W2UI is a JavaScript UI library for building rich web applications
https://github.com/vitmalina/w2ui
44 comments
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.)
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.
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.
Not only that, but there's a file `.bebelrc`. That really should be `.babelrc`, for the configuration file for the Babel transpiler.
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.
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.
They need to "remoe" the typos
> The library has a small footprint (115kb gziiped)
That's more than most JavaScript frameworks, not taking into account tree shaking, how is this "a small footprint"?
That's more than most JavaScript frameworks, not taking into account tree shaking, how is this "a small footprint"?
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.
JS devs that did not used Desktop or Mobile GUI tolkits have no idea what is missing in the browser.
> would give you say a DataGrid component with sort able columns and some advanced optimizations like windowing
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/[email protected]....
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/[email protected]....
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)
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)
[deleted]
Ooof, 115kb gzipped. That's not exactly featherweight.
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:
<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.
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.
Loading cached JS can still be very slow. https://www.webperf.tips/tip/cached-js-misconceptions/ has a good explanation of the bottlenecks involved.
> 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.
> 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.
Thanks for the link - I'll read up on that!
> 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.
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.
I’m afraid you can’t say modern and not support mobile correctly anymore.
And it's not even on the roadmap.
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?
[0]: https://w2ui.com/web/home
[0]: https://w2ui.com/web/home
I mean, it's got legacy support…
> Latest Chrome, FireFox 7+, Safari 5+ and IE 9+ and Latest Edge are all supported browsers.
> Latest Chrome, FireFox 7+, Safari 5+ and IE 9+ and Latest Edge are all supported browsers.
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.
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.
View source reveals that the home page is made with Bootstrap.
> To compile JS and CSS, run gulp
Shows how dated this modern UI framework is
Shows how dated this modern UI framework is
Haven't heard that name in years.
VS Code still uses gulp for compilation.
I have. I've used it recently when maintaining a legacy project. It's really not that bad, after a few hours of googling.
"and has only one dependency - jQuery, though, it is one of the goals of 2.0 to remoe jQuery as a dependency."
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.
There are so many of these already: https://bestofjs.org/projects?tags=keyboard
"Component oriented" frameworks are what people need 95% of the time. Applaud the effort.
> "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!
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!
Precisely. For internal, and even ‘Portal’ like apps for users, component frameworks can’t be beat on speed of development.
Very few things need an SPA but the industry is obsessed with them…
Very few things need an SPA but the industry is obsessed with them…
So, this library for rich applications implements... a grid, a sidebar, tabs, and forms.
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.
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.
Impressive! Super polished - thank you for sharing.
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.
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.
Seems interesting but quite limiting?
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.
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.
Disappointing, not mobile ready?
https://imgur.com/a/8ZblIf5
https://imgur.com/a/8ZblIf5
Yay for a modern day YUI!!! I'm still using it for a few projects but this looks very nice and might have to migrate over.
YavaScript?
I like it, the demo is quite interesting.
"Simple popup" doesn't trap focus.
How does this compare to dojotoolkit.org ?
> has only one dependency - 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.