241–250 of 255 posts
Earlier quoted context omitted.
Or use Polymer/LitElement, where it's just all in one file... I swear people are just reinventing react methods to eventually get to where Web Components have been for the past 4 years.
React is greater than 4 years old, and people mostly use it for the nice authoring experience, not to dick around with CSS isolation problems.
SASS + BEM accomplish the result in a more manageable way.
Earlier quoted context omitted.
> it's valid HTML with attributes that tell Vue how to bind to it. It's really not that difficult. You mean it has at least three JS-like DSLs (which are not JS, and have different rules depending on which context they are in). In addition it has a very weird binding system which I described at length in the linked comment. Yup. "Not that difficult". Meanwhile JSX is a single consistent DSL that directly maps to func…
> That's it. Even "html-like" attributes that people seem to not like... are exactly what HTML attributes are in actual Javascript DOM APIs [1] [2] The attributes / DOM properties in JSX are also a mixed bag and not consistent. See https://github.com/facebook/react/issues/13525#issuecomment-... > Look, it's exactly what React without JSX is [3]. Only in React you don't need to invent a custom scripting language and b…
Yes. However, one thing you fail to see is that it directly compiles to function calls.
{valid JS expression}
React.createElement(Tag, { a: "b", x: y + z }, [])
- you have access to JS variable in scope
- you can use JS facilities (proper if/switch statements, for loops, functional programming, you name it)
- you need no additional scripting or templating features. It's, well, just Javascript.
However in Vue (emphasis mine):
> There's really nothing that complicated in here, if you're familiar with Vue.
Yes. Exactly. If you're familiar with Vue
So:
- custom tag attributes: v-bind, v-if, v-for, v-on, v-show, v-model... (I honestly don't know how long this list is)
- custom attribute shorthands: :key, @key
- attribute extensions: v-on:keypress.prevent
Inside attributes you can have:
- Javascript expressions (much like React inside {})
- or magic binding:
v-bind:href="url", v-if="seen" etc.
v-bind:class="{ active: isActive, 'text-danger': hasError }"
v-bind:class="[activeClass, errorClass]"
v-bind:class="[{ active: isActive }, errorClass]"
v-for="(item, index) in items"
v-for="(item, index) in items" :key="items.id"
v-on:click="counter += 1"
v-on:click="greet"
v-on:click="say('what')"
v-on:click="warn('Form cannot be submitted yet.', $event)"
v-on:click.stop.prevent="doThat"
Oh yes, and this gets compiled down to some JS that bears little to no resemblance to original code.
And somehow people complain about how React is difficult. Wat?
Earlier quoted context omitted.
> What is so weird about it? I go a bit in depth here: https://news.ycombinator.com/item?id=17471199 > Vue has the option to use Webpack to compile html compliant templates to JS functions just like JSX Vue's templates are not HTML-compliant. They are just that: templates. That get compiled to JS anyway. > JSX (which BTW is not JavaScript and not HTML compliant and is also a separate concept that needs to be learned…
I thought one of the beauty of vue template is 'It is not complete set of JavaScript logics, only subset that just able to support proper html structure.'. It means you can't abuse JavaScript everywhere, creating totally unreadable render function, nest array mapping in Ternary operator and reduce it to what the hell no one can read and destroy all the readabilities. For me, for you, for everyone, if you using that s…
The problem with all templating systems is that they start with "we need to limit the amount of logic". But all templating systems find out that this is extremely limiting. So they grow. And grow. And grow. And grow.
Same with Vue. The amount of special cases and custom things just grows and grows. See my comment here: https://news.ycombinator.com/item?id=19199423
You need simple conditional logic. So you end up with v-if and v-else. Then you have to add v-if-else.
You need loops. So you end up with a custom DSL for v-for. And then you expand it to also work on objects. And you need to bind to object produced inside the for loop. And...
And you need to handle events. But events are anything but simple. You need to prevent them, you need to stop or start propagation, you need access to their properties. So you end up with v-on:click.stop.prevent. And function calls. And magic variables in the form of $event.
Worse still, all your existing knowledge about how to apply these concepts in JS is void. Template has taken over.
So in the end you end up with a system that is not really HTML, not really JS, but a weird combination of the two. And the amount of concepts is not exactly more readable than plain React that just uses JS everywhere.
Earlier quoted context omitted.
> That's it. Even "html-like" attributes that people seem to not like... are exactly what HTML attributes are in actual Javascript DOM APIs [1] [2] The attributes / DOM properties in JSX are also a mixed bag and not consistent. See https://github.com/facebook/react/issues/13525#issuecomment-... > Look, it's exactly what React without JSX is [3]. Only in React you don't need to invent a custom scripting language and b…
> JSX is a custom extension to JavaScript. > In fact, you have to use some sort of transpiler in order to use it. So, it's not just JavaScript. Yes. However, one thing you fail to see is that it directly compiles to function calls. {valid JS expression} is React.createElement(Tag, { a: "b", x: y + z }, [ ]) Which means: - you have access to JS variable in scope - you can use JS facilities (proper if/switch statements…
I understand how JSX works, stop patronizing me. The only thing I fail at is seeing how any of your examples are complicated or have magic so deep that you need to continue to burn Vue at the stake for. In fact, I find your Vue template examples completely intuitive and easy understand with minimal time invested in learning how Vue templates work. It's my preference to spend a little bit of effort up front learning how Vue templates work in order to have clearer separation between business logic and templates.
Earlier quoted context omitted.
> What is so weird about it? I go a bit in depth here: https://news.ycombinator.com/item?id=17471199 > Vue has the option to use Webpack to compile html compliant templates to JS functions just like JSX Vue's templates are not HTML-compliant. They are just that: templates. That get compiled to JS anyway. > JSX (which BTW is not JavaScript and not HTML compliant and is also a separate concept that needs to be learned…
I thought one of the beauty of vue template is 'It is not complete set of JavaScript logics, only subset that just able to support proper html structure.'. It means you can't abuse JavaScript everywhere, creating totally unreadable render function, nest array mapping in Ternary operator and reduce it to what the hell no one can read and destroy all the readabilities. For me, for you, for everyone, if you using that s…
Earlier quoted context omitted.
This is sad. All because people are not able to think of one simple prefix and stick with it when naming CSS classes. How hard can it be? Just use some part or abbreviation of the company name and be done with it. Or better yet: Let third party do that. I always hated that, when someone used Bootstrap on a website and Bootstrap f'ed up all future styling, by assuming it was the only one player in the game. So stupid.…
I'm happy that just prefixing things is working for you. I don't typically have problems on smaller projects. But I've also been writing CSS since 1997. I've deployed CSS to sites like walmart.com, nfl.com, mlb.com, starbucks.com, twitch.tv, etc. Some of these sites have a lot of third-party widgets on them. I can confidently say that the (multiple) issues with CSS are not a "just do " type of problem.
I'd go so far to say that almost no (real) problem is that type of problem. Maybe problems that are mostly inconsequential, sure.
Earlier quoted context omitted.
With copy and paste? :)
Am I misinterpreting something? In my app that uses CSS-in-JS, if I go to the "Elements" tab of my browser developer tools and select an element, I have the option to inspect, add, remove and change styles — including using the color picker and bézier curve editor — and have it reflected live on the page.
Earlier quoted context omitted.
A lot of CSS-in-JS libraries provide a theming solution, e.g. [1], so it's not an 'either/or'. (You can also relatively easily implement your own, because JS :)) [1] https://www.styled-components.com/docs/advanced#theming
Sure. My point is, when it comes to visual styling, you inherently have a shared visual context. The post I was replying to was concerned with the "global" nature of CSS. I'm pointing out that this is inherent to the problem space. You have to deal with it whether you use CSS, code or any other mechanism to style.
Earlier quoted context omitted.
Good software is reusable. I can import functions from 1,000,000 different npm modules all into my project and they don't fuck with each other, right? Let's say you wanted to pull in a button from Bootstrap for one part of your page, a button from Material UI elsewhere, a button from Semantic UI elsewhere, etc. These things are made to be reusable right? What are the chances you can do that without issues? Do you thi…
> Good software is reusable. I can import functions from 1,000,000 different npm modules all into my project and they don't fuck with each other, right? I just spent the whole day trying to fix compatibility issues between different versions of npm libraries transitively imported in a project. Reusability in JS is a joke.
As a primarily JS/React developer, I think there is irony if JS is held as a good design pattern in comparison to CSS with respect to reusability. Inasmuch as what are being called CSS "workarounds" are in fact workarounds, so too has been the case with JavaScript itself. I am old enough to remember jQuery and Prototype colliding over the dollarsign namespace.
Don't get me wrong. I am not a JS (or CSS) hater. I think these "workarounds" are more than adequate in making these technologies easy to work with. Which I suppose is sort of my point. I see a lot of overengineered codebases with Byzantine solutions to relatively simple problems.
Also, to parent poster:
> Let's say you wanted to pull in a button from Bootstrap for one part of your page, a button from Material UI elsewhere, a button from Semantic UI elsewhere, etc.
1) First of all, don't do this. Perhaps you were just saying this to make a point, but obviously don't include 3 monolothic libs with overlapping functionality in order to implement 3 things with the same functionality.
2) It sounds like your problem with this is more with the libraries themselves. When I write a component, I always namespace it myself. Obviously, if libraries are properly namespaced, then you could easily include buttons from three separate button libraries.