[neya]

I'm one of the laggards - Over the years, based on staying around tech communities (esp. HN) I've learned not to invest time / effort into the hype that surrounds a newly launched tech. I did burn my finger a couple of times, especially with MongoDB back then, so these days I'm pretty cautious.

I'm one of the very few who didn't invest in React. I waited it out and invested into Vue.JS, instead. This is no framework war, purely based on opinions.

My opinion is pretty simple and resonates with a lot of people, apparently[1]:

    ~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we’re writing code like this: [1]

This alone makes React a joke for me, let alone the author's post. If it resonates with you, then good for you. I may not be from Facebook or Google to have the authority, but I do know what's good in the long run and what isn't. I couldn't be happier with Vue.

[1] https://twitter.com/thomasfuchs/status/810885087214637057?la...

[borplk]

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.

[davidmurdoch]

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.

[borplk]

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.

[coldtea]

>~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we’re writing code like this:

That's definitely not what's bad about React. In fact that's what great about React -- coherent widgets (components) that are defined in a single place. Not to mention that JSX in React it's all JS and properly parsed and checked -- the "HTML" there is just sugar.

Such separation of HTML/JS/CSS was misconceived. It makes sense for web documents and simple forms, but not for web apps with rich widgets etc (which is what we're trying to do). Tons of problems stemmed from cargo cult adherence to that.

Everybody else, including those that add JS instructions (or ad-hoc "templating language" instructions inside HTML tags) are getting it wrong.

[threatofrain]

I'd argue that back then, focusing on elegant CSS was also a mistake. Outside of well-done libraries, I've never really perceived code re-use as a big force multiplier.

Even now with React, I still don't see much code re-use outside of libraries. When you want your code to be re-used... you exercise the discipline that a library author would. You add typings, you add documentation, you add tests, you create a Github page where people can provide info. Taking someone else's code is a commitment, so you at least want the reassurance of library-quality code.

Otherwise when you write a component, whether in the old school html/css/js split, or in React, you're unlikely to write the component in a way that optimizes for generality, and optimizing for generality, as opposed to the narrow business case in front of you, is often a lot harder.

[ldiracdelta]

And it wasn't 15 years. It been more like 40 years of trying to push Model-View-Controller architecture. Widgets instead of MVC increases code mental locality - the things that closely interact in the system are close in the code. Widgets also do not create an arbitrary cutline that doesn't fit all scenarios.

[rhinoceraptor]

Is it actually better to need to have three files open at a time in order to work on a UI component?

I think React components perfectly follow the single responsibility principle. You have a single file that is responsible for one thing: mapping data to UI. Yeah, it has some crazy syntax but it's just sugar.

I tend to use separate stylesheets, but that file lives right next to the component file.

[yen223]

To paraphrase somebody, separating HTML, JS & CSS is like taking an essay and separating out the nouns, verbs and adjectives. Sure you have achieved "separation of concerns", but your codebase now no longer has any semblance of coherence.

[TheCoreh]

I don't see how vue's take on this same issue is significantly or even marginally better: https://vuejs.org/v2/guide/conditional.html

Instead of getting HTML fragments on your JS, you get JS fragments on your HTML? Whenever you need to programatically generate markup with conditionals and iteration over existing data structures, you end up having to mix a programming language with your markup. (The other option is of course to create an entire programming syntax on top of your markup language.)

BTW, I haven't actually used vue, so this post is by no means me saying that it doesn't have its merits or it's not a good framework.

[rhinoceraptor]

Having used Angular 1 quite a bit, I think the whole DSL for HTML business is not the way to go. But at least Vue had the good sense to compile them rather than evaluate them at runtime like Angular.

[wslh]

I will buy the hype once I can sit and create the whole UI/UX visually dragging widgets and not creating a single line of html/javascript/css/your-favorite-tenplate-language. Except if I am doing some real new UI/UX.

[janci]

I still sitck with AngularJS because of it's simplicity. You just bind your data to the template. Vue looks similar, but I learned not to start new big project with brand-new library.

[noway421]

Vue components are really following the same paradigm React does: styling, view and logic are all in one place. The only thing in which react differs here is that it uses different syntax. Instead of using attributes in the template which create a new language, react went with slightly modified javascript. And in the production build, Vue compiles html to javascript functions anyway.