Touche

86 ms·

901.
by Touche 10y ago
Vanilla JS has long been used to refer to a lower-level JavaScript; ie not using any abstractions. Vanilla JS was often used to compare to jQuery. Of course jQuery is JavaScript.
902.
by Touche 10y ago
So if you want to use a router in Vue what do you do? Well, you install vue-router. The point of Svelte is that it can infer all of the features you are using for you, and not compile the ones that you aren't.
903.
by Touche 10y ago
Also, the problem with big chain restaurants with a thousand things on the menu is not reading the menu, it's that none of it is very good. Much rather eat at a small restaurant with 5 things on the menu that are all excellent.
904.
by Touche 10y ago
I sit on my sofa. Not the best thing for my back, but that's what I do.
905.
by Touche 10y ago
No it's not, transpiling future ECMA-262 is not within the scope of this discussion. We are compared browser-native language features JS (non transpiled), HTML, CSS, to non-native features, namely JSX.
906.
by Touche 10y ago
Transpiling is complexity. You don't have to transpile if you just use web technologies (JavaScript, HTML, CSS).
907.
by Touche 10y ago
> Its such a simple transformation and adheres to javascript standard behavior. JSX doesn't add anything new, it just adds a way to do something old. I don't understand your point, to be honest. A lot of language features are j
908.
by Touche 10y ago
You can't ignore syntax, hyperscript isn't very popular.
909.
by Touche 10y ago
JSX is not JavaScript. If its not in a spec that is ever going to be implemented by a JS runtime, like a browser or Node.js, then it's not JavaScript. It's a superset of JavaScript. If you admit that JSX is a superset of JS then t
910.
by Touche 10y ago
It's not a compiler optimization step. Your code will through without the plugin: https://github.com/threepointone/markdown-in-js/blob/master/...
911.
by Touche 10y ago
It's a leaky abstraction. The point is to make your code do something other than what you described it as doing (because it will do it "better"). That's what makes it unreadable; hiding behavior from code decreases read
912.
by Touche 10y ago
Yeah, I do, slightly. A more noticeable thing is that if you select some text and then Bold / Italics / Underscore, etc. there is a flash where the text appears to be no selected and then becomes selected again. Given this is Reac
913.
by Touche 10y ago
Because if you do: import markdown from 'markdown-in-js'; var markdown = function() { } var foo = markdown` #Header ... `; It will incorrectly rewrite this template literal. And while they could potentially fill th
914.
by Touche 10y ago
> It seems to me that this is nearly universal among nontrivial front and projects. Each one, through its build configuration, has a slightly different subset of all the language features supported by the current crop of JavaScript deriv
915.
by Touche 10y ago
It is specific to this project, in that it will rewrite your code to mean something other than what you intended it to mean. I'm not being critical of this project, I'm being critical of the all too common practice these days of i
916.
by Touche 10y ago
As noted above, I think the practice of installing a bunch of Babel plugins is the wrong approach to this problem. If you want to avoid parsing markdown in the client, then pre-compile it using one of the million markdown compilers that e
917.
by Touche 10y ago
Note that local identifiers (such as vars) mask the import identifier so it will be easy to create a false positive.
918.
by Touche 10y ago
This is a great illustration why using random babel plugins you find on the internet is super dangerous. This works because it assumes you have named your local identifier either `markdown` or `md` and are using that. If you want to use
919.
by Touche 10y ago
Same here, nice to see an app that doesn't immediately add 300k of JavaScript before its really needed. This is 200 lines of code that's pretty useful. Great work.
920.
by Touche 10y ago
Doesn't look like they are really actively working on it: https://bugzilla.mozilla.org/show_bug.cgi?id=889230 https://bugzilla.mozilla.org/show_bug.cgi?id=1205323 Which is weird because FF devs are act
921.
by Touche 10y ago
It's already in Chrome stable. Open your de tools and type `customElements`
922.
by Touche 10y ago
You're right, custom elements don't do that, and it's not a goal of the custom elements spec (as far as I can tell) to promote any particular programming style. It's a low level spec. So showing the most low-level way to
923.
by Touche 10y ago
This one is easier and more universal than the other approaches. There's not setup involved like: $("#foo").myWidget(); You just put the markup on the page and include the JavaScript: <my-widget></my
924.
by Touche 10y ago
Custom elements are not related to templating. I suppose they did it this way because they were highlighting custom elements and not some templating thing.
925.
by Touche 10y ago
Distribute a widget that others can use, or that you can use more easily in other contexts.
926.
by Touche 10y ago
How would you do a progress bar without JavaScript? Well, you wouldn't. So custom elements don't affect progressive enhancement as far as I can see. They enhance the DOM when JavaScript is available and when its not they are essen
927.
by Touche 10y ago
There are examples in this very article.
928.
by Touche 10y ago
I don't know or care, I didn't claim that W3C is breaking a license, just that they are taking other people's work and claiming it as their own. That you can't see the difference between these things is not anything I ca
929.
by Touche 10y ago
> There are those of us who need to develop against a stable feature set. Can you explain what you mean here more? The HTML standard doesn't break compatibility, if that's what you mean, because of course that's not possib
930.
by Touche 10y ago
Probably because the W3C literally copy/pastes other's work and claims it for their own. Look at this blog post, which doesn't credit WHATWG at all for doing the actual work of speccing HTML.

More ›