Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »

prom candy: Dec 16, 2005; Only I may dance

I use flexbox all the time but I wouldn't write

code:

<div class="ui grid outer">
  <div class="ui columns four">An image</div>
  <div class="ui columns eight">Some info</div>
</div>

I would write

code:

<div class="article">
  <div class="article__image">An image</div>
  <div class="article__info">Some info</div>
</div>

# ? Jul 21, 2017 00:54

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 10:57

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Yeah, composition in the HTML classes is a bit of a disaster for maintainability. Unless it's ridiculously well documented you're gonna have a bad time targeting your changes we'll, and even then because the HTML could be doing all sorts of composition it's easy to do it wrong. Compare that to a reasonably disciplined BEM implementation and I almost guarantee you can make a tight well targeted change with minimal side effects, often without touching HTML.

# ? Jul 21, 2017 01:22

luchadornado: Oct 7, 2004; A boombox is not a toy!

Thermopyle posted:

I think I know what you're saying but this is probably the first time I've heard Java called 'terse'!

No, you're totally right - I have no idea why that was the word I typed (although I like how Vessi kind of made it work). I was probably thinking "verbose" and just brain-farted.

# ? Jul 21, 2017 01:53

HaB: Jan 5, 2001; What are the odds?

prom candy posted:

Your class names should describe what something is, not how it looks. When you have to make changes across lots of different areas of a site it makes it really difficult if everything has a ton of class names, and even more so when it's hard to tell which class names are related to which larger overall concept.

In my experience, systems like BEM are way better for creating CSS that scales. Your HTML says what things are, your CSS determines how they look.

So I had to look up the term BEM as I was reading replies in this thread. I have seen that implementation before - just never heard the term applied to it. After reading about it and the reasons why people are using it, I'm just about convinced it's the worst thing ever.

So the bolded part of your statement is the fundamental belief on which I *completely* disagree with you.

Describing how things look is EXACTLY what CSS is for, in my opinion. HTML = structure, Code = behavior, CSS = visuals.

BEM is what I would call "snowflake style hell" . I don't want unique selectors for everything. To me, that is missing almost the entire point, particularly if someone in your organization was nice enough to create a style/pattern guide.

BEM looks like it is ugly to write and super ugly to read. If you are looking at a list of users and need a class name of users-table__row to tell you which element is a row in the users table - then I'm not sure what to tell you. If my UX designer spent many hours standardizing what a table is supposed to look like, then I will style the table element and any of its child elements and use that everywhere. Snowflake style should be the extreme exception not the rule, and for that I can use an id in the way it was intended (SINGLE use) or poo poo - namespace the CSS for that particular block.

Even easier now since I am currently using Angular 2 which can namespace styles by component anyway.

prom candy posted:

I use flexbox all the time but I wouldn't write

code:

<div class="ui grid outer">
  <div class="ui columns four">An image</div>
  <div class="ui columns eight">Some info</div>
</div>

I would write

code:

<div class="article">
  <div class="article__image">An image</div>
  <div class="article__info">Some info</div>
</div>

Your example here is somewhat contrived. Your first block isn't semantic in the same way semantic-ui is asking you to be. More accurate would be:

code:

// I know I am looking at a grid which SHOULD be standard across my app 
// except in very few corner cases . "outer" from your example isn't providing any meaningful info
<div class="ui grid">                      
    <div class="eight wide column"> // I know this column is 8 units wide
    <div class="four wide column">  // I know this column is 4 units wide.

Or the other way semantic can do it for contrast:

code:

<div class="ui grid eight columns"> // this grid will have 8 columns
	<div class="column">
	.... repeat 7 more times...

In your second block, how is that superior to:

code:

<div class="article">
  <div class="image">
  <div class="info"

? In both cases I can see that I have an article with a nested image and a nested info inside. You BEM example hasn't given me any more information than I had, and created two snowflake classes.

prom candy posted:

We had a developer who did all that stuff too, and it was me. This is all stuff that seems like a really great idea until you have to scale it or maintain it.

Maluco Marinero posted:

Yeah, composition in the HTML classes is a bit of a disaster for maintainability. Unless it's ridiculously well documented you're gonna have a bad time targeting your changes we'll, and even then because the HTML could be doing all sorts of composition it's easy to do it wrong. Compare that to a reasonably disciplined BEM implementation and I almost guarantee you can make a tight well targeted change with minimal side effects, often without touching HTML.

I wouldn't really call that composition. The structure of the markup isn't being changed by the application of semantic styles. Is it telling me what elements my widget/component is made of and what standard styles are being applied to them? Yes. Is it structuring the component based on CSS? No. Again, to me: HTML = structure, CSS = visuals.

Can someone provide a real-world example in which this was hard to maintain? It seems pretty simple to me. If I want to add a column to my grid, I find the grid div and change class "eight" to "nine". Particularly now in a component based architecture. I'm wondering what kind of markup you guys are writing where something like this would suddenly become a maintenance nightmare.

I should note that I was a little startled at my own strong reaction when I looked up what BEM was and realized you guys are pitching it as some kind of best practice, as opposed to the snowflake nightmare is looks like to me. After a night of sleeping on it, I'm not emotional about it anymore, but I am genuinely curious as to why BEM is a better idea. I can agree that this:

geeves posted:

code:

<button class="btn lrg org left"/>

is awful, but again - that's not what semantic is doing. The more semantic approach would be:

code:

<button class="large left aligned button"/> . // I have no idea what 'org' is in your example.

If you glanced at it and thought the first example is what it wants - I did the same at first. But after literally building a site with it, it seems like a sound approach. I wrote a fairly simple (8-9 components) site with it, and wound up with about 20 lines of custom CSS, and the rest is via semantic and its theme. So I am eager to hear why that's a bad thing. And particularly eager to hear someone explain how BEM isn't the nightmare I think it is.

HaB fucked around with this message at 12:51 on Jul 21, 2017

# ? Jul 21, 2017 12:47

Tei: Feb 19, 2011; Can't post for 4 days!

I don't want to talk too strong, this is not my area of expertise, and I always feel very bad when I said something that end being wrong (and it happens often)

But if somebody is doing

code:

<div  class="red"> food </div>

Please stop. Look at the past

code:

<font color="red">food</font>

You are not much better.

code:

<div  class="intense"> food </div>

This is a bit better

code:

<div  class="food-item intense"> food </div>

Even better.

foot-item, is semantic. One day in the future we will do something with the semantic web, we need to work for that day.

intense. unopinionable. intense can be red, but maybe can be bold, maybe it blinks, maybe reads loud in a voice reader.

code:

<button class="large left aligned button"/>

why not this:

code:

<div class="toolbar top-toolbar ">
 <button class="button-large button-save" />
</div>

let the designers choose if all top-toolbars are left or right or center or whatever. maybe instead of button-large, button-important

you have a large website with many pages, and you want to put all the buttons in toolbars to the center. what you do? edit a CSS file, or swim in a loot of template files hunting for left next to button in the right context.

we created CSS so a designer can change a website without having to change the html. has much has possible, has much as it make sense.

Tei fucked around with this message at 13:20 on Jul 21, 2017

# ? Jul 21, 2017 13:08

HaB: Jan 5, 2001; What are the odds?

Tei posted:

code:
<button class="large left aligned button"/> 
why not this:
code:
<div class="toolbar top-toolbar ">
 <button class="button-large button-save" />
</div>
let the designers choose if all top-toolbars are left or right or center or whatever. maybe instead of button-large, button-important

you have a large website with many pages, and you want to put all the buttons in toolbars to the center. what you do? edit a CSS file, or swim in a loot of template files hunting for left next to button in the right context.

we created CSS so a designer can change a website without having to change the html. has much has possible, has much as it make sense.

Totally agree with the class="red" example. If someone decides later that we want to display errors in Orange because Red focus-tested as "too aggressive" then yes.

quote:

you have a large website with many pages, and you want to put all the buttons in toolbars to the center. what you do? edit a CSS file, or swim in a loot of template files hunting for left next to button in the right context.

Now THIS is an example I understand. I can see where that would be an issue. Perhaps because the last 7-8 years of my career has been spent working at large corporations which all move at such a glacial pace that a broad sweeping style change like that wouldn't come down without an act of Congress. And a designer changing production css? LOL. no.

So I am sitting here watching talks about it and reading about BEM, because I am really trying to understand. But I still keep thinking that the problem it is solving is nearly non-existent in a Component-based architecture.

# ? Jul 21, 2017 13:36

prom candy: Dec 16, 2005; Only I may dance

Maybe we just work on different projects. Over the past 12 years or so I've build hundreds of websites, many small, some massive. In an agency setting, the number one rule when developing any kind of software is that business requirements WILL change. You rag on "snowflake styles" as if no designer has ever said "hey I need the third article on the home page to be different than everything else."

BEM class names are pretty ugly, it's true, but they also convey a ton of meaning. The beautiful thing about having a div like "article__image" is you know exactly what it is, where it belongs, where to find it in your CSS, and what CSS rules are affecting its design. If you rely on using class composition to style things you can end up with conflicting styles (the classic "why is this text red" problem.) If I go into a project and I need to edit styles for .article_image, I open _article.scss and everything I need to know is right there. I can confidently change _article.scss and know that I'm not going to affect some other component.

In terms of repetition, this is solved easily using mixins or extensions with SASS, or whatever your preferred CSS preprocessor is.

code:

.article {
  padding: $spacing-sm;

  @include breakpoint($medium) {
    @include grid-container;
  }
}

.article__image {
  width: 100%;
  margin-bottom: $spacing-md;

  @include breakpoint($medium) {
    @include grid-columns-4;
    margin-bottom: 0;
  }
}

.article__info {
  width: 100%;
  
  @include breakpoint($medium) {
    @include grid-columns-8;
  }
}

Now if I have articles littered throughout my code base and I want to change them to be 5 and 7 columns, or I don't want them to break into a grid until the $large breakpoint, I only have to edit one file, and I can do so confidently knowing I'm only affecting instances of article. If I used your case of calling my subclasses just "image" and "info" how do I make targeted changes if I don't want to also affect other, non-article places where I want to use the "image" class? A bunch of nesting? Nooo thank you, that becomes hard to read and hard to find really fast. If I truly have a global "image" then it can become its own block:

code:

<div class="article">
  <div class="article__image">
    <div class="image">
    </div>
  </div>
</div>

This might seem gross to you, but the important thing is when another developer is onboarded or I come back to this project after working on other stuff for a year it's instantly obvious what's going on. "article" is a block and all of its styles can be found in _article.scss. "article__image" is responsible for positioning "image" within an article block. "image" is its own global block that's used elsewhere in the site, and its styles can be found in _image.scss.

In your example you have classes like "eight wide column" and "four wide column." What happens when you need to radically alter the presentation depending on the size of the device the user is using? In my article example it's easy for me to say, okay on mobile-ish sizes the image and the info stack on top of one another, on a small tablet maybe we go 50/50, and then everything up from there is 30/70. Your HTML class composition is declaring how it looks, not what it is. In a world of RWD that's not really great unless you're okay with your grid ALWAYS changing in the exact same way, at the exact same breakpoints. My designers are not okay with that. So then what's the class composition solution? "eight wide column sm-six md-ten"? Ack!

If you've never maintained CSS on a huge website, never had to make changes to a project that you weren't the original developer on, or generally don't deal with these kinds of problems I can see how BEM would seem insane to you, but for us it's been an absolutely massive leap in productivity and maintenance.

# ? Jul 21, 2017 14:12

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

prom candy posted:

If you've never maintained CSS on a huge website, never had to make changes to a project that you weren't the original developer on, or generally don't deal with these kinds of problems I can see how BEM would seem insane to you, but for us it's been an absolutely massive leap in productivity and maintenance.

Yeah, there are some fundamental elements to BEM that makes it PERFECT for component based development. It's been an incredible boon for our site development. Snowflake styles are actually really great. By defining what things are it makes it way way way easier to target the snowflake design requirements without loving up the design system.

Bloat in CSS doesn't matter, often gzip will remove all that extra text. Bloat in style names doesn't matter, usually gzip will remove all that extra text.

Consider this site:

https://australianbabywearingcollective.com.au/

Everything is named based on it's place in the world. In our code we can build up markup with components, and know that the CSS perfectly maps to these components (my biz partner is a fan of jade so I wrote a jade to React transformer, but it should be relatively easy to follow this if you remember indentation denotes containment. All the cx calls replace & with our component name, in this case HomeTemplate.

code:

  return rj`
      +StandardLayout(this.props)
        main(class=cx(classes))
          +HomeCarousel(opening_slideshow)
          section(class=cx('&__introduction'))
            h1(class=cx('&__introductionTitle'))= introduction.title
            +Richtext(class=cx('&__introductionBody') bigOpeningPara=true)
              = blockLayouts(introduction.body)
            if introduction.link && introduction.cta
              div(class=cx('&__introductionCta'))
                +SplashButton(
                  href=introduction.link
                )= introduction.cta
          if featured_event
            +EventSplash(
              class=cx('&__featuredEvent')
            )&attributes(featured_event)
          if events.length > 0
            section(class=cx('&__upcomingEvents'))
              header(class=cx('&__upcomingEventsHeader'))
                +Measure
                  h2(class=cx('&__upcomingEventsHeaderText'))= "Upcoming Events"
              for event in events
                +EventPreview(
                  class=cx('&__eventPreview')
                  key=event.slug
                )&attributes(event)
          if associations.associations.length > 0
            +AssociationsTicker(associations)
    `

It becomes easy to see what styles are specific to this template, and what belongs to child components. In addition we have little rules we try to follow, for example components MAY NOT have margins. That way they will all block together naturally, and that means parents can see fit to add in padding and spacing if necessary.

This way we can build out pretty much any 'snowflake' design with 100% confidence in our ability to address edge cases without screwing up our primary design system. Classes are very exact targets as long as you don't combine them, selector depth and relying on specificity is the enemy of most attempts to create a decent CSS design system, and BEM does a great job of keeping the selector depth and specificity flat.

And if you think it takes a lot of effort to build like this, I'd just flat out disagree. We've built towards a component approach that leverages React and straightforward BEM for everything we do, and it's allowed us to punch wayyy above our weight in comparison to the budgets we work on, and deliver them largely on the money in terms of our estimates. BEM is our safe boring predictable choice that allows us to respond to change requests with a 'no problem' rather than a 'errrr'.

# ? Jul 21, 2017 15:14

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

One thing with BEM, what's with the double underscores? Like why is that a thing?

# ? Jul 21, 2017 15:27

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Kobayashi posted:

One thing with BEM, what's with the double underscores? Like why is that a thing?

ComponentName__elementofcomponent

ComponentName--modifierOfComponent

Essentially what the underscores mean is this thing belongs inside ComponentName.

# ? Jul 21, 2017 15:35

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

But I mean, why two dashes/underscores instead of one? I'm a designer so I look at that, find it to be aesthetically displeasing, and wanna know why.

# ? Jul 21, 2017 15:38

Tei: Feb 19, 2011; Can't post for 4 days!

Kobayashi posted:

But I mean, why two dashes/underscores instead of one? I'm a designer so I look at that, find it to be aesthetically displeasing, and wanna know why.

Have you seen something like this: ?

"name-customer_name"

It make sense for some people, It reads like "this is name, and it comes from a database field that is named customer_name"

another way to write it would be:

name__customer_name

I think the "__" just mean "I am using _ has a meta character, not as a actual _".

# ? Jul 21, 2017 15:42

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Kobayashi posted:

But I mean, why two dashes/underscores instead of one? I'm a designer so I look at that, find it to be aesthetically displeasing, and wanna know why.

Because some people use single underscore or dash instead of camel case in naming things, so the double underscore is to differentiate things like:

code:

element-name--modifier

block_name__element

# ? Jul 21, 2017 15:42

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Kobayashi posted:

But I mean, why two dashes/underscores instead of one? I'm a designer so I look at that, find it to be aesthetically displeasing, and wanna know why.

It's just the convention, I imagine to play nice with certain people who use single underscore spacing in the naming. I guess it doesn't really defend why WE do it, cause clearly we're using camel or just capitalisation, but honestly it never bothers me. I guess I don't care about the aesthetics of HTML, cause HTML is hardly aesthetic in its final state.

# ? Jul 21, 2017 15:45

Gildiss: Aug 24, 2010; Grimey Drawer

I will be moving into a position where I am the only web dev at this company working with the backend consisting of the head programmer, making the web version of their already existing Android and iOS apps.

Real rear end green field project, aside from the fact they want it in React.

What is the wish list of things you would do given this situation for a React project?

# ? Jul 21, 2017 16:09

HaB: Jan 5, 2001; What are the odds?

prom candy posted:

Maybe we just work on different projects. Over the past 12 years or so I've build hundreds of websites, many small, some massive. In an agency setting, the number one rule when developing any kind of software is that business requirements WILL change. You rag on "snowflake styles" as if no designer has ever said "hey I need the third article on the home page to be different than everything else."

If you've never maintained CSS on a huge website, never had to make changes to a project that you weren't the original developer on, or generally don't deal with these kinds of problems I can see how BEM would seem insane to you, but for us it's been an absolutely massive leap in productivity and maintenance.

I think the bolded part is all which needs to be said. After the last 18 years I have done all of that as well, and have yet to run into a problem which would be solved by literally giving every element a unique class name. In fact, I can only think of ways that would just compound the problems i have seen.

quote:

In your example you have classes like "eight wide column" and "four wide column." What happens when you need to radically alter the presentation depending on the size of the device the user is using? In my article example it's easy for me to say, okay on mobile-ish sizes the image and the info stack on top of one another, on a small tablet maybe we go 50/50, and then everything up from there is 30/70. Your HTML class composition is declaring how it looks, not what it is. In a world of RWD that's not really great unless you're okay with your grid ALWAYS changing in the exact same way, at the exact same breakpoints. My designers are not okay with that. So then what's the class composition solution? "eight wide column sm-six md-ten"? Ack!

See I think here is the problem. First - they aren't my examples. You guys are assuming I made up a semantic styling framework from scratch. I simply posted a trip report on my experience with it, and you guys are telling me how bad it is without ever trying it. It has solutions for the example you are giving above already. Are they super opinionated solutions? Of course they are. I mentioned it's a super opinionated framework. You are thinking it's like bootstrap with it's .col-xs-6 crap and it's not. At all. One solution offered for the problem you mentioned would be something like (and I am spitballing, because I haven't used it to style for mobile):

code:

<div class="ui grid mobile only">
.. layout your mobile grid here ...
</div>

<div class="ui grid computer only">
... layout the desktop one here ...
</div>

It also offers a few stacking/doubling classes for adding different behaviors for columns/cards/containers based on screen size.

A badly implemented semantic solution or really ANY badly implemented solution is just that - bad. Theirs seems pretty good. Opinionated af, but good.

BEM seems to be solving a problem I have yet to encounter. Maybe I'm a unicorn.

# ? Jul 21, 2017 16:10

PlaneGuy: Mar 28, 2001; g e r m a n
e n g i n e e r i n g; Yam Slacker

HaB posted:

BEM seems to be solving a problem I have yet to encounter. Maybe I'm a unicorn.

Nah, you're no unicorn. You've probably encountered it, but your inherent programmer sense avoided it. I don't think I've been in that pickle since university when I was learning how to deal with the cascading part of css. I do a lot on component stuff now and I guess it's "BEM" but it ends up looking old-school because I think the block__element--modifier naming convention is stupid and dumb and ugly.

code:

.block .element .modifier {color:blue;}
/* or if you like typing things over and over again */
.block.element.modifier {color:blue;}

# ? Jul 21, 2017 17:31

prom candy: Dec 16, 2005; Only I may dance

The reason I like block__element--modifier is because it's a janky way to manage namespacing. I think all this goes away when whatever CSS in JS solution comes out as the clear winner but for now if you have ".article.image" and ".profile.image" there's a risk of editing the styles for .article > .image and accidentally changing .profile > .image in the process. I would rather write longer class names than deal with ambiguity.

# ? Jul 21, 2017 18:43

Tivac: Feb 18, 2003; No matter how things may seem to change, never forget who you are

I've been using CSS Modules (via modular-css) to avoid all of that. When optimized for production things end up looking pretty wild

code:

<div class="BC HA">
    <div class="HB">
        <h3 class="BA BD HC">
            <p class="HD HF">Game Innovation</p>
            <p class="HD HE HG">Industry Leading Art</p>
            <p class="HD HE HH">Professional Growth</p>
        </h3>

but during dev doing class composition via composes within the CSS is awesome, as is the automatic module-level selector scoping. It's really removed a lot of the pain I used to deal with around CSS cascading and composition. A nice side benefit is that it does away w/ the need for BEM-style insane-looking selectors.

# ? Jul 21, 2017 19:18

spacebard: Jan 1, 2007; Football~

There are two reasons to use BEM:

1. Improved specificity without any loss of performance that large sites fall into with wildly inefficient selectors. IDs would be better selectors, but you just know you're going to gently caress yourself in the future on a large site for some snowflake page.
2. Semantically naming selectors (Markup and selectors = structure) so that the CSS definitions describe the design (CSS styles = visuals).

That said, I'm currently working on an Angular app using component-based architecture with a design where we can just utilize Bootstrap 4. The "consultant" opted to heavily rely on IDs and the team lead prefers camel case :bang:

which is annoying to type and imo harder to read than BEM or anything loving else. Luckily the design isn't anything fancy so we won't need to rely on nested specificity hell (yet).

# ? Jul 21, 2017 22:53

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

The flat specificity is a big one for me. The knowledge that bear every single selector is single class level:

.Component
.Component__elementOne
.Component__elementTwo

...is very dependable for not stepping on one another's toes. Far more that:

.component .element

CSS modules came across as an interesting idea, but not one that solves enough problems for me to consider tying my style authoring to my JavaScript authoring in the highly dependant way it does.

# ? Jul 21, 2017 23:09

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Anyone used redux-first-router?

I just stumbled across it and I like what I read about it, but I'm not smart enough to be able to tell if a library is good just by reading about it...I usually have to really use it a couple times.

quote:

Motivation - What Routing in Redux is Meant To Be

To automate routing. To be able to use Redux as is while keeping the URL in the address bar in sync. To think solely in terms of "state" and NOT routes, paths, route matching components. And of course for server side rendering to require no more than dispatching on the store like normal. Path params are just action payloads, and action types demarcate a certain kind of path. That is what routing in Redux is meant to be.

In practice, what that means is having the address bar update in response to actions and bi-directionally having actions dispatched in response to address bar changes, such as via the browser back/forward buttons. The "bi-directional" aspect is embodied in the diagram above where the first blue arrows points both ways--i.e. dispatching actions changes the address bar, and changes to the address bar dispatches actions.

# ? Jul 24, 2017 15:18

Ahz: Jun 17, 2001; PUT MY CART BACK? I'M BETTER THAN THAT AND YOU! WHERE IS MY BUTLER?!

Thermopyle posted:

Anyone used redux-first-router?

I just stumbled across it and I like what I read about it, but I'm not smart enough to be able to tell if a library is good just by reading about it...I usually have to really use it a couple times.

I am integrating it into a project after reading everything I could about it. It seems like the real deal, my main concern was future support, but this guy seems pretty dedicated to the idea and his JS chops are pretty good.

Worth a try to avoid coupling to a router based architecture.

# ? Jul 24, 2017 15:49

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Thermopyle posted:

Anyone used redux-first-router?

I just stumbled across it and I like what I read about it, but I'm not smart enough to be able to tell if a library is good just by reading about it...I usually have to really use it a couple times.

Ahz posted:

I am integrating it into a project after reading everything I could about it. It seems like the real deal, my main concern was future support, but this guy seems pretty dedicated to the idea and his JS chops are pretty good.

Worth a try to avoid coupling to a router based architecture.

Just when I was about to try React Router 4.0 for the first time!!!

This does look super sweet. I think.

# ? Jul 24, 2017 16:42

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Lumpy posted:

Just when I was about to try {{framework version+1}} for the first time!!!

{{alternative framework}} This does look super sweet. I think.

Anyone want to help me with what I posted earlier about Webpack?
Or should I just wait 5minutes for Webpack 4/ Some other-totally-better-than-Webpack.js to come out?

# ? Jul 24, 2017 20:31

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Some other-totally-better-than-Webpack.js: https://rollupjs.org/

Simply bundles javascript es2015 imports, simply. It's like abreath of fresh air. I get to just build websites again, I never needed a built-in development environment / giant config files / compiled html. Just bundle the god drat imports into one file so I can program using modules and use them.

# ? Jul 24, 2017 21:16

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

rollupjs isn't better than webpack. It is a tool for a different purpose, though webpack can also do what rollup does just as simply. You may think it's more complex only because the docs don't say "do this and this to use webpack just like rollup".

Don't take this as a criticism of rollup, it's a good and fine tool, but comparing it to webpack by saying rollup is simpler is a little misleading.

# ? Jul 24, 2017 22:17

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

The only important thing Webpack does, serves the same purpose as Rollup. Webpack is a monolithic bloated mess that tries to do 1000 different things I don't want. I suppose other people do want that, and in that case I can see what you mean that they aren't the same tool.

For me they're the same tool.

# ? Jul 24, 2017 22:39

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Nolgthorn posted:

The only important thing Webpack does, serves the same purpose as Rollup. Webpack is a monolithic bloated mess that tries to do 1000 different things I don't want. I suppose other people do want that, and in that case I can see what you mean that they aren't the same tool.

For me they're the same tool.

Yes, if you only want to do the one thing rollup does, then rollup is a good solution for that. Just to be clear, webpack does the same thing with basically the same amount of configuration.

# ? Jul 24, 2017 23:52

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Nolgthorn posted:

Some other-totally-better-than-Webpack.js: https://rollupjs.org/

Simply bundles javascript es2015 imports, simply. It's like abreath of fresh air. I get to just build websites again, I never needed a built-in development environment / giant config files / compiled html. Just bundle the god drat imports into one file so I can program using modules and use them.

So what should I use for all the other stuff I use Webpack for?

# ? Jul 25, 2017 01:58

prom candy: Dec 16, 2005; Only I may dance

Grunt

# ? Jul 25, 2017 05:06

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

prom candy posted:

Grunt

Grunt -> Gulp -> Webpack -> Rollup -> Grunt

# ? Jul 25, 2017 05:19

Tivac: Feb 18, 2003; No matter how things may seem to change, never forget who you are

I wish webpack output was as nice as rollup output, but webpack definitely handles a boatload of other stuff.

Even with the scope-hoisting plugin webpack's output is ugly.

# ? Jul 25, 2017 07:31

luchadornado: Oct 7, 2004; A boombox is not a toy!

Lumpy posted:

So what should I use for all the other stuff I use Webpack for?

Delegate it to someone else and work on actual business problems that make money.

# ? Jul 25, 2017 12:50

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

So the fact that the documentation tutorial on Webpack's site is broken is fine because I shouldn't use Webpack anyway
:thunk:

# ? Jul 25, 2017 13:33

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Helicity posted:

Delegate it to someone else and work on actual business problems that make money.

But I'm the only person at work, and setting up Webpack takes about 20 seconds.... I'm so confused now.

# ? Jul 25, 2017 18:59

darthbob88: Oct 13, 2011; YOSPOS

I'm just getting started with React, and for the most part it seems pretty cool, but I'm having trouble once I start moving beyond a toy mockup. Specifically, how can I assign complex types to React components? <Component FooProp={[1, 2, 3]} /> works fine, but when I try to do <Component FooProp={ObjectWithMultipleFields} /> it insists that I assign one prop for each of those fields. Is there a better way to do this, or do I just have to keep my objects nice and simple?

# ? Jul 25, 2017 20:37

reversefungi: Nov 27, 2003; Master of the high hat!

darthbob88 posted:

I'm just getting started with React, and for the most part it seems pretty cool, but I'm having trouble once I start moving beyond a toy mockup. Specifically, how can I assign complex types to React components? <Component FooProp={[1, 2, 3]} /> works fine, but when I try to do <Component FooProp={ObjectWithMultipleFields} /> it insists that I assign one prop for each of those fields. Is there a better way to do this, or do I just have to keep my objects nice and simple?

You should be able to pass it in like anything else. Can you give an example of what you're trying to do? Maybe you're just simply not calling/destructuring/passing it in properly

If we're inside the render function of a class based component, here's what you might do

JavaScript code:

render() {

	const complexThing = {
    		foo: "bar",
    		baz: "biz"
	}
	
	return (
		<div>
			<SomeComponent thing={complexThing} />
		</div>
	)

Then inside the component itself you'd have something like this:

JavaScript code:

const SomeComponent = ({thing}) => {
	return (
		<div>
			<h1>{thing.foo}</h1>
			<h2>{thing.baz}</h2>
		</div>
	)
}

# ? Jul 25, 2017 21:19

darthbob88: Oct 13, 2011; YOSPOS

The Dark Wind posted:

You should be able to pass it in like anything else. Can you give an example of what you're trying to do? Maybe you're just simply not calling/destructuring/passing it in properly

If we're inside the render function of a class based component, here's what you might do.

That's more or less what I'm trying to do. After looking elsewhere, it looks like half the problem might be that I'm trying to do this with Typescript, and not just vanilla JS. I have, massively stripped down-

code:

export interface Question {
	Text: string;
	Required: boolean;
	QuestionId: string;
	Options: string[];
}

export interface QuestionList {
	questionList: Question[];
}

export class QuestionField extends React.Component<QuestionList, NewQuestion> {
render() {
		return <div className="LargeQuestionField">
			<div className="RequiredQuestions">
				{this.props.questionList.map(question =>
					<QuestionsBox item={question} key={question.QuestionId}
Options={question.Options} Text={question.Text} Required={question.Required} 
					QuestionId={question.QuestionId} />
				)}
			</div>
		</div>;
	}
}
export class QuestionsBox extends React.Component<Question, NewQuestion> {
//Render a box for each question.
}

When I try to do simple <QuestionsBox question={question} />, Typescript flips its lid because it can't find property Text in that props dictionary. I think the problem is that I'm declaring QuestionsBox will take a props object which satisfies the Question interface, so I need to explicitly provide all of those properties when I call that component.

darthbob88 fucked around with this message at 22:09 on Jul 25, 2017

# ? Jul 25, 2017 21:58

Adbot: ADBOT LOVES YOU

# ? Jun 6, 2024 10:57

luchadornado: Oct 7, 2004; A boombox is not a toy!

Lumpy posted:

But I'm the only person at work, and setting up Webpack takes about 20 seconds.... I'm so confused now.

You're being flippant, but I've seen a team of smart front-end devs sink dozens of hours into upgrading from Webpack 1 to 2 and breaking up a monolith into 12 web apps. Dealing with Webpack and build processes is a huge time sink to a degree I haven't seen in large multi-developer projects written in Python, .NET, or Java.

"Webpack is easy it just bundles my JS" is valid, but it's trying to be much more than a JS bundler and once you start using complex configs and a myriad of plugins it's easy to enter Webpack Hell. More and more devs seem to believe the idiomatic way is on the Hell path.

# ? Jul 26, 2017 02:01

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »