4 ms·

I gave you an up vote, because that's the great thing about this industry -- there are many valid opinions and options for each problem. Its more about balancin

I gave you an up vote, because that's the great thing about this industry -- there are many valid opinions and options for each problem. Its more about balancing tradeoffs then anything else. Mine stems from working in the industry for nearly a decade, and shipping 100% js projects in a variety of frameworks (angular, react, vue and backbone to name a few). Most of the time, but not all of the time, I see iteration and maintenance costs far exceed simpler js enhanced pages. If js everywhere works for you and your team better, then that's what you should do.

jkoudys 8y ago
Oh I've been around a long time too, and I've definitely had that experience in the past. Presentation logic was the really _big_ one years ago. Few devs seemed at all bothered if their views were extremely complex, contained heavily nested conditionals, poorly componentised, etc. Presentation wasn't seen as "serious" code, because real devs did backends. As a result, so much of our available tools, libraries, docs, blog posts, etc. were valued based on how quickly you can churn out something that matches some mockup at one point in time, and that's it. You'd never make any significant updates, only create new pages to replace it. In this world, a completely separate dev (or designer) would throw together the HTML/CSS and the ecma dev would link up some events to the buttons. I've really seen it flip after React matured, and everyone started transpiling w/ bundlers. I don't have some `colors.scss` with a bunch of constants, and then redefine those same constants in my .js anywhere -- I have a .js file with my palette. I don't embed logic into the template with a bunch of `<div ng-if` stuff anymore, I can use the same `if` I use everywhere else. All my static analysis for unreachable code detection, style guides, etc. runs the same everywhere. I'd argue that those "simpler js enhanced pages" aren't so much simpler, as they are merely more familiar. 1 consistent approach in one language, that is equally (or more) suited for declarative code, is simpler than 3 languages with 3 approaches. One module that says `export default css({ p: { fontSize: '16px' } });` then importing it into another file is simpler than some scss `.MyBigClassName { p { font-size: 16px; } }` then remembering that classname in your HTML. `h('p', { onClick }, 'Hello!')` (or `<p onClick={onClick}>Hello</p>` in jsx) isn't more complicated than `<p class="foobar">Hello</p>` and some js elsewhere that says `$('.foobar').click(` or whatever. I've taken this approach with my very intern/jr heavy team, and they all take to it really fast. It tends to be the older devs who are more resistant, because it requires changing old habits.
- was_boring 8y ago
  > I don't have some `colors.scss` with a bunch of constants, and then redefine those same constants in my .js anywhere -- I have a .js file with my palette. Thank you for your reply. Do you have an example repo of using this pattern? I'm afraid I'm not terribly familiar with _not_ having any css files and instead defining it in a js file. create-react-app maintained by facebook doesn't seem to follow this pattern (unless I'm misunderstanding).
  - jkoudys 8y ago
    [emotion](https://github.com/emotion-js/emotion https://github.com/emotion-js/emotion) is the main lib doing it now -- it's pretty popular among the React crowd, and sits at 5k stars right now. It's a nice, gradual transition, since it mostly follows scss-like syntax, and the docs all use tagged templates. e.g. `const className = css\`p { font-size: 16px; }\`;`, but `const className = css({ p: { fontSize: '16px' } });` works fine too. What's cool is you can use the same obj conventions for the CSS as a React component's `style` prop, or a regular Node's style. e.g. if I have `const headerColor = { color: '#ff0000', backgroundColor: '#00ff00' };`, I can say `<div style={headerColor}>`, or `Object.assign(document.querySelector('p').style, headerColor)` too.

jkoudys 8y ago

Oh I've been around a long time too, and I've definitely had that experience in the past. Presentation logic was the really _big_ one years ago. Few devs seemed at all bothered if their views were extremely complex, contained heavily nested conditionals, poorly componentised, etc. Presentation wasn't seen as "serious" code, because real devs did backends. As a result, so much of our available tools, libraries, docs, blog posts, etc. were valued based on how quickly you can churn out something that matches some mockup at one point in time, and that's it. You'd never make any significant updates, only create new pages to replace it. In this world, a completely separate dev (or designer) would throw together the HTML/CSS and the ecma dev would link up some events to the buttons. I've really seen it flip after React matured, and everyone started transpiling w/ bundlers. I don't have some `colors.scss` with a bunch of constants, and then redefine those same constants in my .js anywhere -- I have a .js file with my palette. I don't embed logic into the template with a bunch of `<div ng-if` stuff anymore, I can use the same `if` I use everywhere else. All my static analysis for unreachable code detection, style guides, etc. runs the same everywhere. I'd argue that those "simpler js enhanced pages" aren't so much simpler, as they are merely more familiar. 1 consistent approach in one language, that is equally (or more) suited for declarative code, is simpler than 3 languages with 3 approaches. One module that says `export default css({ p: { fontSize: '16px' } });` then importing it into another file is simpler than some scss `.MyBigClassName { p { font-size: 16px; } }` then remembering that classname in your HTML. `h('p', { onClick }, 'Hello!')` (or `<p onClick={onClick}>Hello</p>` in jsx) isn't more complicated than `<p class="foobar">Hello</p>` and some js elsewhere that says `$('.foobar').click(` or whatever. I've taken this approach with my very intern/jr heavy team, and they all take to it really fast. It tends to be the older devs who are more resistant, because it requires changing old habits.

was_boring 8y ago
> I don't have some `colors.scss` with a bunch of constants, and then redefine those same constants in my .js anywhere -- I have a .js file with my palette. Thank you for your reply. Do you have an example repo of using this pattern? I'm afraid I'm not terribly familiar with _not_ having any css files and instead defining it in a js file. create-react-app maintained by facebook doesn't seem to follow this pattern (unless I'm misunderstanding).
- jkoudys 8y ago
  [emotion](https://github.com/emotion-js/emotion https://github.com/emotion-js/emotion) is the main lib doing it now -- it's pretty popular among the React crowd, and sits at 5k stars right now. It's a nice, gradual transition, since it mostly follows scss-like syntax, and the docs all use tagged templates. e.g. `const className = css\`p { font-size: 16px; }\`;`, but `const className = css({ p: { fontSize: '16px' } });` works fine too. What's cool is you can use the same obj conventions for the CSS as a React component's `style` prop, or a regular Node's style. e.g. if I have `const headerColor = { color: '#ff0000', backgroundColor: '#00ff00' };`, I can say `<div style={headerColor}>`, or `Object.assign(document.querySelector('p').style, headerColor)` too.