https://github.com/richardanaya/wasm-service
dom다루는거 string으로하네 씨발ㅋㅋㅋ
심지어 js도 완전히 제거할 수 없고 css끼니까 개 난잡하네
이런쓰레기짓거리를 러스트로 하다니 진짜 너무하네
뭐가좋은건지 아무리 찾아봐도 모르겠음 누가설명좀
[질문] rust랑 htmx사용한 예제 찾았다ㄷㄷ 이게미래임?
익명(104.28)
2023-07-19 17:17
추천 0
댓글 41
다른 게시글
-
angular를 사용했던 이준석.png [8][%] 익명(211.204) | 23.07.19추천 0
-
하노이탑 이틀차 [3][%] 익명(117.111) | 23.07.19추천 0
-
비연고 3700중견 전산 뼈묻기 vs 연고지 2800si [1][질문] 익명(61.82) | 23.07.19추천 0
-
도커로 개발 환경 꾸미는거 한번 생각해봤는데 아찔해짐.. [11][%] 익명(58.122) | 23.07.19추천 0
-
db에서 뷰나 커서같은것도 쓰임?? [2][질문] 익명(222.112) | 23.07.19추천 0
-
Python은 프로덕트 레벨에서 쓸 수 없음? [10][질문] 익명(220.121) | 23.07.19추천 1
-
리액트로 개인프로젝트 중인데 메뉴 만들고 있거든? 코드 평가점 [3][질문] 이직하고싶..(121.140) | 23.07.19추천 0
-
도커 neovim찾아보니깐 이런게있네.. [2][%] 익명(117.110) | 23.07.19추천 0
-
지금 다니고 있는 회사에 레퍼체크가 일반적임? [9][질문] 익명(106.101) | 23.07.19추천 4
-
구글 클라우드 나만 어렵나..[%] 익명(223.33) | 23.07.19추천 0
진짜모름
너 예전에 이걸로 꾸준글 썼던 애 아님? 내가 그때 링크 보내주고, 또 장점 모르겠으면 질문하라고 했는데, 잠수 탔잖아. 그냥 깔려고 생각하는 게 아니면 진지하게 물어보는 거면 대답해줄게.
https://dev.to/quii/htmx-is-the-future-157j
일단 이거 보고 와닿는 게 없으면 나한테 질문 해줘. 설명해줄게
나 꾸준글 쓴적 없는데 애초에 글을 잘 안씀
아 그래? 딴 넘이랑 착가했나보네. 암튼 궁금한 거 있으면 질문 ㄱㄱ
왜 쓰는지, 내가 왜 SPA 프레임워크와 비교해서 이 방법을 더 좋아하는지 말해주고 싶음. 좋은 의미로 키배 환영.
html 조각을 주고 받는 게 좀 그렇다 해야하나? ui 수정하려면 프론트랑 백을 다 수정해야하는데 난 이건 좀 별로같음 아니면 다른 방법이 있나?
일단 html 조각을 주고 받는 게 좀 그렇다는 게 왜 그렇다는지 모르겠음. 원래 하이퍼미디어의 목적자체가 그런 용도로 설계되었고, 이게 전통적인 방식이자, 웹에서 처음 지향했던 방향? 이기도 함. 그러다가 하이퍼미디어가 여러가지 기능적 한계 때문에, 점점 의미를 상실하고, 서버가 RESTFUL API 로서 통신방식은 데이터를 주고받는 데이터 레이어로 변하기 시작했음. 주로 프로토콜은 JSON으로 통일되었고, htmx는 원래의 전통적인 방법을 부활, 보완하자는 방향임.
내가 바라보기에, 데이터를 json으로 직렬화해서 전송하고, 그걸 클라이언트가 받아서 다시 파싱해서, 수정하는게 더 번거로워보임. 어차피 최종적으로 보여주는 건 html인데, 그 과정에서 왜 바로 주고 받으면 안 된다는 거임? 훨씬 자연스럽고 직관적인 방안임. 그리고 ui 수정하려면 프론트와 벡을 다 수정해야된다는데 htmx 를 쓴다고 가정하면 굳이 spa 프레임워크를 쓸 필요가 없슴. 그 말인즉슨
ui 수정하고 싶으면, 서버 측에서 html template을 교체하거나 수정하면 됨. 이게 왜 둘 다 수정해야 된다는 걸로 귀결되는 건지 모르겠네. SPA 프레임워크를 쓸 때도 UI 를 수정할라치면 프론트만 수정하면 되잖아. 똑같은 거임. 상태도 바꿔야 되면, 프론트 벡 둘다 수정해야 되고, 질문이 이해가 안 감.
아 맞네 spa를 안쓰니까 서버만 수정하면 되는구나
preact 써라
tree-sitter 같은걸로 쌩 문자열 하이라이팅 정도는 해결할 수 있고, 가볍게 간단한거 만들기엔 괜찮아보이는데
백엔드 개발은 하고 싶은데 프론트엔드는 너무 집중하고 싶지 않을 때 쓰기 좋아보이는듯
oo 맞음. 특히 JS/TS npm 혐오하는 나 같은 웹개발자 입장에서 진짜 최고임.
가볍게 간단한거 뿐 아니라 꽤 복잡한 것도 부드럽게 잘 만들 수 있음.
솔직히 복잡한건 좆같아도 TS 쓸 것 같음...
why? 취업 때문에?
htmx를 아직 직접 써보진 않아서 첫인상에 의한 뇌피셜임. 나중에 써보고 판단할 예정 1. 관련 라이브러리 수가 적으니 결국 거의 다 직접 개발하는 형태가 될텐데, 쓰는 사람이 적으니 협업도 힘듦 2. JS/TS는 좆같은만큼 하다보면 이 좆같은게 왜 존재하고, 웹개발에 내부적으로 어떤 문제점이 있는지 공부되는게 있음. 저건 생산성은 좀 오를지언정 어느 방향에서든 내 실력향상에 도움이 될지 모르겠다... 취업 문제랑 연결되는 부분이기도 하고 딱 프론트엔드 신경안쓰고 백엔드 PoC 토이프로젝트 찍어낼 때 좋은 것 같음
1. 생태계는 당장 적은 게 맞음. 그러나 앞으로 활발해질 예정(내 뇌피셜). 그리고 htmx 쓴다고 JS/TS 를 못 쓰는 것도 아님. TS는 굳이 쓸라면 같이 연동해서 쓸 수도 있음. 근데 그렇게 되면 필연적으로 node.js 및 npm 툴 체인과 연계되므로 비추. 어쨌든 JS는 사용가능. 그 말인 즉슨, 니가 필요한 모든 JS 생태계를 갖다 쓸 수 있다는 말임. CDN 형태로. (또는 JVM 환경이면 WEBJAR 같은 걸로.) 그래서 프론트 프레임워크 없이 최소한도로 필요할 때만 라이브러리 땡껴쓰는 형태로 생태계의 도움을 받을 수 있음. 쓰는 사람이 적으니 당장은 협업이 힘들긴 하겠지만, 그때 어차피 디자인은 html, css로 작업하니, 퍼블리셔만 한 명 고용하면, 니가 혼자 다 할 수 있음.
2. 웹개발에 내부적으로 어떤 문제점이 있는지 공부되는게 있다는 거, 난 솔직히 납득못함. 실력향상은 여러가지 관점에 따라 개인적 편차가 있긴 하겠지만, 프레임워크에 대한 능숙함을 요구하는 업종에서는 불리함이 있겠지. 근데 뭐 어쩔 수 있나 ㅋ 내가 써야 될 이유를 납득못하는데, 뭐 회사에서 쓰는 거라면 써야 되지만.
내말은 컴포넌트 레벨로 쪼개서 개발하는게 아직 힘들 것 같다는 얘기임. 커뮤니티가 얼마나 커질 수 있는지 두고 봐야지 개인적으로는 딱 백엔드 개발자들을 위한 프론트엔드 라이브러리(프레임워크?)라는 포텐셜은 있어보이고 제대로 타겟층을 잡았으니 react/vue/svelte 등등 프레임워크 경쟁이랑은 별도로 살아남아서 꾸준히 성장은 가능할 것 같음
근데 저렇게 js가 들어갈 것 같으면 뭐하러 러스트를 씀? 그니까 htmx 하고 싶은 건 알겠는데 이게 왜 좋고 간단한지 설득이 안 됨 난 이게 오히려 빙빙 둘러가는 길처럼 보임
그리고 저렇게 하면 너무 구조가 딱딱해지고 유지보수도 훨씬 어려워보이는데
오늘 피곤해서 길게 답장은 못하겠다. 내일도 같은 의문이 있으면 추가적으로 답해줌. js가 들어가는 건 웹 개발하는 이상 wassm 이 궤도에 오르기 전에는 필수적이다. 단지 js 활용도를 최소로 낮출 수 있나 아니나로 바라봐야 될 관점이지. htmx 쓰면 그 js를 정말 필요할 때만 사용할 수 있다. 대부분 인터렉션은 다 커버를 치기 때문에. 러스트를 활용하는 건 당연히 서버사이드에서 쓸려고 사용하는 거지. 이것도 질문을 이해 못 하겠네. 벡엔드 언어를 선택해야 되는데, 벡엔드는 언어의 선택의 폭이 다양하다. 위에는 RUST를 좋아하니까 RUST를 사용하는거지. 니는 프론트엔드 JS 쓰는데 그럴 거면 왜 벡엔드 다른 언어 씀? 이라고 질문하는 거임?
그리고 저렇게 하면 너무 구조가 딱딱해지고 유지보수도 훨씬 어려워보이는데 <=> 정확히 반대다. 디커플링이 문제라고 한다면 그건 맞다. 애초에 서버와 한 몸으로 조합되어 사용하는 게 가장 효율적인 방안이기 때문에, 기존 SPA 프레임워크로 만든 웹앱처럼 REST API 만 교체하거나 추가하여 쉽게 확장할 수 없다는 게 단점이다 그리고 이게 SPA 프레임워크의 유일한 장점이다. 대신 구조는 훨씬 간단해진다. 유지보수도 애초에 1인 웹 개발이라고 친다면 훨씬 쉬워진다. 이거는 구차하게 설명하는 것 보다 직접 해보면 확실히 와닿겠지만, 내일 추가적으로 의문이 있다면 답해드림.
암만 설명을 들어봐도 풀스택 개발자에게나 어필되는 장점인 것 같은데 htmx 서버를 구현하면 백엔드만 하던 사람은 강제로 풀스택이 돼야하는 거임? 그리고 구조가 간단할 수 밖에.... 하드코딩의 영역이 훨씬 늘어나는데 그래서 생기는 확장성의 저하는 따라오는 속성인 거 아님?
구조가 단순하다랑 유지보수의 난이도는 같이 보면 안 되지 게다가 혼자 개발하는 거면 몰라도 팀, 회사 단위로 프로젝트 운영할 때 도대체 명세는 어떻게 세우고 어떻게 이해시키고 어떻게 납득시킴?
난 좀 방향을 다르게 접근해서 생각함. 애초에 대부분의 회사에서 전문 웹 프론트엔드 엔지니어가 따로 존재해야 되나? SPA 프레임워크가 등장하기 이전에도 수백만명의 사용자를 감당하는 웹 사이트 개발을 잘 해오고 있었음. 그 시절에 웹 개발자면 웹 개발자지, 프론트, 벡엔드 엔지니어가 따로 존재하지는 않았음. 프론트엔드 영역이 따로 떨어져나가게 된 건, SPA 프레임워크가 본격적으로 활개치면서부터인데, 나는 그 이유가, 표면상으로는 모던 웹, 모던 JS의 등장으로 웹 환경이 고도화되면서 이 환경을 전문적으로 다룰 수 있는 프레임워크가 필요하다고 하지만, 사실상 내 생각에 이 프레임워크(특히 REACT) 자체를 다루는 러닝커브가 높아져서 그렇다고 생각함. 대부분의 개발자는 일반적인 CSS + html +JS
의 지식으로 잘만 개발을 해오고 있었음. 근데 그들에게 너무나 복잡하고, 그만큼 강력하고 많은 기능을 제공하는 (때로는 쓸데없이 강력함) 프레임워크를 배워야 되는거임. 특히 NON-js 환경에서 개발해오던 개발자에게는 더더욱 힘든 일임. NODE.JS를 사용하지도 않는데, 프레임워크를 쓸려면, 모던 JS 생태계를 잘 알아야 함.(npm, package.json, webpack, eslint, babel.config ... . 등등등....) . 그 많은 추상화 레이어 개념을 알고 또 프레임워크 자체의 문법과 개념을 알아야 제대로 된 개발을 진행할 수 있음. 특히 리액트!!!! 같은 경우, 이렇게까지 복잡하고 난잡해야만 될까하는 생각이 항상 들음. 그래서 일종의 포기를 해버린 거지. 난 모르겠고,
서버만 개발을 할 테니까, 알아서 프론트엔드 엔지니어을 뽑아라. 그리고 닌 그 피로도가 영역을 나누게 된 근본적인 원인이라 생각함. 난 그게 일종의 재앙이라고 생각함. 영역이 고도화되면 분야를 나누는 건 당연한 일이긴 하지. 근데 솔까말 대부분의 웹은 그렇게 복잡한 걸 요구하지 않음. 애초에 ㅈ만한 웹 개발하는데, 나는 프론트 몰라 ㅠㅠ UI 못 짜ㅠㅠ 난 서버 몰라 ㅠㅠ DB 몰라 ㅠㅠ 징징거리는 게 이상한 일인 거 아님?
문제는 SPA 프레임워크가 모든 곳에서 쓰이고 있다는 거고, 적어도 내가 본, 신규 프로젝트는 대부분 리액트나, Vue 같은 걸로 개발을 진행함. 거의 무조건임. 심지어 공공기관에서도 그렇게 하드라구, 난 이게 이상하다고 생각함. 둘로 나눠져 있으면, 당연히 유지보수는 더 어려워짐. 서로 다른 코드 베이스를 개발, 유지보수해야 하는데, 당연히 일이 2배로 늘어나지.
끈임없이 벡엔드 개발자와 프론트엔드 개발자끼리 커뮤니케이션 미스를 해결해야 됨. 이게 비용이 만만치 않음. 실제 일 하다보면 이거 맞추는 회의시간이 전체 개발의 상당량을 차지함. 이 얼마나 쓸데없는 일임. 하드코딩의 영역이 훨씬 늘어난다는 건 뭔 말인지 이해를 못하겠음. 하드코딩이 들어갈 영역인가? 확장성의 저하는 분명함. 근데 대부분의 웹은 그 수준이 필요할 정도로 확장되지가 않음 ㅋ, 그냥 유지보수에 추가 기능 개발 정도로 끝나는 정도지. 물론 페이스북이나, 인스타 같이 대규모 웹앱은 다른 접근방식이 필요할 수 있다는 건 이해. 그러면 그 때 SPA 프레임워크를 쓰면 됨.
회사단위로 팀 단위로 개발도 그냥 딱딱 관련 페이지 및 기능 정해놓고 개발 진행하면 됨. 원래 하던 방식대로, 익숙하잖아? 오히려 같은 코드베이스를 가진 개발진들끼리 뭉칠 수 있어서, 커뮤니케이션 미스의 위험도가 현저히 낮아지게되지
템플릿 엔진이랑 뭐가 다름
템플릿 엔진이랑 조합해서 쓰는 거임. 템플릿 엔진의 단점인 화면(페이지)을 통째로 던져주는 걸, 조각조각 나눠서 교체할 수 있도록 해주는 거임.
속도가 빠를려나?
php 스타일이네 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 역시 유행은 돌고도는법~~
맞다. 전통적인 웹 개발의 부활 신호라고 보면 된다. 예전의 SPRING + JSP + AJAX , PHP + AJAX , 장고 + 진자 + AJAX 같은 개발방식을 좀 더 개선한 방식으로 새롭게 진화한 거다. 모던 프론트엔드 환경에 진절머리난 개발자들에게는 정말 좋은 선택권이 주어진 셈이다.
이뭔ㅆ..