Bất cứ khi nào tôi đề cập đến việc tôi không sử dụng các bộ tiền xử lý CSS, mình có khuynh hướng có ngạc nghiên từ những người không thể tưởng tượng được việc viết CSS mà không có Sass. Và vì vậy mình phải bảo đảm sự lựa chọn của mình và giải thích tại sao, hết lần này đến lần khác. Một số người sẽ hiểu, hầu hết sẽ không. Hoặc họ không muốn. Nhưng đây là một nỗ lực để giải nghĩa lý do của tôi.
Quay lại khi các preprocessors CSS đầu tiên được đưa vào thời trang, mình đã thử sử dụng chúng. Và sau đó vài năm một lần, do áp lực bên ngoài và dai dẳng, mình đã có diện mạo mới và cho họ cơ hội mới. Nhưng đối với tôi, họ luôn cảm thấy như các giải pháp cần giải quyết vấn đề. Đó là, mình không thật sự tìm ra được "vấn đề" với CSS mà các nhà tiền giải quyết dự định giải quyết các vấn đề. Quy mô của trang web tôi đang xây dựng không trọng điểm, có thể là website nhỏ chỉ với một vài trang tĩnh hoặc mạng nội bộ tổ chức khổng lồ. mình chỉ ngắn gọn là không bao giờ cảm thấy sự cần thiết cho mixins, làm tổ hoặc mở rộng.
Một list các lý do sau đó:
tôi không cảm thấy các tiền xử lý CSS "vấn đề" có ý định giải quyết là đủ nghiêm trọng để đảm bảo chi phí, tức là với tôi giải pháp tồi tệ hơn vấn đề.
tôi muốn kiểm soát tuyệt đối CSS của mình, có nghĩa là mình muốn làm việc với nó, và xem chính xác những gì sẽ được gửi đến trình duyệt (tốt, trước khi nó được minified và gzipped, tất nhiên). Nếu điều đó cho thấy nhìn thấy cùng một khai báo lặp đi lặp lại trong một số quy tắc, hoặc phải tham khảo tiền tố nhà cung cấp trông như thế nào, vì thế hãy là nó. Đối với tôi, WET CSS dễ hiểu hơn và có thể bảo trì hơn so với hộp giả CSS màu đen DRY.
tôi không muốn tìm hiểu và lệ thuộc vào một syntax không chuẩn để bao bọc CSS của mình, làm cho nó cần phải biên dịch trước khi các trình duyệt có thể hiểu được nó. mình cũng không muốn đồng nghiệp của mình phải làm như vậy.
Tôi muốn CSS nguồn của mình có thể open beta mọi lúc, cho dù ở dạng chưa được rút gọn, không được ghép nối. Nếu quá trình xây dựng của tôi không thành công, vì bất kỳ lý do gì (như một mô-đun npm chưa được xuất bản), tôi có thể open beta CSS nguồn như một giải pháp khẩn cấp. Hiệu suất có thể có thể mất một hit, nhưng một trang website hơi chậm hơn có khả năng tuyệt vời hơn so với một trang website bị hỏng hoặc không có CSS cho đến khi quá trình xây dựng có thể được cố định.
tôi không muốn phải chờ đợi để biên dịch trước khi nhìn thấy kết quả của những thay đổi CSS của tôi. Thời gian xử lý có thể là bất cứ điều gì từ không đáng kể đến bực bội, rõ ràng, nhưng nếu mất nhiều thời gian hơn để mình chuyển từ trình chỉnh sửa mã sang browser của mình và tải lại trang (≈1s) thì quá chậm.
Tôi hoàn toàn nhận thức được rằng nhiều người dùng các preprocessors CSS sẽ không đồng ý với hầu hết hoặc tất cả những điều trên. Tôi đã biết rằng vì thế không cần phải nói với tôi :-).
Còn muốn đọc nữa:Java core
Tuy nhiên, mình không sử dụng Sass hoặc các bộ tiền xử lý CSS khác như cssnext không có nghĩa rằng mình không sử dụng các bộ giải quyết CSS. Sự khác biệt, như tôi thấy, là liệu CSS của bạn có yêu cầu biên dịch hay không trước khi các trình duyệt có thể hiểu nó, điều mà tôi thực sự muốn tránh.
Mình sử dụng PostCSS (với các plugin của bên thứ ba và những cái tôi đã tự viết) và CSScomb làm người trợ giúp cho những thứ như:
- Sắp xếp các khai báo và sửa các vấn đề về kiểu code hóa với CSScomb
- Tự động chèn tiền tố của nhà cung cấp vào bất cứ nơi nào họ cần (hoặc xóa chúng ở bất cứ đâu)
- Chèn dự phòng cho thuộc tính tùy chỉnh
- Iinting CSS
Tôi thiết lập cả CSScomb và PostCSS để làm việc trên CSS nguồn của mình, có nghĩa rằng mình luôn thấy kết quả. Không có hộp đen. mình có thể save tệp của mình và tải lại ngay lập tức mà không cần phải chờ biên dịch (vì các đổi thay chủ yếu là tiền tố của nhà cung cấp và tiền tố / chỉ có thể được chèn một lần). Nhưng các công cụ giúp tôi tiết kiệm được một số phương pháp gõ và sửa chữa hầu hết các mâu thuẫn kiểu mã hóa đối với tôi. Đó là loại xử lý CSS của mình.
No comments:
Post a Comment