추가적으로…
제가 (그리고, 많은 분들이) 블레이저 앱에서 UI프레임워크 보다 css 를 선호하는 이유는, 블레이저의 독특한 구조때문입니다.
블레이저는 돔 객체를 관리하고, 우리는 C# 코드를 통해 객체의 상태를 제어하게 됩니다.
물론, 자바 스크립트(나 제이쿼리)의 실행도 막지 않습니다.
문제는 자바 스크립트 실행 코드 중 일부가 돔 객체를 변경했는데, 블레이저가 이를 통지받지 못하면, 그로 인해 블레이저가 오동작을 하게 된다는 점입니다.
일례로 제가 직접 겪은 바를 말씀드리면, 부트 스트랩의 체크 박스인데, 아래 글의 예제 코드에서 사용했었습니다.
블레이저 - 양 방향 바인딩이 가능한 Flag Enum 입력 콘트롤. - 
튜토리얼, 팁, 강좌 - 닷넷데브 (dotnetdev.kr)
부트 스트랩 체크 박스의 체크 상태(bool)는 자바스크립트에서 관리합니다.
그런데, 간혹 가다가 코드 변수가 가진 상태와 자바스크립트가 가진 상태가 불일치되는 경우가 있더군요. (실력이 안되서 이유는 못 밝혔지만요)
즉, UI는 체크 상태인데, 코드는 해제 상태로 남아 있는 등.
그런 이유로 예제는 코드의 상태 값이 변하면, 체크 박스가 전체가 다시 렌더링되는 구조로 변경했습니다. 문제는, 예제에서는 체크 박스가 10개도 안되기에 리렌더링의 비용이 쌀지는 몰라도, 몇 백개가 되면 무시할 수 없는 수준이 됩니다.
그래서, 실제 사용 코드에서는 체크 박스를 html 로 정의하고, 체크 상태를 css 를 통해 제어하는 방식으로 변경했습니다.
문제의 소지가 있는 자바스크립트에는
- JSInterop 을 위해서 사용자가 정의하거나 import 해 온 것.
- 부트스트랩을 포함한 외부 CSS 프레임워크에 포함된 것.
- UI 프레임워크에 포함된 것
등, 돔 객체를 건드리는 한 모두 잠재적 위험 요소가 됩니다.
대부분의 UI 프레임워크는 자바스크립트 친화적입니다. 그쪽에 계신 분들이야 맘 편하겠지만, 블레이저 사용자 입장에서는 언제 어디서 어떻게 문제가 나타날 지 불안을 떨칠 수 없습니다.
닷넷 전용의 UI 프레임워크라도 용의선 상에서 내려오기란 쉽지 않습니다.
프로젝트 템플릿에 끼워 있는 부트스트랩에도 문제되는 부분이 있을 정도니까요.
아래는 같은 내용을 설명해주는 닷넷 문서입니다.
이 글을 처음 읽었을 땐 뭔 말인가 했는데, 문제를 겪은 후에 읽으니 아주 그냥 가슴을 후벼팝니다.
많은 유튜브 강좌나 인터넷 튜토리얼에서도 가급적 자바 스크립트를 안 쓰고, C# 코드로만 UI를 제어하려는 경향과도 무관하지는 않은 것 같습니다. 그들의 가슴에도 패인 흔적이 몇 군데 있을 듯 합니다.
물론 돔 객체와 무관한, 특히 브라우저가 제공하는 웹 API 호출 스크립트는 아직까지 문제를 발견하지 못 했습니다.