7 ms·

This is how I coach my team through this: use the right tools for the job. Now what does that mean? Just displaying some data and accepting some input, or requ

This is how I coach my team through this: use the right tools for the job. Now what does that mean? Just displaying some data and accepting some input, or requirements are unclear? No js required. Now they want some interaction, like a hover effect? Use vanilla js, jQuery, or plain css. Requirements keep changing and you have more the 25 lines of js? Maybe start thinking about vuejs to enhance the page and using a simple script tag. Starting to have several hundred lines of js and you can't remember where in the file that function is, or you are required to minify? Start thinking of vuejs plus a build tool. Do you need js everywhere? The answer is almost certainly no. Do you need to enhance a page with js? That's about a 50/50. Obviously this is just my advice, but was born from working on small teams, at startups where requirements are often unknown, change frequently, and time to market matters.

jkoudys 8y ago
Plenty who will disagree and say they do want JS everywhere. I can build my dom much more cleanly using nice declarative js than html with all its silly and inconsistent rules, and letting react do the rest. I'm happier writing my style rules as objects, then having emotion apply it to style elements. Much happier using JS for everything than some old html+CSS that uses JS to add a few bells and whistles.
- dagoat 8y ago
  > html with all its silly and inconsistent rules Can’t the same be said of js? > old html+CSS What’s wrong with html & css being old?
  - jkoudys 8y ago
    Nothing wrong, it's just a more common tradition. JS used purely as a declarative language is actually remarkably consistent. And if you have inconsistencies, I'd rather have the same inconsistencies than have 3 different languages to worry about.
- was_boring 8y ago
  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.

jkoudys 8y ago

Plenty who will disagree and say they do want JS everywhere. I can build my dom much more cleanly using nice declarative js than html with all its silly and inconsistent rules, and letting react do the rest. I'm happier writing my style rules as objects, then having emotion apply it to style elements. Much happier using JS for everything than some old html+CSS that uses JS to add a few bells and whistles.

dagoat 8y ago
> html with all its silly and inconsistent rules Can’t the same be said of js? > old html+CSS What’s wrong with html & css being old?
- jkoudys 8y ago
  Nothing wrong, it's just a more common tradition. JS used purely as a declarative language is actually remarkably consistent. And if you have inconsistencies, I'd rather have the same inconsistencies than have 3 different languages to worry about.
was_boring 8y ago
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.