161–169 of 169 posts
So far, the Infinite monkey theorem is just giving us an infinite number of javascript frameworks, and no Shakespeare
Earlier quoted context omitted.
Yup. I think within your own components it makes sense to stick with a single library setup for this reason, but atleast if you want to use a third-party component you don't have to rule out components that use different rendering machinery. You just have to weigh that additional download penalty.
Well... At this point you can't e.g. include two web components when one of them uses Polymer 1 and one of them uses Polymer 2, for example...
Earlier quoted context omitted.
Well... At this point you can't e.g. include two web components when one of them uses Polymer 1 and one of them uses Polymer 2, for example...
That's only because Polymer 1 and 2 installed themselves on the `window.Polymer` global, so they would conflict, and Polymer 1 used the old Web Components v0 spec. Polymer 3.0 doesn't write to any globals and can intermix with LitElement, other Web Components libraries, and future Polymer 4.0 and beyond.
So far, the Infinite monkey theorem is just giving us an infinite number of javascript frameworks, and no Shakespeare
I'd disagree. React is very much a "Shakespeare" of javascript frameworks. It has solved UI dev by making even the most complex types of UIs predictably programmable. (Note: not including redux in this, which no developer who owns their time would use)
What's that they say about each and every framework. IMHO there is no Shakespeare and all JS frameworks will eventually die once web assembly is in place.
Earlier quoted context omitted.
Don't assume that everyone is happy with whatever level of mediocrity _you_ think is acceptable. It's because of developers prioritizing developer experience and other baggage over user experience that I despise my mobile web surfing experience. Plenty of people do care about frontend performance (as evidenced by the plethora of efforts ranging from small alt vdom libs by solo devs to large corporate efforts like AMP…
>>Don't assume that everyone is happy with whatever level of mediocrity _you_ think is acceptable. So large library size == mediocre? Jesus christ, HN is full of extremists.
And I, as a user, am left waiting several seconds waiting for pages larger than the original Doom executable to load. It's gotten so bad that my wife had to be selective of when to use her phone because browsing normally without wifi from starbucks etc would get her over the plan limit by mid-month. I mean, how much browsing are you really supposed to be able to do when every page is several MBs of JS alone, and you have a 300MB/mo plan to work with? Not every country has cheap/good mobile plans.
Earlier quoted context omitted.
>>Don't assume that everyone is happy with whatever level of mediocrity _you_ think is acceptable. So large library size == mediocre? Jesus christ, HN is full of extremists.
A large library is perfectly fine if it provides enough functionality to pull its own weight. But these days just about every site on the web has dozens if not hundreds of bloated libraries for the stupidest things and large bundle sizes due to that have become a pretty good indication of wrong priorities from the developer's part. And I, as a user, am left waiting several seconds waiting for pages larger than the or…
If you're interesting in a reactive template library that doesn't require a compiler for non-standard JavaScript syntax, check out a library I've been working on for a little while now, lit-html: https://github.com/Polymer/lit-html Where JSX would look like this: const view = (state, actions) => ( {state.count} actions.down(1)}>- actions.up(1)}>+ ) The lit-html would be: const view = (state, actions) => html` {state.…
> so that it doesn't have to do any expensive VDOM diffs. I am wondering, how is it possible that such non-expensive algorithm is more expensive than many VDOM libraries in this benchmark[1] ? 1. https://rawgit.com/krausest/js-framework-benchmark/master/we...
1. benchmarks have zero information value
2. be careful about wording, react does effective DOM update, but effective does not always mean fast - what I mean is that compiled templates are usually much faster than doing vdom diffing along with all of that destructuring and other unoptimizable (prepack might help, but it's far from being usable) stuff
Earlier quoted context omitted.
> so that it doesn't have to do any expensive VDOM diffs. I am wondering, how is it possible that such non-expensive algorithm is more expensive than many VDOM libraries in this benchmark[1] ? 1. https://rawgit.com/krausest/js-framework-benchmark/master/we...
Please note: 1. benchmarks have zero information value 2. be careful about wording, react does effective DOM update, but effective does not always mean fast - what I mean is that compiled templates are usually much faster than doing vdom diffing along with all of that destructuring and other unoptimizable (prepack might help, but it's far from being usable) stuff
Statements without any proof is more valuable than "benchmarks with zero information value"?
> what I mean is that compiled templates are usually much faster than doing vdom diffing
If they are usually much faster, why it is so hard to make them perform faster than vdom libraries in this benchmark? Or maybe any other benchmark, please just show me something that I can measure.
Earlier quoted context omitted.
> Hyperapp is Elm for the rest of us. Curious who you think Elm is for?
Elm is for anyone. I love Elm. "for the rest of us" is a common English language idiom/phrase. https://english.stackexchange.com/questions/41687/meaning-of... I know the idiom mostly from For Dummies' books. I'm implying that Elm, while great, is not as user-friendly, intuitive or easy to use as Hyperapp. I'm saying that Hyperapp is deeply inspired by Elm, but also designed with extreme devotion to details, minimalis…
First, Elm is designed to be user friendly. The designers of the language have put effort into ensuring the error messages are understandable. The messages even include information on how to potentially resolve them! Elm's error messages are much more friendly than most Javascript error messages I've seen.
Second, there is nothing intuitive about programming. If there were we wouldn't need years of training to gain proficiency: you could simply give a human being a computer and they would be able to do it in the absence of conscious reasoning. Despite our best efforts and research there has yet to emerge a language that is intuitive.
> designed with extreme devotion to details, minimalism, and simplicity
I believe Elm is also designed with these concepts in mind.
It sounds like it's not the kind of simplicity you're used to and that may be why Hyperapp is _for you_.
I interpreted the phrase, for the rest of us, to be a false equivalence between all programmers that do not use Elm and programmers with the same opinions and needs as you. I think I understand your point better now but it would have been clearer if you had left out that phrase and enumerated why it's better for people who need X instead.