7 ms·

The downside to that is that I've seen a lot of old school frontenders who 5-7 years ago were able to just dus html/css and sass haven't been able to keep up, i

by toshk 6y ago

The downside to that is that I've seen a lot of old school frontenders who 5-7 years ago were able to just dus html/css and sass haven't been able to keep up, it just got too complex. In that regard the old situation had better seperation of concerns.

Swizec 6y ago
In my experience that separation of concerns was fake. 15+ years of webdev and I ain’t ever seen a redesign that doesn’t fundamentally change the layout and business logic. Never seen a spec update to logic that doesn’t also change how things look. The coupling is super tight and always has been.
- toshk 6y ago
  I meant more in the sense that different people could do different jobs. Non-developers/designers were able to do a lot of the frontend stuff. With the "new" complexity of frontend development that's mostly gone. I've seen it a few times with my own eyes that in teams the 1-5 frontenders specialised in html/css had a really hard time switching to react, at the same time more seasoned developers felt like fish in the water. Considering the scarcity of developers that's actual a big deal, more work for developers while at the same time less work for traditional frontenders.
  - Swizec 6y ago
    In my experience those different people couldn’t do different jobs. Designers could write css, but I hd to set up magic id/class incantations for them. They could write html, but changes kept breaking business logic. Css zen gardens was a fantastic idea that I’ve never seen realized in a real project with business needs. Maybe I’ve just been unlucky.
    - toshk 6y ago
      I've seen few organisations where there was a group of frontenders specialised in html/css. Even integrated in continious development. It's a fine line, but with backbone.js and sass they could manage, but with react and postcss the line between templates and logic disappeared. But it's less specific then that. When 6 years ago hiring a frontender they needed to just know html and css, now they need to be full blown devs.
  - dgb23 6y ago
    I’m currently training/mentoring a designer in using React, Tailwind, Markdown and basic CLI tooling (git and yarn). She appreciates the power and expression shes given and is learning quickly and steadily. No prior coding knowledge. Most of this comes down to getting past the fear of coding/programming. And it is a powerful enabler, even reshapes thinking. She recently came up to me with saying “why should I write this in Word? We have markdown and I bet there is a tool where I can style this and generate a PDF”.
    - toshk 6y ago
      Some people just get development. I had one close person who was able to learn webdev and become and highly skilled freelance developer in 0.5 to 1.5 year (having played with computers his whole life), I had another friend who after 3 to 4 years still struggles to do a simple loop, let alone grasp a recursive function, at the same time he makes great designs and has good skills to implement them frontend wise. Different minds, different talents.
    - rimliu 6y ago
      That's really the main reason React got popular. Somehow it lets the people who do not know what they are doing get by. At the expense of the users.
      - dgb23 6y ago
        Mind you in my case the designer just really does JSX templating with it and styling. The wiring, plumbing, state and so on is not her business. The reason I use React is mostly its composable, simple templating abstraction and the fact that it works both on the server and the client. UX is generally improved. If a site/app is done well, it will work w/o JS enabled, loads fast and transitions even faster. JS typically makes things better, not worse. What makes sites slow is putting in external and/or heavyweight stuff: ads, analytics, tracking, fonts, images and so on.
  - hombre_fatal 6y ago
    >Non-developers/designers were able to do a lot of the frontend stuff. This always smells like "nobody could possibly do what we do" developer hubris. The designers I've worked with on my last three large React projects could edit .jsx/.scss files. I don't really buy the idea that someone can learn web client design but it's jsx or whatever that's too much.
  - tln 6y ago
    FWIW enabling designers is one reason I like Vue a lot (as compared to react). With single file components[0], it's quite possible to contribute knowing just html+css. In fact the scoped CSS makes Vue files superior to plain html+css for non CSS experts -- organizing large stylesheets is hard to get right! [0] https://vuejs.org/v2/guide/single-file-components.html https://vuejs.org/v2/guide/single-file-components.html
- deleted 6y ago
  [deleted]
- ryandvm 6y ago
  This is true. The MVC idea of separation of concerns on the surface seems like a good idea, but the reality is that I've never been on a team that was disciplined enough to actually keep things separated. As a mostly back-end developer, I am not a fan of the complexity and magical bullshit you have to know about to use React properly. I am also disgusted when a stopwatch app that can be done in 500kb of native code turns into 25 MB of cruft when implemented with React Native. The fact that it completely disregards MVC, which maybe never really worked anyway, is the least of its problems.
  - lukeramsden 6y ago
    > I am also disgusted when a stopwatch app that can be done in 500kb of native code turns into 25 MB of cruft when implemented with React Native. On the other hand, the time saved from using React Native versus having 2 separate codebases for iOS and Android is the difference between having a product and not having a product for many teams and solo developers. The issue there is not React Native being bloated, but cross-platform development being such a pain.
  - andrekandre 6y ago
    > The MVC idea of separation of concerns on the surface seems like a good idea, but the reality is that I've never been on a team that was disciplined enough to actually keep things separated. on the native app side, ive seen this too with mvc, mvvm, mpv apps: people just arent very good at deciding what goes where in many specific cases im not sure, but my guess is, the more layers you have to maintain, the higher the cognitive load that one has to implement so many parts, they start to tire and without knowing it, smear things across layers, making a huge mess over time
- kgin 6y ago
  The idea that HTML was meant to be a pure data format, styled by CSS classes that also were somehow part of that pure data format was always silly, but it became much more silly once REST apis became popular.
  - andrekandre 6y ago
    maybe its "ivory-tower thinking" in the end... that idea alwasy appealed to me to he honest... i guess the thing is its only one small facet of web development, not the whole thing
    - kgin 6y ago
      Same here, I spent so much time making semantic html that felt great but in the end was never consumed semantically by anyone or anything.
      - Swizec 6y ago
        Only benefit I get out of keeping my HTML semantic these days is that using 1 div instead of 10 has a big impact on UI performance. Draw fewer DOM nodes is still one of the best bang for buck optimisations you can do.
      - yashap 6y ago
        Semantic HTML is a pretty important part of making your site accessible. Screen readers have likely consumed that HTML plenty of times.
  - rimliu 6y ago
    What REST has to do with it?
- rimliu 6y ago
  So in your 15+ years you never saw a project done right. Sad, really. CSSZengarden is mostly forgotten. True, it is just a demo project, but there were some prominent redesigns, and some people even had fun doing "CSS Swaps".
baron816 6y ago
That's the luddite take. You probably shouldn't take up a career in technology if you're not willing to continually learn new things to keep up with advancements.
- brandonmenc 6y ago
  React may be an improvement on what came before, but it's still too complex for "draw a UI on the most-widely used platform." It's definitely not helping to democratize programming the way that the personal computer did when it simplified the world of computers down to a BASIC interpreter that a child could understand. The "advancements" are necessary, but let's be honest - they are far from ideal, overcomplicated messes that exist solely to paper over the fact that the main software delivery platform is still just a hacked-up document viewer. They make professional programmers' lives easier, but the act of programming becomes generally less accessible with each iteration.
  - hombre_fatal 6y ago
    Don't really buy this. React is a lot simpler than all of the other frameworks/APIs/SDKs I've used like Cocoa/UIKit that draw a UI on a client that only a fraction of people can use. You'd expect it to be simpler, not more complicated, if you get to target a Also, unlike iOS dev (for example), the web still has a trivial `echo "<div>hello world</div>" > index.html` you can use when you want it. I always wonder how many web-client dev critics have done much work building clients on other platforms. Spoiler: it never was simple nor easy. And people's favorite hey day examples only worked for a specific platform.
  - diffrinse 6y ago
    Unclear why React has to service that need. jQuery still exists, is still supported and maintained, and serves that need much more effectively I wager. And taking a step back I think many people in frontend confuse React for a jQuery alternative, the thing you whip up a web project with by default, but it really isn't. That there is a component ecosystem might suggest its a jQuery alternative, but they really are for different scales of application programming. I think it's this idea most harmful about React adoption and to be fair React marketing hasn't exactly said otherwise. So we get web pages with massive JS deps cause most people are probably using React for a productive developer experience rather than a fitting use case that actually justifies resorting to a virtual DOM model for applying view state, and yet React sold itself on "we probably know better than you about efficient DOM updates". That's true if you have lots of Juniors hanging around.
julianeon 6y ago
They could always look into a minimalist framework like Svelte, which is intentionally the most minimal step up from plain JS/HTML in terms of coding, yet gives you the power to make React-level websites. I recently wanted to throw up some minimal stuff on S3 without building, just a HTML file, and was surprised at how small the difference was, for simple enough pages - almost 0.

by toshk 6y ago

Swizec 6y ago

In my experience that separation of concerns was fake. 15+ years of webdev and I ain’t ever seen a redesign that doesn’t fundamentally change the layout and business logic. Never seen a spec update to logic that doesn’t also change how things look. The coupling is super tight and always has been.

toshk 6y ago
I meant more in the sense that different people could do different jobs. Non-developers/designers were able to do a lot of the frontend stuff. With the "new" complexity of frontend development that's mostly gone. I've seen it a few times with my own eyes that in teams the 1-5 frontenders specialised in html/css had a really hard time switching to react, at the same time more seasoned developers felt like fish in the water. Considering the scarcity of developers that's actual a big deal, more work for developers while at the same time less work for traditional frontenders.
- Swizec 6y ago
  In my experience those different people couldn’t do different jobs. Designers could write css, but I hd to set up magic id/class incantations for them. They could write html, but changes kept breaking business logic. Css zen gardens was a fantastic idea that I’ve never seen realized in a real project with business needs. Maybe I’ve just been unlucky.
  - toshk 6y ago
    I've seen few organisations where there was a group of frontenders specialised in html/css. Even integrated in continious development. It's a fine line, but with backbone.js and sass they could manage, but with react and postcss the line between templates and logic disappeared. But it's less specific then that. When 6 years ago hiring a frontender they needed to just know html and css, now they need to be full blown devs.
- dgb23 6y ago
  I’m currently training/mentoring a designer in using React, Tailwind, Markdown and basic CLI tooling (git and yarn). She appreciates the power and expression shes given and is learning quickly and steadily. No prior coding knowledge. Most of this comes down to getting past the fear of coding/programming. And it is a powerful enabler, even reshapes thinking. She recently came up to me with saying “why should I write this in Word? We have markdown and I bet there is a tool where I can style this and generate a PDF”.
  - toshk 6y ago
    Some people just get development. I had one close person who was able to learn webdev and become and highly skilled freelance developer in 0.5 to 1.5 year (having played with computers his whole life), I had another friend who after 3 to 4 years still struggles to do a simple loop, let alone grasp a recursive function, at the same time he makes great designs and has good skills to implement them frontend wise. Different minds, different talents.
  - rimliu 6y ago
    That's really the main reason React got popular. Somehow it lets the people who do not know what they are doing get by. At the expense of the users.
    - dgb23 6y ago
      Mind you in my case the designer just really does JSX templating with it and styling. The wiring, plumbing, state and so on is not her business. The reason I use React is mostly its composable, simple templating abstraction and the fact that it works both on the server and the client. UX is generally improved. If a site/app is done well, it will work w/o JS enabled, loads fast and transitions even faster. JS typically makes things better, not worse. What makes sites slow is putting in external and/or heavyweight stuff: ads, analytics, tracking, fonts, images and so on.
- hombre_fatal 6y ago
  >Non-developers/designers were able to do a lot of the frontend stuff. This always smells like "nobody could possibly do what we do" developer hubris. The designers I've worked with on my last three large React projects could edit .jsx/.scss files. I don't really buy the idea that someone can learn web client design but it's jsx or whatever that's too much.
- tln 6y ago
  FWIW enabling designers is one reason I like Vue a lot (as compared to react). With single file components[0], it's quite possible to contribute knowing just html+css. In fact the scoped CSS makes Vue files superior to plain html+css for non CSS experts -- organizing large stylesheets is hard to get right! [0] https://vuejs.org/v2/guide/single-file-components.html https://vuejs.org/v2/guide/single-file-components.html
deleted 6y ago
[deleted]
ryandvm 6y ago
This is true. The MVC idea of separation of concerns on the surface seems like a good idea, but the reality is that I've never been on a team that was disciplined enough to actually keep things separated. As a mostly back-end developer, I am not a fan of the complexity and magical bullshit you have to know about to use React properly. I am also disgusted when a stopwatch app that can be done in 500kb of native code turns into 25 MB of cruft when implemented with React Native. The fact that it completely disregards MVC, which maybe never really worked anyway, is the least of its problems.
- lukeramsden 6y ago
  > I am also disgusted when a stopwatch app that can be done in 500kb of native code turns into 25 MB of cruft when implemented with React Native. On the other hand, the time saved from using React Native versus having 2 separate codebases for iOS and Android is the difference between having a product and not having a product for many teams and solo developers. The issue there is not React Native being bloated, but cross-platform development being such a pain.
- andrekandre 6y ago
  > The MVC idea of separation of concerns on the surface seems like a good idea, but the reality is that I've never been on a team that was disciplined enough to actually keep things separated. on the native app side, ive seen this too with mvc, mvvm, mpv apps: people just arent very good at deciding what goes where in many specific cases im not sure, but my guess is, the more layers you have to maintain, the higher the cognitive load that one has to implement so many parts, they start to tire and without knowing it, smear things across layers, making a huge mess over time
kgin 6y ago
The idea that HTML was meant to be a pure data format, styled by CSS classes that also were somehow part of that pure data format was always silly, but it became much more silly once REST apis became popular.
- andrekandre 6y ago
  maybe its "ivory-tower thinking" in the end... that idea alwasy appealed to me to he honest... i guess the thing is its only one small facet of web development, not the whole thing
  - kgin 6y ago
    Same here, I spent so much time making semantic html that felt great but in the end was never consumed semantically by anyone or anything.
    - Swizec 6y ago
      Only benefit I get out of keeping my HTML semantic these days is that using 1 div instead of 10 has a big impact on UI performance. Draw fewer DOM nodes is still one of the best bang for buck optimisations you can do.
    - yashap 6y ago
      Semantic HTML is a pretty important part of making your site accessible. Screen readers have likely consumed that HTML plenty of times.
- rimliu 6y ago
  What REST has to do with it?
rimliu 6y ago
So in your 15+ years you never saw a project done right. Sad, really. CSSZengarden is mostly forgotten. True, it is just a demo project, but there were some prominent redesigns, and some people even had fun doing "CSS Swaps".

baron816 6y ago

That's the luddite take. You probably shouldn't take up a career in technology if you're not willing to continually learn new things to keep up with advancements.

brandonmenc 6y ago
React may be an improvement on what came before, but it's still too complex for "draw a UI on the most-widely used platform." It's definitely not helping to democratize programming the way that the personal computer did when it simplified the world of computers down to a BASIC interpreter that a child could understand. The "advancements" are necessary, but let's be honest - they are far from ideal, overcomplicated messes that exist solely to paper over the fact that the main software delivery platform is still just a hacked-up document viewer. They make professional programmers' lives easier, but the act of programming becomes generally less accessible with each iteration.
- hombre_fatal 6y ago
  Don't really buy this. React is a lot simpler than all of the other frameworks/APIs/SDKs I've used like Cocoa/UIKit that draw a UI on a client that only a fraction of people can use. You'd expect it to be simpler, not more complicated, if you get to target a Also, unlike iOS dev (for example), the web still has a trivial `echo "<div>hello world</div>" > index.html` you can use when you want it. I always wonder how many web-client dev critics have done much work building clients on other platforms. Spoiler: it never was simple nor easy. And people's favorite hey day examples only worked for a specific platform.
- diffrinse 6y ago
  Unclear why React has to service that need. jQuery still exists, is still supported and maintained, and serves that need much more effectively I wager. And taking a step back I think many people in frontend confuse React for a jQuery alternative, the thing you whip up a web project with by default, but it really isn't. That there is a component ecosystem might suggest its a jQuery alternative, but they really are for different scales of application programming. I think it's this idea most harmful about React adoption and to be fair React marketing hasn't exactly said otherwise. So we get web pages with massive JS deps cause most people are probably using React for a productive developer experience rather than a fitting use case that actually justifies resorting to a virtual DOM model for applying view state, and yet React sold itself on "we probably know better than you about efficient DOM updates". That's true if you have lots of Juniors hanging around.

julianeon 6y ago

They could always look into a minimalist framework like Svelte, which is intentionally the most minimal step up from plain JS/HTML in terms of coding, yet gives you the power to make React-level websites. I recently wanted to throw up some minimal stuff on S3 without building, just a HTML file, and was surprised at how small the difference was, for simple enough pages - almost 0.