In other news: Why I moved from table salt to sea salt.
If you feel the topic is inappropriate for HN, flag and move on. Snarky, dismissive comments like this don't add constructively to any discussion.
Why I moved from Angular to React
31–40 of 107 posts
Re: Why I moved from Angular to React
#32Earlier quoted context omitted.
You should give Elm a look, then.
I'm really interested in Elm, it's on my 'things to explore' list. But I've already built a big 'component' library for my designs and style in React, and it's hard to justify a switch to anything else for a long time. And sadly that's the biggest problem the upcoming languages/frameworks face.
Yup, I still use knockout because I have components for nearly everything I do.
Re: Why I moved from Angular to React
#33React comes with its own syntax to build components called JSX. In JSX you can mix up HTML and JavaScript. Additionally people often use inline styles in their elements. It is like adding CSS into the mix. This really scares me. We spent a lot of effort removing inline styling from HTML with CSS, and yet it still creeps into our HTML. We also have created a lot of "template" languages (e.g. PHP, Python, ERB, etc.) mi…
Take the CSS for an small button and add all the variations you need. And after some time someone not so skilled like you arrives and adds a padding to the first button.
That on scale it's not easy solvable.
And that's the reason why we are looking for other approaches to isolate/share the main functionality.
Re: Why I moved from Angular to React
#34React comes with its own syntax to build components called JSX. In JSX you can mix up HTML and JavaScript. Additionally people often use inline styles in their elements. It is like adding CSS into the mix. This really scares me. We spent a lot of effort removing inline styling from HTML with CSS, and yet it still creeps into our HTML. We also have created a lot of "template" languages (e.g. PHP, Python, ERB, etc.) mi…
This sounded scary to me at first, but in practice I've found it to be the opposite.
Separating css, html, and js makes sense when you're writing a document, and the content is the html and the css is strictly formatting.
It makes less sense when you're writing an app, and the styling of the html is an integral part of what is being created. The javascript works the same way; it's often integral to what's being rendered, not just patchwork adding small amounts of functionality to an existing document.
But probably most importantly is that react gives you a different way of separating concerns: it's very easy to put different chunks of the UI into different components/files, so your app is divided by functionality, instead of divided by technology. Keeping the html (and sometimes css) with the js that uses it helps increase the cohesion of small units in your UI that intimately work with each other, while separating those from other js/html/css for other units.
Re: Why I moved from Angular to React
#35Earlier quoted context omitted.
How are you going to embed an app in another app/DOM without using an iframe, and how is creating that iframe going to be any harder to accomplish depending on the technologies used inside of it? I'm not sure what you mean about components...Angular is component based. Are you referring to native web components?
Take a rich component from your angular UI/lib and export it as a web element. (React/preact/vue/polymer) can! Manage an stream of html comming from a backend CMS. An upgrade their DOM.
I see. Yeah, Angular probably doesn't target environments where it isn't the main/driving DOM/context.
Re: Why I moved from Angular to React
#36React comes with its own syntax to build components called JSX. In JSX you can mix up HTML and JavaScript. Additionally people often use inline styles in their elements. It is like adding CSS into the mix. This really scares me. We spent a lot of effort removing inline styling from HTML with CSS, and yet it still creeps into our HTML. We also have created a lot of "template" languages (e.g. PHP, Python, ERB, etc.) mi…
I look at JSX as more of a helper to lower the barrier to entry. In the end it's all just Javascript. You can render the (virtual) DOM in React without using any JSX/HTML syntax. So it's not "everything mixed into HTML", it's "there is no HTML until the top-level render() is instantiated".
Also, regarding the CSS questions, setups like CSS Modules in a Webpack build make the CSS very maintainable. Not to say there aren't drawbacks, but IMO having the classes be dynamic makes everything way more flexible. And, tools like hot-module-reloading make front-end development so much more enjoyable.
Re: Why I moved from Angular to React
#37React comes with its own syntax to build components called JSX. In JSX you can mix up HTML and JavaScript. Additionally people often use inline styles in their elements. It is like adding CSS into the mix. This really scares me. We spent a lot of effort removing inline styling from HTML with CSS, and yet it still creeps into our HTML. We also have created a lot of "template" languages (e.g. PHP, Python, ERB, etc.) mi…
As mentionned already, and as Pete Hunt famously talked about in "Rethinking Best Practices" (you can find it on youtube), you want to separate -concerns-, not technologies. Often there is a 1:1 between those things, but not in modern web development.
So we've seen a push toward components that mix technologies, but separate concerns. And it's been great.
Re: Why I moved from Angular to React
#38React comes with its own syntax to build components called JSX. In JSX you can mix up HTML and JavaScript. Additionally people often use inline styles in their elements. It is like adding CSS into the mix. This really scares me. We spent a lot of effort removing inline styling from HTML with CSS, and yet it still creeps into our HTML. We also have created a lot of "template" languages (e.g. PHP, Python, ERB, etc.) mi…
Splitting your code across technology boundaries is a misapplication of "separation of concerns". The "component" concept of React and other front-end frameworks seems to be a much better abstraction.
Styles work very well on the per-component level. The best and worst part of CSS is the "cascading" part.
The thing is that with React, you aren't really writing HTML. Sure, JSX makes it look like it, but it's not a template, it's actually just a Virtual DOM element tree. This means it doesn't have the same issues as many templates.
Re: Why I moved from Angular to React
#39React comes with its own syntax to build components called JSX. In JSX you can mix up HTML and JavaScript. Additionally people often use inline styles in their elements. It is like adding CSS into the mix. This really scares me. We spent a lot of effort removing inline styling from HTML with CSS, and yet it still creeps into our HTML. We also have created a lot of "template" languages (e.g. PHP, Python, ERB, etc.) mi…
You have to ask yourself why we were removing inline styling and inline JavaScript. There is a performance argument (inline styles perform badly), but the main goal was maintainability.
Now we have ways to use these patterns and still have them be maintainable, which means it's time to reevaluate that previous effort. Co-locating styling with structure and behaviour tends to make our lives easier.
I can go one step further, I work on a React-based website which achieves straight 'A's on webpagetest and scores 100 on Google Pagespeed (Mobile and Desktop), this took far less effort than it ever took me to achieve worse results on previous stacks.
The component model (with co-location of styles) is incredibly powerful, and it works, give it a try.
Re: Why I moved from Angular to React
#40Earlier quoted context omitted.
Take a rich component from your angular UI/lib and export it as a web element. (React/preact/vue/polymer) can! Manage an stream of html comming from a backend CMS. An upgrade their DOM.
I see. Yeah, Angular probably doesn't target environments where it isn't the main/driving DOM/context.
That's one of the problems.. it only covers an slice of the front-end space. And also there is some kind of lock-in.. you can't reuse your components for something else.