Hacker News new | ask | show | jobs
by borplk 3230 days ago
The whole "separate HTML, JS & CSS" idea I don't believe is something that should go unchallenged.

It was "best practice" back in the days for years and mostly just because it was best practice, but also because at that time it made juust that much more sense where web applications were more primitive and closer to a semantic HTML "document" with some interactivity sprinkled on top (remember when AJAX was bleeding edge jaw dropping? "LOOK THE PAGE DOES NOT EVEN REFRESH!").

It's just some theoretical ideal that never pays any dividends in the real world and is not appropriate for a sophisticated modern web application.

The separated HTML, JS and CSS of your sophisticated datetime picker element or auto-suggest fancy textbox are of no use or importance separately. They all need each other, they are all inter-dependent and if you force that separation on some ideological idealistic principle you create the spaghetti that any commercial web developer out in the front lines is well aware of.

You spend a good 60% of your time on "where is the HTML for this JS" ... "where is the JS for this HTML" ... "where is the CSS for this HTML".

I'm sure a lone programmer is going to come down here and reply about their snowflake project that "was done right".

I don't care. Frame the code and hang it on your wall.

Out there in the real world in teams of 10+ people with varying degrees of skill and care who join and leave over multiple years you can't have a snowflake project that is perfect in every regard. So if the eco-system doesn't give you strong suspension belts things will go south.

If you could easily and practically switch and mix and match custom HTML/JS/CSS for any given web application then that would be something.

We would need much tighter and stricter interfaces and so on for something like that to work.

We all know that's nowhere near the case. Any non-trivial commercial web application will inevitably have HTML/JS/CSS that are all heavily dependent on each other and as a result the separation of them doesn't provide much benefit, and creates a whole series of problems on top too.

1 comments

React+Redux is still very focused on separation of concerns, but now it's all in the JavaScript side: "where is the JS for this JS?" is the question now. Components, states, props, actions, reducers, stores, etc. React has just as many "separation of concerns" as ever.
I don't disagree. I don't think React+Redux is perfect or fixed every possible problem.

A lot of those things are in a way a fundamental side effect of lenient languages and dynamism.

Having said I think it's definitely nowhere near as bad.

I use Typescript and modern JS and types and the modules/import system does a lot to prevent those things.

Because in general I don't have any globals lurking around so for example the styling of a component is imported at the top in the same file so it's always nearby. So the symbols and variables that you see on the screen are more obvious in terms of where they come from.

Redux also while not perfect if you have a reasonable amount of discipline it doesn't get as bad as the old-school stuff.