Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: ReactCSS – Inline Styles with Support for React, Redux and React Native

reactcss.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Show HN: ReactCSS – Inline Styles with Support for React, Redux and React Native

#31

Post by zeitg3ist »

k__ wrote: post #19
zeitg3ist wrote: post #12

This is slightly off-topic, but... this simple website is made of a single, static page without any kind of user interaction. Why does it load a 2.8 Mb javascript, and why is javascript needed to render the page at all?

I only see a ~800kb bundle.js, which could be smaller if minified, I think, but nothing strangely big.

Sorry, I was looking at the uncompressed size!

While 700 Kb is sort-of-acceptable in terms of data usage, the execution of 2.8 Mb of JS is quite taxing on the browser: on my 2010 MacBook Pro it takes 4-5 seconds to show the text on the page, even when bundle.js is cached...

Re: Show HN: ReactCSS – Inline Styles with Support for React, Redux and React Native

#32

Post by qudat »

xirdstl wrote: post #18
jbob2000 wrote: post #6

Earlier quoted context omitted.

The component paradigm that react is built around is all about working with very small objects, where everything you need for that component is in one file. It's a fantastic model when you are working with a complex interface that has many components to it. It's a paradigm that needs to be managed and used carefully though, otherwise you'll end up with massive 2000 line files. I never thought there was a separation b…

Where I work, we're a small dev team of a few full stack developers and a designer. Our designer does the CSS, and the devs the JS. The separation works well enough for us. YMMV.

So anytime the designer makes a change to the structure of the application, where HTML element changes are required, do they send you a request so you can change it?

It seems odd to only allow the "designer" to manipulate properties of elements and not the elements themselves. If they are allowed to modify DOM elements then in the React world, that is manipulating JS. For us the important separation is at the component level, which includes everything that component needs to render and function (HTML, CSS, JS).

Re: Show HN: ReactCSS – Inline Styles with Support for React, Redux and React Native

#34

Post by casesandberg »

haukur wrote: post #27
casesandberg wrote: post #14

Earlier quoted context omitted.

React CSS Modules does not allow you to use props or state to style your component. Say you wanted to use a button you could map the color prop directly to CSS.

There is nothing preventing you from using (React) CSS modules & state/props. Use the allowMultiple option if you need more than one classname (base classname + modifier).

But how does that work if this translates everything to traditional CSS?

Re: Show HN: ReactCSS – Inline Styles with Support for React, Redux and React Native

#35

Post by xirdstl »

qudat wrote: post #32
xirdstl wrote: post #18

Earlier quoted context omitted.

Where I work, we're a small dev team of a few full stack developers and a designer. Our designer does the CSS, and the devs the JS. The separation works well enough for us. YMMV.

So anytime the designer makes a change to the structure of the application, where HTML element changes are required, do they send you a request so you can change it? It seems odd to only allow the "designer" to manipulate properties of elements and not the elements themselves. If they are allowed to modify DOM elements then in the React world, that is manipulating JS. For us the important separation is at the compone…

I was unclear about that part. The designer will edit the HTML also, which is outside of JS.

We are not using React.

Re: Show HN: ReactCSS – Inline Styles with Support for React, Redux and React Native

#36

Post by gedy »

natrius wrote: post #16
AndrewSB wrote: post #3

What happened to the separation of concerns between CSS and JS? In my experience most developers dont want anything to do with CSS. They want a designer who can code to do that.

The React way is different and I was hesitant, but it is better. It combines the best parts of native app development with the best parts of web development, then improves on them. The old way of doing CSS was crazy and unmanageable because CSS was intended for documents. Cascading styles are useful for publications, but they are unwieldy for UI components. There aren't many native app designers clamoring for global…

> The old way of doing CSS was crazy and unmanageable.

That's a bit of a stretch though, we've had good success with using normal CSS files, included in each component with webpack CSS-loader[1]. CSS is displayed in head as needed, but without an all-JS approach like this

[1] https://github.com/webpack/css-loader

Re: Show HN: ReactCSS – Inline Styles with Support for React, Redux and React Native

#37

Post by haukur »

casesandberg wrote: post #34
haukur wrote: post #27

Earlier quoted context omitted.

There is nothing preventing you from using (React) CSS modules & state/props. Use the allowMultiple option if you need more than one classname (base classname + modifier).

But how does that work if this translates everything to traditional CSS?

You write CSS files and import them in your component. By using Webpack you would do something like this in your component:

    import CSSModules from 'react-css-modules';
    import styles from './styles'; // This is a styles.css file in the same dir
    
    const Component = () => Hello, world!
;

    export default CSSModules(Component, styles);
The stylesheet import is just Webpack doing its thing, using css-loader. Example config: https://github.com/hph/kit/blob/master/webpack.config.js

Sorry if I misunderstood your question.

Re: Show HN: ReactCSS – Inline Styles with Support for React, Redux and React Native

#38

Post by tracker1 »

zeitg3ist wrote: post #12

This is slightly off-topic, but... this simple website is made of a single, static page without any kind of user interaction. Why does it load a 2.8 Mb javascript, and why is javascript needed to render the page at all?

First off, it's not compressed... that would probably bring it to 1/8 the size, I'm also assuming that the documentation as a project may well expand...

Usually React+Redux project min + gz will come in around 200-300KB for a relatively simple app... If you go with preact, and are really judicious in what you bring in, you can hit half that. For most people, if your initial send is under 500kb, it won't be noticed except some mobile connections.

YMMV of course, for comparison, angular apps tend to be about 50-80% bigger, and ng2 apps over twice the size. At least from my own experience and setting up a few boilerplate apps.

Re: Show HN: ReactCSS – Inline Styles with Support for React, Redux and React Native

#39

Post by tracker1 »

teleclimber wrote: post #30
k__ wrote: post #19

Earlier quoted context omitted.

I only see a ~800kb bundle.js, which could be smaller if minified, I think, but nothing strangely big.

The bundle is 2.8 Mb uncompressed, ~800Kb compressed. Even if compressed and minified, that's still a huge amount of JS statements that the interpreter has to go through. I'm getting about 2 seconds to DomContentLoaded on my iMac and a reasonably fast cable connection. Four seconds to visible content on my Nexus 5X on same connection. This is the kind of crap that makes the web feel so lame and clunky on mobile (and…

For reference, it's not necessarily react or redux, or whatever else is in use... I've managed to get preact+redux in a 20k (gz) bundle for a standalone, usable component, flushing out an app may triple that size, but if you're judicious with your components, it's not too hard.

Then again, Immutable.js is about 15kb on it's own, and a few other heavy hitters and you'll hit 100kb (gz) load before much functionality. That said, I think a 500kb target for a web app isn't too bad, this does exceed that, but not sure if certain bits (image references, fonts, etc) are part of the actual JS bundle, which will bloat it out a lot.

Re: Show HN: ReactCSS – Inline Styles with Support for React, Redux and React Native

#40

Post by tracker1 »

gedy wrote: post #36
natrius wrote: post #16

Earlier quoted context omitted.

The React way is different and I was hesitant, but it is better. It combines the best parts of native app development with the best parts of web development, then improves on them. The old way of doing CSS was crazy and unmanageable because CSS was intended for documents. Cascading styles are useful for publications, but they are unwieldy for UI components. There aren't many native app designers clamoring for global…

> The old way of doing CSS was crazy and unmanageable. That's a bit of a stretch though, we've had good success with using normal CSS files, included in each component with webpack CSS-loader[1]. CSS is displayed in head as needed, but without an all-JS approach like this [1] https://github.com/webpack/css-loader

For that matter, it's not so hard to setup sass-loader with custom default locations... I'll usually have my own copy of bootstrap's variables.scss, a mixins.scss that points to bootstrap's... from there, I have a copy of bootstrap.scss included higher up pointing to the local mixins/variables, and the rest from the node_modules/bootstrap(-sass)/ path...

I can then, inside my component...

    require('./mycomponent-style.scss')
    ....
with the mycomponent-style.scss

    @import "variables";
    @import "mixins";
    
    .mycomponent {
      ...
    }
And have all of bootstrap's variables/mixins to work with... I can update variables for those bits of bootstrap I want changed, components also update based on those values. It actually works really well, and it's not hard to setup.

I should really write a current article on using Bootstrap@4 from source... There's a little bit of boilerplate, but so worth it.

That said, I do appreciate the inline options, and feel that future React apps in particular should probably go in that direction. It really just depends on how you are working with.

Post reply on HN