181–190 of 309 posts
What I don't get: Why is it just for React?
Earlier quoted context omitted.
The question is: how many of these will be maintained several years later? Can you build a long term project on these? Or the expectation is that one has to make a new UI anyway every several years to keep up with the changing fashion, so rewrites are inevitable?
Sure, if it works now, it'll work ten years down the line as long as they're not doing anything nonstandard. There's a big fear that projects that become unmaintained suddenly stop working; this isn't correct. Besides, all webapps are rebuilt in a 3-5 year cycle anyway so it really doesn't matter.
While true, it only applies if you don't want to upgrade your lower level dependencies, ever. And given that this is a React based framework, so it's not based directly on the web platform, if it's not maintained, you'll have to port the framework yourself.
Coversely, if it is maintained, you may be forced to keep up and upgrade whatever this is based on, or backport fixes if the project moves on to a newer incompatible version of the lower level dependency.
> Besides, all webapps are rebuilt in a 3-5 year cycle anyway so it really doesn't matter.
Eh? :D I still iterate on 13 or 9 year old codebases for my clients without re-building anything.
Earlier quoted context omitted.
Apparently you haven't read my comment as you missed "which they are already developing." and "100% support on mobile Web" part. Plus there are polyfills available for the meantime. So what other browsers are many popular ?
> Apparently you haven't read my comment as you missed "which they are already developing." part. Apparently you haven't read my first comment either, since you can't tell the difference between "a spec is implemented" and "planning to implement a spec" which you obviously count as "a spec is implemented" for you or you would have refrained from making your first comment. And no, there is no polyfills for shadow DOM…
Firefox already on beta.
As for Edge it is already in development, and to be honest it doesn't matter with its insignificant market share.
When Microsoft employees use only Chrome at BUILD to show Azure and .NET Core MVC features, the writing is on the wall how relevant the browser is on the market.
Still you keep running away to clarify what "many browsers" means.
Maybe it is my lack of native English skills, but Edge being a single browser is far away from being "many browsers", even if we include Firefox until they get out of beta, two still does not make "many browsers".
I wish people would stop making UI frameworks in , and instead make it web components based with vanilla JS/very light lib dependency, so that everyone can enjoy the benefit. React is becoming a bubble of its own, and it's exclusive.
Those are not standard, some people like VDOM other not, and not everybody want to bind data the same way. So if we all contributed components in vanilla JS / Web Components, this still doesn't solve what should the API of those webcomponent look like.
Earlier quoted context omitted.
Edge is implementing (updated the roadmap), Firefox ships enabled WC's in closest release (it is already in the beta) I think Firefox 63 will ship in a week?. That leaves only IE11/Edge with polyfills.
> That leaves only IE11/Edge with polyfills. what polyfills are you talking about? And no, Polymer is not a polyfill for custom element. Please link me to a library that will polyfill the entire shadow DOM and Custom Element spec so that I can write the same code without polyfills on platforms that support both specs and only load the polyfills on platforms that do not.
Quote from the readme.
" A suite of polyfills supporting the Web Components specs:
Custom Elements v1: allows authors to define their own custom tags (spec, tutorial, polyfill).
Shadow DOM v1: provides encapsulation by hiding DOM subtrees under shadow roots (spec, tutorial, shadydom polyfill, shadycss polyfill). "
Earlier quoted context omitted.
The question is: how many of these will be maintained several years later? Can you build a long term project on these? Or the expectation is that one has to make a new UI anyway every several years to keep up with the changing fashion, so rewrites are inevitable?
I think rewriting UI systems every few years and reimplementing in various JS frameworks that come and go is a serious waste of manpower. I'd so wish people would embrace web components properly once and for all, with LitElement, Svelte or Stencil. This way we won't have to live with another framework-bootstrap clone again and again and everyone can contribute to one solution that will work with all JS frameworks.
This list was posted a few weeks ago, but here is a fairly definitive list of similar UI frameworks: https://element.eleme.io/ https://ant.design/ https://quasar-framework.org/ https://at-ui.github.io/at-ui/ https://developer.microsoft.com/en-us/fabric https://vmware.github.io/clarity/ http://appnexus.github.io/lucid/ https://ng-lightning.github.io/ng-lightning/ https://blueprintjs.com/ http://www.jetbrains.org/ring-…
https://github.com/material-components/material-components-w...
Earlier quoted context omitted.
This is a trivial function, your argument applies to complex utilities. It is piss easy to roll your own, and it's not worth introducing a potential attack vector via a new dependency. In this case, if your devs can't keep up with your classNames function, fire them, because it's trivial. it("should work with no classes", () => { expect(classNames({}).to.be.false }) it("should work with a single class", () => { expec…
If you write 100 ~50 line "trivial functions" you've now written 5000 lines of code that doesn't actually solve your underlying problem, it just makes it slightly easier. And you can't write this particular utility function in 5 minutes and support all the uses-cases, particularly if you are going to write a bunch of unit tests. The reason to depend on someone else's code in trivial use-cases is entirely because they…
Responsive (in terms of interaction with components) and lightweightedness were our top priorities when we started developing (~3 years ago) and no third party solutions seemed to fit the bill back then. Always a fear as well of reliance on third parties for such an important part of the product - is a very large technical risk for the entire business.
We're pleased with the results, our entire app is smaller than the Apple homepage (usable after ~1MB of network transfer) and often starts up faster than our C++ native Windows predecessor. Bloating third party solutions could add significant %'s onto the download size - the example HN React Clone is a comparible size to our product: http://www.hnclone.win/
There was a lot of resistance from users initially when we announced the future of our product would be in the browser and not the native desktop app they were currently using, but we do get emails from users saying after using it for a while they forget they are working in the browser which is amazing.
If we started developing today, I think we'd still roll our own.
Earlier quoted context omitted.
Curious what your issue with classnames is? Is it just because it’s a small and simple module (50 lines of code)?
I was curious so I checked out their Github page. I found this example: classNames('foo', 'bar'); // => 'foo bar' classNames('foo', { bar: true }); // => 'foo bar' classNames({ 'foo-bar': true }); // => 'foo-bar' classNames({ 'foo-bar': false }); // => '' classNames({ foo: true }, { bar: true }); // => 'foo bar' classNames({ foo: true, bar: true }); // => 'foo bar' ... var btnClass = classNames({ btn: true, 'btn-pres…
const classNames = [
“btn”,
this.props.isSelected && “btn-selected”
].filter(Boolean).join(“ “)