Hacker News Reader

Comment by Swizec | Hacker News Reader

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.

View on HN

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.

> 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.

> 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

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.

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”.

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.

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.

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.

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

>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.

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.

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.

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.

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

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.

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.

Semantic HTML is a pretty important part of making your site accessible. Screen readers have likely consumed that HTML plenty of times.

What REST has to do with it?

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".

Reply on news.ycombinator.com