좀 많이 애매한거같은데... html 보내주는 백엔드는 뭐 조상님이 만들어 주실것도 아니구 자료를 html 로 보내기 시작하면 확장성도 참담하고 상태관리 제대로 한다고 생각하면 눈앞의 코드 몇 줄 줄이는게 크게 의미가 있나 싶기도 하고 객체 지향 프로그래밍을 좋아하는 입장에서는 솔직히 좀 끔찍한 접근방법이네요 좀 복잡한 웹앱 만들때 쓰기에는 터무니 없구요 간단한 사이트 만들때는 좋아보이는데 사실 간단한 사이트는 워드프레스나 아임웹으로 만드는게 더 나아요 그냥 리액트하세요 스벨트 쓰던지
하이퍼링크가 없어서 그렇습니다. Rest api로 받아오는 정보로부터 또 다른 api를 받아올 수 있는 구조가 되어야 해요. Json api는 서로 관련되어 있는 api도 네트워크 상에서 보면 사실 모든 api가 endpoint로 전혀 관련이 없고 독립적입니다. 각각의 api는 자신 이외의 api의 존재조차 알 수 없습니다. 즉 api의 연관성을 알기 위해서는 rest api가 무조건 필요한거죠. api reference 웹페이지를 통해 json api들의 연관성을 알 수 있지 않냐고 하실 수 있는데 웹페이지 또한 그냥 브라우저가 요청하는 html api입니다. 그냥 브라우저가 api를 유저 친화적으로 볼 수 있도록 렌더링해주는 것 뿐이죠. 그러므로 그냥 api reference 페이지를 사용하는 건 rest api를 사용해서 rest하지 않은 api를 알려주는 것 뿐입니다.
@@codingapple물론 시중의 REST API들의 99%는 JSON을 사용하는 HTTP RPC이지만, 그렇다고 JSON을 사용한다고 RESTful하지 않다고 단정할 수는 없습니다. HTTP의 입장에서 보면 JSON은 미디어 타입일 뿐이기에, JSON 안에서도 충분히 hypertext를 표현할 수 있기 때문입니다. 예: JSON HAL, JSON Hyper-Schema
@@wocnjdoqnqkp저도 이 의견에 동의합니다. 논문 저자가 말하는 Hypertext-driven 중에서 지금 이 스레드에서 논점이 되는 부분은 HATEOAS에 대한 것으로 요청의 결과로 반환되는 데이터의 유형을 정의하는 것이 아닙니다. 고로, “JSON을 전송하는 순간 REST API 원칙에 어긋난다“라고 말하는 것은 Hypertext-driven 해석의 오류라고 봅니다. Hypertext가 HTML을 가리키는 것이 아니니까요. HAL은 이 HATEOAS를 만족시키는 훌륭한 표준이라고 봅니다.
1.htmx 상용화 됨 2. 백엔드 api 응답을 html로 변환 해야 함 3. api 응답값을 html로 자동 변환 해주는 미들웨어 등장 4. Response 사이즈 줄이려고 모듈 추가 됨 5. 중간과정 추가 돼서 퍼포먼스 떨어진다고 프론트엔드가 위 처리를 대신하게 함 6. 일부 브라우저에서 문제 생긴다고 babel 설정 필요해짐 7. 추가 기술 등장 … 웹 시장이 이렇더라구요..
마지막 멘트가 핵심 ㅋㅋ
VPL 중에서 PPTX, DOCX 주로 다루고 있는 저와 같은 사무직군에게 참으로 반가운 소식입니다. CSS와 LaTeX도 당당한 프로그래밍 언어로 인정받는 날까지 응원합니다.
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
이러다가 png랑 json까지 프로그래밍 언어 되겠네 ㅋㅋㅋ
@@sloan00ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
@@sloan00 엌ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
ㅋㅋㅋㅋㅋㅋㅋㅋcsv도 넣어줘잉
코딩애플형! 앞으로도 이런 트렌디함 부탁한다구우~😎
물론 안쓸거라는건 함정
제목보자마자 개빡쳐서 들어왔다가 수긍하고 갑니다ㅋㅋ
5:01 수상하게 트렌드 반영이 빠른 프로그래머
도리도리 짤 말하시는거져? 저거 뭐에요?ㅋㅋㅋㅋㅋ
@@Vinjae봇치더락 뮤지컬?이라네요
무무무무무무무
난 프로그래밍 진짜 쪼끔 배웠을을 뿐인데 왜 이런거 구독하고 보면서 배우고 싶어서 가슴 두근두근...거리냐고.. 하..
태생적 프로그래밍 변태 ㄷㄷ
이런 건 또 어디서 알아오셨데요? ㅎㅎ
좋은 정보 감사 😊
실컷 약 팔아놓고 맨 마지막에 자기는 안 쓴대 🤣
왜냐면 다 갈아엎어야 되거든요...
특히 팀 개발 같은 거 하시는 분들은 다 허락을 받거나 해야되는 거라 귀찮아서 안 하시는 거겠죠
해외에서 개인 프로젝트할때 htmx + tailwind 같이 쓰는경우 진짜 많음. 유튭에 클론 코딩 영상 예제도 많음
국내 취업만 생각했을 때 해당 스택 사용하는 게 도움이 될까요?
@@justhighway글쎄요.. 한국 취업시장에서 해당 스택 사용해서 얻는 이점이 딱히 없을꺼같아요
흥미롭지만 고민이 되는 부분이네요 ㅋㅋ,,
간단하거나, 개인 프로젝트는 사용해볼법 하지만 회사에서 사용하기에는 한계가 있어보이네요. 현재 서버 API들이 대부분 json 반환형태인데 htmlx로 하려면 기존 API들을 싹다 고쳐야할거고.. 프로젝트 크기 커질수록 리액트처럼 컴포넌트로 파일 관리하기에도 어렵겟네요
1:22 형... 붕탁 세대였구나?
어쩌다가 말실수 했는데 “설마 html을 프로그래밍언어로 아는거…아니지?”라고 한 친구가 생각나네요
상당히 마음에 드네요.. 한번 써봐야겠네요 호기심으로라도 ㅎㅎㅎ
1:40 맞지 이게 근본이지!
"물론 저는 안쓸거구요"
ㅋㅋㅋㅋㅋ 나중에 대중화되면 그 때 써도..ㅋ
임베디드 웹이라 저런거 쓸일 진짜많은데... 회사코드 이걸로 다 쓰면 진짜 좋을거같은데.... 이건 진짜 팀장님한테 보고해볼만한데....
멈추시오...
@@KylloxStudioㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
저런거 쓸일 진짜 많으면... 저걸 진짜 많이 해야하는거 아닌가요...?
간단한 기능들만 있는데 이 기능들이 너무 편하긴하다
이건 호재야!
좀 많이 애매한거같은데...
html 보내주는 백엔드는 뭐 조상님이 만들어 주실것도 아니구
자료를 html 로 보내기 시작하면 확장성도 참담하고
상태관리 제대로 한다고 생각하면 눈앞의 코드 몇 줄 줄이는게 크게 의미가 있나 싶기도 하고
객체 지향 프로그래밍을 좋아하는 입장에서는 솔직히 좀 끔찍한 접근방법이네요
좀 복잡한 웹앱 만들때 쓰기에는 터무니 없구요
간단한 사이트 만들때는 좋아보이는데
사실 간단한 사이트는 워드프레스나 아임웹으로 만드는게 더 나아요
그냥 리액트하세요 스벨트 쓰던지
왜 상태 관리를 클라이언트에서 하려고 하나요... 애초에 복잡한 상태관리를 클라이언트에서 하는것부터 끔찍한 설계방식입니다.
@@kim-lg7rchtmx에서는 상태관리를 서버에서 하지 않나요? 해당 영상 보고 그렇게 이해했는데 혹시 제가 잘못 이해했나 싶어 질문드립니다
@@donghyun1998 리액트를 말한거였습니다
@@kim-lg7rc 아이코 제가 문맥 파악을 못했네여
늦은시간에 빠른 답변 감사합니다~!
호, ..이건흥미롭긴하군요
새로운 종류 같아서 좋네요
어그로 끄는 법을 너무나 잘 알고있는 유튜버
htmx를 워드프레스에서도 쓸수있나요?
지금 보니까 되개 간편하게 보여줄수있을거같은데
와 마지막 한줄요약 지리네
더도말고 덜도말고 딱 이 영상에 나온 프로젝트와 같은 경우에만 쓰면 되겠습니다…
깃갤러이실듯😂 좋은정보 감사합니다ㅎㅎ
5:01 이게 킬포 ㅋㅋ
궁금한 게 생겼는데 왜 JSON 형식으로 보내면 REST한 API가 아닌걸까요? HTTP Method(POST, GET, PUT, DELETE) 기능외에도 어떤 조건이 있나요?
"그런 rest api로 괜찮은가“라는 강연 추천드립니다
@@kdh8219code-on-demand 제약 조건때문에 그런건가요? 선택적 제약 조건으로 아는데…
하이퍼링크가 없어서 그렇습니다. Rest api로 받아오는 정보로부터 또 다른 api를 받아올 수 있는 구조가 되어야 해요. Json api는 서로 관련되어 있는 api도 네트워크 상에서 보면 사실 모든 api가 endpoint로 전혀 관련이 없고 독립적입니다. 각각의 api는 자신 이외의 api의 존재조차 알 수 없습니다. 즉 api의 연관성을 알기 위해서는 rest api가 무조건 필요한거죠.
api reference 웹페이지를 통해 json api들의 연관성을 알 수 있지 않냐고 하실 수 있는데 웹페이지 또한 그냥 브라우저가 요청하는 html api입니다. 그냥 브라우저가 api를 유저 친화적으로 볼 수 있도록 렌더링해주는 것 뿐이죠. 그러므로 그냥 api reference 페이지를 사용하는 건 rest api를 사용해서 rest하지 않은 api를 알려주는 것 뿐입니다.
@@kim-lg7rc 실행 가능한 코드가 없기 때문이라는 말씀이신가요??
@@user-ue2eo1ed5f REST HATEOAS를 검색해보세요. 코드의 여부는 상관없습니다. html도 코드는 아니지만 rest하니까요. 간단하게 말하면 api response에 다른 api에 대한 url(하이퍼링크)을 적는 표준이 없기 때문입니다.
간단한 개인 프로젝트엔 써볼만하네요
일단 어그로 하나는 뒤지는 제목이네요
1:22 😊
React는 너무 장황하고 htmx는 너무 간결하니 SvelteKit을 쓰겠습니다.
스벨트 붐은 온다
여러분 스벨테 봄이 온다 봄이 온다 하는데, 그 봄 어디 갔습니까? 허풍입니다 허풍!
스벨트 봄은 온다!
스벨트 봄은 온다!!!!!!!!!!!!!!!!!
스붐온!
와 개미쳤당
JSP 같이 서버사이드 렌더링의 성격이 강한 것 같네요.
진짜 좋아보이는데.. 써보고싶은데.. 군대네..
HTML은 프로그래밍 언어가 아닙니다 (소근소근)
그래서 htmx 만들었잖슴
너 귀엽구나(핥짝)
그럼 css는 프로그래밍 언어인가영
@@1000qur cascading style shit
@@Luxusioshit ㅋㅋㅋㅋㅋㅋㅋ 속마음인가
막줄본문 뭔뎈ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 기껏 열심히 설명해놓고
역시 끝까지 들어봐야되 ㅎㅎ
회사에서 쓰는 프레임워크가 딱 이런모양임..
딥러닝 모델 배포 서빙 강의도 하나 만들어줘 형
오 좋다!
마크다운도 좀 저런거 할 수 있었으면 좋겠다
「역시」!?
이거 리액트 같은거에 끼워넣을 수 없나요? ㅋㅋ
마지막이 포인트입니다...
json 쓴다고 rest 가 아니라고 하는게 좀 황당하네요. 그냥 쌩 데이터만 내려주니까 그런거지 odata 처럼 resource 를 representation 할수 있는 포맷으로 주고받으면 rest 맞습니다.
게다가 저 htmx 는 정확히는 full html을 내려주는게 아니라, html slice를 내려주는데, 그러면 이게 오히려 rest가 아닙니다. html 처럼 생긴 xml 이 내려왔다고 해서 그걸 rest 라고 하면 전혀 개념을 잘못알고있는거죠
간단한 사이트정도는 다른 라이브러리 쓸바에야 이걸 쓰는게 빠르고 효율적일듯?
스파이더맨 때문에 콧구멍에서 물 나왔네
역시 사람말은 끝까지 들어야 함 ㅎㅎ
오 써봐야지
오늘부터 이거다
마지막 멘트가 이 영상의 핵심입니다
멘토는 누구인가요
@@user-bs6yc5sl3f 앗!!!! 이런 ㅠㅠ
챗gpt도 html은 프로그래밍 언어라고 했음
결론이...?
1:45 json 데이타를 응답으로 보내는 REST API 가 아니라는 말이 이해가 잘 안되네요
저도 궁금…
저두
roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
@@codingapple물론 시중의 REST API들의 99%는 JSON을 사용하는 HTTP RPC이지만, 그렇다고 JSON을 사용한다고 RESTful하지 않다고 단정할 수는 없습니다. HTTP의 입장에서 보면 JSON은 미디어 타입일 뿐이기에, JSON 안에서도 충분히 hypertext를 표현할 수 있기 때문입니다. 예: JSON HAL, JSON Hyper-Schema
@@wocnjdoqnqkp저도 이 의견에 동의합니다. 논문 저자가 말하는 Hypertext-driven 중에서 지금 이 스레드에서 논점이 되는 부분은 HATEOAS에 대한 것으로 요청의 결과로 반환되는 데이터의 유형을 정의하는 것이 아닙니다.
고로, “JSON을 전송하는 순간 REST API 원칙에 어긋난다“라고 말하는 것은 Hypertext-driven 해석의 오류라고 봅니다. Hypertext가 HTML을 가리키는 것이 아니니까요.
HAL은 이 HATEOAS를 만족시키는 훌륭한 표준이라고 봅니다.
흣틈스 언어 좋네요
개쩌네
알림 보자마자 못 참고 누름 하
코파일럿이랑 ChatGPT랑 비교하는 영상 있었으면 좋겠네요.
쓰임새가 다름
봇치야 그게 무슨 소리니? 5:01
와.... 차세대 html이다....
저거 사용하는 회사 많아지고 그러면 프론트엔드 문턱 확 낮출 수 있겠는데요...
과연 그럴까요?? 취업문턱은 계속 높아짐. 하두 기술이 계속 나와서 ㅋㅋ
1.htmx 상용화 됨
2. 백엔드 api 응답을 html로 변환 해야 함
3. api 응답값을 html로 자동 변환 해주는 미들웨어 등장
4. Response 사이즈 줄이려고 모듈 추가 됨
5. 중간과정 추가 돼서 퍼포먼스 떨어진다고 프론트엔드가 위 처리를 대신하게 함
6. 일부 브라우저에서 문제 생긴다고 babel 설정 필요해짐
7. 추가 기술 등장 …
웹 시장이 이렇더라구요..
이건 또 처음 보네요 와.
htmx 사용 기업 사례 발표를
djangocon 에서 했군요 호
소감 : ”느낀 희열감은 엄랭과 크게 다르지 않다“
뭐야 안쓰는 이유 가르쳐주시고 가세요 ㅠ
진짜로 저걸로 개발이 해결된다고 믿으면 당신은 초보~
real world 프로젝트 사용 사례가 있습니다. Htmx로 대부분의 웹사이트 기능을 구현가능합니다.
th-cam.com/video/3GObi93tjZI/w-d-xo.htmlsi=AgzR27BaxjtmKQlT
내가 지금 멀 본거지
아니 마지막 한 마디가 핵심이잖아욬ㅋㅋㅋ
말투가 군대 같아요 ㅋㅋ;
좀 쩌네
저 법전 어딥니까?!~~
펑션할것만 넣고 그냥 클릭만하면 클릭펑션이 되는군요.
그런데 예제에서는 어쩔땐 기존 텍스트가 덮어씌워지고 어쩔땐 유지가 되네요?
팡션??그런 것 너무 쓰지 마새요
개쩌노
프론트와 백이..뒤죽박죽 될거 같은데..
헐; json이 REST하지않음?
재믺다~
포폴 사이트 만들때 하나 만들만 할지도?
핵심 : 안쓸꺼다
html의 성능 향상이 아니라 js입니다.
물론 알고 어그로 끄신거 같지만…
어그로 장난없네. 조회수 올리는 방법을 알고 있음. 제목보자마자 흥분해서 광클함
"물론 저는 안 쓸거구요"
다시 ㅋㅋ 거꾸로 가내 ㅋㅋㅋㅋㅋ
와;
몰라 난 streamlit 쓸거야~ html 하나도 몰라
컴포넌트가 뭔지 설명 해주세요!!&
최근에 깃허브 보다가 알게돼서 써봤는데 처음엔 편했는데 쓸수록 한계가 보이더라고요.
걍 간단한 포폴용? ㅋㅋ
많은 프레임워크들이 그랬듯이 나중엔 어떻게될 지 모르죠. 아직은 비교적 초기니까...
혹시 어떤 한계가 보이셨는지 구체적으로 알려주실 수 있으신가용??
편해 보이기는 하는데... 흠...
발작버튼 ON
xhtml 도 있는뎅
결과가 json이 아니고 xml 을 가지고 오는?
flex 붐은 다시 온다
간단하다고 했지 쉽다고는 못하겠다
ㅋㅋㅋㅋㅋㅋ 물론 저는 안쓸꺼구요!
아 아무튼 language라고~
htpl
저도 안쓸겁니다
응..응애
뭐이리 쉽고 재밋냐
뭣
오 좋네! 안써야징