100%. The JS community didn't lose me with React. They lost me when people started converting their blogs to React and locking themselves in to server-side javascript and proprietary cloud-products-build-on-other-cloud-products in order to use their front-end frameworks. But React is still a good solution for me when I need a highly interactive SPA. And yes, I have to develop it as a separate application from the server, both with a sensible API, state machines, etc. Pick the right tool 🤷♂
Yeah let me switch my company website to an SPA in some parts, sometimes, somewhere, oh wait the shitty technology can't support that and it barely integrates. What if we just SPA?Oh it works, cool.
That article had the "He is confused but he has got the spirit" energy I agree with his take that things have gotten so complicated over the past few years but whatever he was creating didn't make much sense.
@@theodorealenas3171 Managing state and dom was as total mess, so frameworks like Angular and React came onto the scene to try and manage those issues. Arguably we've gone way too far the other way, but the younger devs won't have experienced the problems that led to those frameworks, so their new solutions may just end up taking us backwards. However, maybe the platform as a whole is now so much better that those more direct solutions are now viable again. I don't know xD
@@michalkowalik89 Right? A controller is nothing but a glorified switch statement. And framework people build entire vast hierarchies of the darned things!
And this is how EHTML framework has born. I'm not joking, the author transformed this into a framework, I'm find it interesting and constructive, very cool article for just thinking things different
Thanks for the feedback. Actually I created this framework 4 years ago, just because I wanted to quickly make AJAX requests and map responses to HTML without the need to create elements in JavaScript. This article was written just to demonstrate the idea in vacuum. Also, I have ideas on how to introduce type safety via linter into this concept.
his approach reminds me of these super verbose xml protocols where you had a hundred elements with a hundred attributes and all it did was "int i = 1; i = i * 2". Getting nightmares from his example but I like that he's trying. I myself have went back into pure html + js and tried to reimplement mechanisms that transform page layout and reactivity in a clean and concise manner without a 500kb framework in the background. it's a powerful learning experience and it's making me want to rewrite my website for the n-th time, without a framework.
@@theodorealenas3171it usually doesn’t. There’s generally no need to use something like React, Angular, etc. for a personal website and most people who do so seem to do it just because they stick with what they already know and try to use that for everything.
8:10 Read from the article, "You can already imagine how much easier it is to share state...." Imagine writing that as if it's a good thing lol. Shared state is basically the source of all spaghetti.
@@dripcaraybbx Not very spaghetti because that's a static HTML file that doesn't need or js or any mutable state at all. I don't really see how that's a fair comparison to a stateful application.
@@avwie132 This does not negate high binding. Your components depend on another component and wait for a value to be initialized. Also, if you want to change the state structure and don't know who is using what, you will break the application because of the high coupling. So this approach doesn't scale. But for small sites it will do fine.
I used Handlebars or Mustache with template tag and vanilla js so you can inject js variables and you have a decent template language with if, foreach, etc... It works and it is pretty straightforward
Look up Mark Turansky's "Better JavaScript Templates." ASP-style templates that support native JavaScript without a template language. Sometimes less is more.
Hey, I read a book and finally understands what this sentence means. Curious, will there be a push one day for new hypermedia controls to fill in the gaps that client side stuff is doing rn?
Specifically, application state (ie the domain model) should be parallel to the view model. Embedding state within the components that isn't totally isolated to the components is OOP goop all over again. Allow the components to access/bring in the application state, but don't embed that state within the components
Btw, what the author proposed is actually a lot how oldschool AngularJS used to do things. You would include the AngluarJS in script section, define a template element, create a service that would hold some state, and bind it to the template html.
I’ve been building web apps without front-end libraries for the past year. I don’t use this guy’s approach with the template tag, but for me I find it much easier to just append to the Dom as needed. This idea that the code becomes unmanageable is a self fulfilling prophecy, not an actuality.
@@Niosushonestly I'd take jQuery over these heavy modern frameworks and npm package hell any day. Remember when you could just add jQuery as a script tag from a CDN and be done with it? You don't even need jQuery to do it any more now that modern JS has more features and IE is dead, you can just use vanilla JS easily
I made my site's menus with JavaScript, while the rest was hand written HTML. Then I was sorry that Emacs' web browser couldn't render it and I redid it in PHP. But how: the PHP tag opens inside of the markup, to give attributes to the elements. It took several iterations before I accepted there's only going to be 4 menu elements anyway
@@georgehelyar yeah I was thinking the same thing. I know Jquery is still around but it’s kinda obsolete with modern js updates. Also jquery syntax is awful to look at.
Generally, it's more desirable to distribute work and memory requirements to clients I think. Not everyone is a company that has resources to stream _videos_ to viewers globally
Not a fan of this approach. I've never once needed to rely on an element's attributes to manage my state except maybe for styling purposes. I'm not the biggest fan of React either but even hooks aren't as unwieldy as this.
@@EdwinMartin I have, when I was a noob. Great argument btw. I've never driven with my back to the wheel either; I still know it's a sh#t way to drive.
It is okayish, but lacks foundation and the template should not say what happens and where but I think it’s totally fine to subject those topics. The framework hell is not a good solution. I am awaiting the proposals that are there for ES to come like the NodeParts, placeholder in templates and the new redesigned html imports.
I am the author of this article, you can check EHTML to see a really good examples where I am mapping AJAX JSON responses on html templates just using HTML.
That's roughly how I make use of templates where I can't make use of frontend frameworks, but the articles arguments are not really correct because they didn't even solve what those frameworks solve. It's fun to replicate what these frameworks do and I did so myself to understand how Vue, for example, achieves their reactivity.
I'm more a designer than a dev today. but my background is in Front End. last time I was doing just. a favor for a friend to help him launch their startup. It was just a website, just a F# website. not an application. it was being dealed by their front-end team. I'm pretty good at HTML/CSS (I know its not programming) so I can draw then build what I done. gosh, how much EASIER would be if I could not use NEXT JS there!!! build processes are horrible. it it was just a static site, they would not be "screaming" at me because THEIR SERVER had an incompatibility with next 14, and I need to go back to 13 and change everything I done just. to help a friend (I'm questioning if it's still my friend btw). HTMX and etc. seems like a breath of fresh air. a fixing on the hell developers look like they have conspired to make. definitely DONT use these to make just simple websites! it's painful.
Indeed, Webdev is such a convoluted mess of misery and tangled frameworks! Then again... developing for Windows UI, with Microsoft continuously reinventing Windows UI programming in ever worse ways isn't much better. Then you've got the multiheaded abstracted monster that is modern C++... I guess the ticket is: just stick with embedded programming in nice beautiful simple C!
The web is great, the problem is it's every script-kiddies first exposure to programming so there is going to be a lot of stupid shit. That said if you are the one setting the rules it's just as fun as any other platform because you can use the smart and throw out the stupid.
mxml and actionscript was the best front end language ever.. databinding both ways, treeviews, treetables, accordion, they have them all you name it.. unfortunately it needed a flash plugin to run in the browser.. and now its dead.. thing is html is like 30 years old and was never meant to build UI.. so what we have now is like a tech soup just to have something decent running in the front end.. i think its time they reinvent the wheel so browsers support better languages so we can use 1 language to build the UI.. i dont understand that they dont understand the problem here..
Re: 10:55 - Virtual DOM is meant to win against `el.innerHTML = ''; el.innerHTML = renderTemplate(data);` (which it does), not against pinpoint data manipulation to do exactly what you need.
@@mkvalorI'd like to see the receipts but I would assume they are similar in cost. If you consider that all mathematical operations in a computer are just addition operations then adding zero and multiplying by one should end up being the same operation. The actual conversion that happens before the mathematical operations will probably vary in time but should be consistently tied to the features of the inputted values (like the length of the input).
I hate both. I prefer the code the speak for itself. Unless the programmer is well read on the quirks of Javascript's insane type system. I prefer to just see a parseInt or parseFloat. He's not being clear and concise with his code. He's just being a smartass.
I once worked at a company that used a custom framework that was actually based on php + templates + jQuery, worked pretty much like this. It worked I guess, but all the tags are still in the inspector even though they dont show up on the page. that alone killed it for me, coding for it was a mess.
Really? I also did something like template elements that only show up on inspector, in a previous iteration of my site, I liked it. You could see how templates expanded over time by looking at inspected eelments
@@theodorealenas3171 I mean I wasn't a fan of showing the user code that he shouldn't have access to yet and in a raw form. But it's far from the worst thing I ever worked with lol
@@refeals Shadow DOMs are still accessible to the user so I'm not sure where the concern is of "showing the user code that he shouldn't have access to". Anything client side is inherently viewable.
Move to the Phoenix Framework and Liveview and all the js madness goes away, true server side state ... on the server, and handle updates via tiny websocket data calls to make the dom reactive. After 20 year writing JS... Liveview is just so much better
LOVE seeing the move toward Native JS! The APIs are SOOO easy these days that there's almost no need to use a framework so long as you just have good code organization habits. A senior has virtually NO problem working in that environment. BTW, most frameworks STARTED OUT as proprietary systems that eventually became abstracted enough to use across any project. (Pssst!... The framework giants don't want you to know this)
I feel like the issue with most modern frameworks being they let applications grow in a natural way. Using templates and traditional backend services without the need for dependencies generates understanding while developing. It's like leveling your way to max level instead of using an xp scroll. If you use the scroll you miss out on understanding how the skills work and lose the understanding of how to generate a "symphony". Like my embedded experience relates to writing linux components which relates to writing web servers which informs security and how to write large software projects. I can make a course graph if needed. The reason why "jumping into the deep end" is probably not a wise decision.
Isn't Vue doing similar things like this, but way better? I've learned Vue during covid and I'm such a fan, and I feel Vue is doing what this person is trying to do. But better.
All I can say is "hallelujah"! I never understood replicating all the state on the client with complicated frameworks. Sure, it works great for Facebook, but most apps aren't Facebook. So much easier to just bring down the HTML with SSR, and adjust the pages as needed with vanilla js. Btw as a C#/vanilla JS/Azure programmer about 3/4 of Prime's stuff goes right over my head. OK, maybe 7/8....
Noob question but if htmx has to make server requests for html, what happens to a user in Australia using a website which has servers in the US? Isn't it just slow and unresponsive
No, the difference is the client asking the server for html snippets vs the client asking the server for json. You keep the delay between request and response, but you reduce the javascript overhead. You likely even get a more responsive website with htmx because there is no need any more to have consecutive ajax requests for loading a single page.
These minimal frameworks are and always will be a bad idea. After almost a decade of trying out all the frameworks under the sun and attempting to make my own probably a dozen times these are my conclusions: - most websites do not need a framework, npm, or a build system of any kind - the best libraries are usually the ones that are just a single js/ts file you can hotlink or copy into your project - forking said minimal libraries to add your own features is the correct approach, don't hack an abstraction layer or plugin system ontop - typescript is worth it, but only when you're creating libraries - webcomponents kinda suck, but they are great for implementing progressive enhancements
“You can come back to the good old days and simply enjoy writing HTML”. To me those were never good old days and I absolutely hated writing HTML/CSS. So glad that there are frameworks out there taking care of all that, so I can focus on writing functionality.
Global 'window' is legacy. But that doesn't mean we have to reference it every single time. You can ask window as argument in every function and that's what I prefer to do. This creates the annoying problem of prop passing which I consider a good problem to have because this forces to think about application design.
I hate how the author dismissed the name collision problem. Naming is one of the 2 hardest problems in programming (right besides caching and off-by-1 errors). "Just name better" bro that only works with a counter button page. The point of components (doesnt matter if its web-components or JS frameworks) is that I can have a 100 separate counters without bloating the global namespace with counter-1, counter-2 etc. I also can use a "counter" state in an other component and don't have to worry if it's already been taken in this particular page. And I can create a component library that matches the company design and build a website like lego. I don't have to copy-paste 10s of lines of complicated markup every time I want to render a datepicker (that argument is pretty weak actually because its solvable by server side templates or whatever this thing he proposes. It's just an argument against vanilla HTML+CSS+JS for more complex sites). I'm not advocating for a heavy JS framework but I'm saying we need a good system for creating semi-isolated(with access to both global and local state), reusable components. Web components suck, React is a bloated mess and HTMX is just an utils library for vanilla HTML so that you can modify parts of markup without reloading (it doesn't really solve my main issue). There's no good solution. Also, React has no real alternative in the mobile app world. And btw on mobile you can throw your HTMX mindset of sending hydrated HTML to the client out the window.
I still believe that jails-js is a better alternative about "diferent way to think". There are too many solutions full html or full js, and very less alternative like Jails which is use html and write logic on top of that without losing your mind... It´s not because I thought about it, but I can´t see anything alike... and I wanted to see more... Not a React/Angular fan... not a htmx fan either... they live too much in the extreme edge for me...
A framework i love that is using templates and a way to integrate state into the templates is Lit. I find it to be a more elegant solution and its a very small framework, but not very popular Initially it was an idea similar from your video called Polimer (the first version of Lit)
There's a JS library called reef.js, it adds the concept of signals to vanilla ja and works well with web components because the author is a vanilla js/web component fan
This is one reason we use frameworks, so we don't have to deal with every codebase maintaining its own (to be blunt) crappy solution like this. In vanilla JS, everyone just comes up with a different crappy solution. With a crappy framework, at least we're all using the _same_ crappy solution. (Though it doesn't have to be crappy--some frameworks are good.)
@@dripcaraybbx Web developers who use a framework. To elaborate: if an app uses React, even though I don't like React, and React has a _lot_ of problems, at least I can read and contribute to the code (usually). But if an app uses vanilla JS, I probably won't be able to easily decipher their codebase, let alone contribute to it, unless every previous main contributor happened to be excellent at designing and writing maintainable code, as well as documenting it. For example, it would be annoying, if not difficult and very time-consuming, to read or contribute to an app written the way the code in the article is written.
@@GrantGryczan On a large project, I feel like this is what a team should be able to do. The architect or senior devs should be able to define a library or abstractions based on a ubiquitous technology that doesn't lock them into a dependency. So, as long as users have browsers, why not develop the internal framework that works for your entire team? Better than than install all those stupid React files on build (just because that's what Facebook needs) or replicate the DOM.
@@dripcaraybbx Yeah, that's what every great developer should be able to do. And I wouldn't doubt that you, I, or any senior engineer at a big tech company could do that. But many (if not most) developers, at companies that can't afford to be picky, simply don't know how to write maintainable code. A lot of developers I see at workplaces only have experience from courses they took in college for a bachelor's degree. They never touched anything even remotely programming-related outside school, and they still don't outside work. They cruise at the knowledge level school left them with, because hey, they make a living, and that might be the only aspect of software development they care about. Good for them! So if I were to join a project, I wouldn't trust a vanilla JS project to be enjoyable to work on as much as I would a React project. React is a really crappy framework, but at least the level of crappiness is much more limited by the framework than it would be if written with the freedom of the entire realm of possibility of vanilla JS. When I join a project using a framework, I know exactly what I'm getting into, and I can use my prior knowledge of the framework rather than having to get used to what is most likely going to be a tightly coupled ball of spaghetti written in vanilla JS, such as the not-that-maintainable code from this article (although I've seen much worse). And that's not to say framework code can't be unmaintainable or tightly coupled, but just that framework code is infinitely more limited in the ways it can be.
@@GrantGryczan If React is a crappy framework compared to other libraries built on the same JavaScript, I would say it's a function of the framework not JavaScript
These people are the motivation why I'm intending to learn HTMX and I really hope the rest of the world will do the same. This madness has to stop. Now.
@@MissViolettaBI think the philosophy of using http like it was intended is the selling point. The actual library seems like more of a proof of concept. I think you could very easily employ the philosophy of htmx into your vanilla app without actually using the htmx script.
"...only to then turn around and use a library which calculates diff between DOM and Virtual DOM and does those direct manipulations anyway." First thing, it is not calculating difference between DOM and Virtual DOM, rather it looks for difference between old Virtual DOM and new copy of Virtual DOM that has changes, confirms what the changes are and then updates only what is needed on real DOM. Second, it's not direct manipulation because it's not us directly manipulating it, automatic system does it based on how state changed and that's the whole point of these libraries.
I hate when my server returns html. Html response means that you don't have any control of your data on the client side at all. Also, all of your endpoints began to look ugly. Also, it oddly separates logic- and logicless parts of your html. I want my APIs to return some helpful format (mainly json, of course). But I found the perfect solution for me: use htmx alongside nunjucks in case I need some data manipulations on the client side or use mustache otherwise.
He started off good but then it became another mess of figuring out the magic keywords to do stuff in the templates which I find annoying in all the other frameworks as well. I recently dabbled with something similar but where I instead use java class to define components each with their own template and proxy for model mapping so it can re-render itself in the dom on model changes. Furthermore I used Javascripts lovely untyped prototype stuff to auto generate functions on the fly for the classes so that you can programmatically set styles, classes and update model as if it was a poco (plain old class object). So in a sense it feels more like developing a desktop application in the good old days, here is an example: class MyApp extends App { constructor() { let para = this.add(new Paragraph({ class: 'my-paragraph' })); this.add(new Button({ text: 'Click me' })).setBorderWidth('5px').setOnClick((button) => { para.setText('Hey stop clicking me!'); // auto function to template props button.model.text = 'Ouch!'; // example to set model directly on button }); } } new App(); App inherits a Container class and has a default column layout using FlexBox, but any container can initialize their own FlexBox with whatever layout they want. All base components have functions for setting all style directly or several can be set by using a object, for example para.setStyle({ padding:1, fontSize:2 }). Each container can have their own base unit, default is rem and 100% font-size on body as it is then easy to adjust size of whole UX by just modifying body %. Ofc any can set class (and have helpers for adding/removing) so if you want you can add plain css files yourself as before to style everything. You can ofc make your own components and even just write your event handlers directly like this: class MyButton extends Button { onClick() { this.setText('Touch me again...'); } } Using setOnClick() will override the default onClick implementation. A cool thing is also that the CSS classes are injected in the page head dynamically so it is quite easy to define some variables that is used to parameterize the styles and hence does not need any preprocessors. Basically the goal of the project was to have plain JS without the need to compile anything to get stuff running, although the auto-prototyping on the fly is a sort of compiling I guess. Creating new components ofc requires you to specify your template (simple string expansion from model variables). Still early days but it works quite well and the fun thing is that I can code in plain Javascript to create a frontend with no mucking about with typing in bindings between html code and the javascript code.
No, var at the top level of a script is on the window, const and key are block scoped see codepen DOT io SLASH anthonybullard SLASH pen SLASH RwdrGrR (thanks YT for making me do weird stuff to make url appear).
looks cool, did know about that. I am the author of this article, I created EHTML, it works in a similar manner, but also allows you to fetch JSON and map it to the tamplate.
Not just about what convivences we choose to develop with, these are the crappy performing behaviors making websites we end up being users on. React , tailwind et al encourage bloat and soppy architecture. It's obnoxious waiting for a frame to load that then fetches the content, then has to render that content, then update that content, then finally display that content and wait for interactivity; and that that isn't something that occurs only for the first load on a lot of "websites". Meanwhile memory usage skyrockets and if your one a phone you now have a heater with a dying power source in your hand. And userscripts and userstyles to fix these sites become harder and harder to make and maintain because of generated html divitis soup because more and more developers are given up on learning how to name things.
4:54 Wrong. Global constants do not become properties of the window object, unlike var variables. You can confirm in in the browser in 2 seconds, have a look at window.constantYouSet - its not on there my guy.
YUCK. I'm done writing client side applications. I'd rather write htmx in an actually comfortable language like ruby than do crazy wasm stuff that's still going to end up calling JS at the end of the day@@thebrowhodoesntlift9613
I haven't tried HTMX yet, because I want to build THICC CLIENTS. I'm a novice dev choking to death on React and wondering why the ideas of HTMX aren't more client sided?
Wait, so you're telling me the things I've been doing for the last two decades, because I hate the state of web dev, might suddenly become hip again? Maybe I better break out that pair of Jenkos and oh! That one t-shirt I still have with the picture on the back!
I did something very similar with vanilla JS that rendered data from microservices - it was before the term microservice was popularized, just little boxes like "address entry box" or "what services are available at your location" kind of boxes. Later saw hoe people made "microservices" in the "processional" way and nearly vomited how much abstraction layering libraries were involved lol - and they still made more work...
@@avwie132 It was definitely what microservices really are. Just you guys I am sure do it the suckful way instead. It was literally a full service with back+frontent that you could plug&play drop onto literally any page or site or whatever and was hosted elsewhere. What else you want? If you want anything else you are overcomplicating what it really means to do microservices. And guess what - they had to communicate and no still no need for fancy libraries for that. Originally it is a very good idea that for example enables different companies to work on different parts of much bigger projects and product simple self-contained module-like stuff that is hosted at various places (or the same machine if you configure it that way - but it depends on where you deploy). Again I really ask what you consider microservices if not this? PS.: Guess what but you can even do microservices without JS and only using htmx too haha
How does HTMX solve the problem of syncing client & server-side state? It seems like you're right back in state co-location hell the second you have a client-side action that changes server-side state, but can't wait on HTTP w/o killing UX.
It solves it by not having client side state in js, the state is the html markup. Every click is basically sent to the server, which modifies it's state, and sends back the appropriate html fragment. If you have some highly interactive components like maps or sheets, you need to implement it by vanilla js or some framework. But for any basic state change like count++ or appending a row, it's perfect.
this style can be called creative programming, when you create solution for the problem you meet along the way, rather just use the tool other handed to you and follow instruction
Coming from a perspective of playing with free web hosting that only allowed client-side scripting I can see this would be useful in that context but not to any level of complexity. Having said that I did once generate an IndexedDB by scraping the data- attributes of a massive webpage listing hundreds of publications with multiple ways to filter them down.
random but the first react example is incorrect iinm; to set state based on previous state, setCount(count + 1) should be setCount(prevCount => prevCount + 1)
@@wlockuz4467 ahh I see -- I just checked the docs. "This is not an issue until you attempt to read state soon after you have set it (setting state repeatedly is an easy way to the issue)." Though, there is an Eslint-react rule against this since it should still never be written like this -- there's no guarantee that someone else later will just know this behavior. react/no-access-state-in-setstate
These frameworks were meant for Single Page Applications, not the whole company website.
this is so true.... the feature creeping is so insane nowadays
100%. The JS community didn't lose me with React. They lost me when people started converting their blogs to React and locking themselves in to server-side javascript and proprietary cloud-products-build-on-other-cloud-products in order to use their front-end frameworks. But React is still a good solution for me when I need a highly interactive SPA. And yes, I have to develop it as a separate application from the server, both with a sensible API, state machines, etc. Pick the right tool 🤷♂
Yeah let me switch my company website to an SPA in some parts, sometimes, somewhere, oh wait the shitty technology can't support that and it barely integrates. What if we just SPA?Oh it works, cool.
react is a lib, not a framework
@@tri__yt I agree. People lose the distinction of website and app. And if you are in the middle (Nextjs), that seems to be the worst place to be
"the DOM is slow"
> What if we had two of them?
That article had the "He is confused but he has got the spirit" energy
I agree with his take that things have gotten so complicated over the past few years but whatever he was creating didn't make much sense.
Hi, I am the author of this article, you can checkout EHTML, hopefully it would make more sense for you. Cheers!
All of your videos are so jam packed with information and your character makes it so easy to ingest! Love it
This comes from the mind of someone who only knows frameworks.
We will forever repeat the mistakes of the past.
I don't know how to interpret this, but you got my attention. How would it be from someone who's only seen the framework light approach
@@theodorealenas3171 Managing state and dom was as total mess, so frameworks like Angular and React came onto the scene to try and manage those issues.
Arguably we've gone way too far the other way, but the younger devs won't have experienced the problems that led to those frameworks, so their new solutions may just end up taking us backwards.
However, maybe the platform as a whole is now so much better that those more direct solutions are now viable again.
I don't know xD
@@ReedoTV Bravo dude, they're reinventing PHP and then they will reinvent NextJS
im waiting for MVC and active records to be a think again
@@michalkowalik89 Right? A controller is nothing but a glorified switch statement. And framework people build entire vast hierarchies of the darned things!
And this is how EHTML framework has born.
I'm not joking, the author transformed this into a framework, I'm find it interesting and constructive, very cool article for just thinking things different
Thanks for the feedback. Actually I created this framework 4 years ago, just because I wanted to quickly make AJAX requests and map responses to HTML without the need to create elements in JavaScript. This article was written just to demonstrate the idea in vacuum. Also, I have ideas on how to introduce type safety via linter into this concept.
@@guseynismayylov1945 wait you created EHTML?
@@rajmajumdar5253 yes, I am creator of EHTML
Rumors out that this is what "Rick" was working on before getting fired.
Got 'em! 😆
his approach reminds me of these super verbose xml protocols where you had a hundred elements with a hundred attributes and all it did was "int i = 1; i = i * 2". Getting nightmares from his example but I like that he's trying. I myself have went back into pure html + js and tried to reimplement mechanisms that transform page layout and reactivity in a clean and concise manner without a 500kb framework in the background. it's a powerful learning experience and it's making me want to rewrite my website for the n-th time, without a framework.
This is the part I don't understand, how does a personal website benefit from reactivity and state?
@@theodorealenas3171it usually doesn’t. There’s generally no need to use something like React, Angular, etc. for a personal website and most people who do so seem to do it just because they stick with what they already know and try to use that for everything.
.NET maui go brrrrrrrr
JDSL ftw! Tom always knew
@@theodorealenas3171 You must lack imagination.
8:10 Read from the article, "You can already imagine how much easier it is to share state...." Imagine writing that as if it's a good thing lol. Shared state is basically the source of all spaghetti.
true, it ends up with a high coupling
Shared writable state is. Shared observable state isn’t.
One owner of data, multiple consumers of data
How spaghetti can my vet's About Me page be?
@@dripcaraybbx Not very spaghetti because that's a static HTML file that doesn't need or js or any mutable state at all. I don't really see how that's a fair comparison to a stateful application.
@@avwie132 This does not negate high binding. Your components depend on another component and wait for a value to be initialized. Also, if you want to change the state structure and don't know who is using what, you will break the application because of the high coupling. So this approach doesn't scale. But for small sites it will do fine.
bro cooked, and then overcooked... i agree with the cooking, just not what actually ended up on my plate
Just checkout EHTML if you want to see a good example. I am the author of this article.
I used Handlebars or Mustache with template tag and vanilla js so you can inject js variables and you have a decent template language with if, foreach, etc... It works and it is pretty straightforward
Look up Mark Turansky's "Better JavaScript Templates." ASP-style templates that support native JavaScript without a template language. Sometimes less is more.
I love Handlebars but I feel like I need to move onto something like React for the future?
PHP i the answer and no one realizes.
reluctant like
And JQuery if you want your pages to have fancy dynamic elements
PHP so old
PHP way of developing websites is not that bad actually. It's just the syntax and stdlib of PHP that's bad, infinitely worse than TS.
@@igorordecha I know but with Laravel i can create a fully fledged backend with workers, queues, caching, dashboard and metrics in about 2 hours
The solution is pretty straight forward, accept that html and http are stateless environments and stop trying to put a square peg in a round hole.
Careful, or I'll put my peg in your square.
The solution is accepting this is a client server model and state needs to be synced just like any other client server implementation.
http also defines we should send all username and password in (almost) plain text and i don't see the engineers recommending that
Hey, I read a book and finally understands what this sentence means. Curious, will there be a push one day for new hypermedia controls to fill in the gaps that client side stuff is doing rn?
So you want to go back to the olden days where doing literally anything will refresh the page?
Specifically, application state (ie the domain model) should be parallel to the view model. Embedding state within the components that isn't totally isolated to the components is OOP goop all over again.
Allow the components to access/bring in the application state, but don't embed that state within the components
Btw, what the author proposed is actually a lot how oldschool AngularJS used to do things. You would include the AngluarJS in script section, define a template element, create a service that would hold some state, and bind it to the template html.
I am the author of this article. You should checkout EHTML
This idea is the core of EHTML framework/library.
I’ve been building web apps without front-end libraries for the past year. I don’t use this guy’s approach with the template tag, but for me I find it much easier to just append to the Dom as needed. This idea that the code becomes unmanageable is a self fulfilling prophecy, not an actuality.
Working directly on the DOM is jQuery all over again. What's old, is new.
@@Niosushonestly I'd take jQuery over these heavy modern frameworks and npm package hell any day.
Remember when you could just add jQuery as a script tag from a CDN and be done with it?
You don't even need jQuery to do it any more now that modern JS has more features and IE is dead, you can just use vanilla JS easily
I made my site's menus with JavaScript, while the rest was hand written HTML.
Then I was sorry that Emacs' web browser couldn't render it and I redid it in PHP. But how: the PHP tag opens inside of the markup, to give attributes to the elements.
It took several iterations before I accepted there's only going to be 4 menu elements anyway
@@georgehelyar yeah I was thinking the same thing. I know Jquery is still around but it’s kinda obsolete with modern js updates. Also jquery syntax is awful to look at.
you should learn C
Generally, it's more desirable to distribute work and memory requirements to clients I think. Not everyone is a company that has resources to stream _videos_ to viewers globally
Not a fan of this approach. I've never once needed to rely on an element's attributes to manage my state except maybe for styling purposes. I'm not the biggest fan of React either but even hooks aren't as unwieldy as this.
You’re not a fan because you’ve never done this? Interesting approach to software development 😄
@@EdwinMartin I have, when I was a noob. Great argument btw. I've never driven with my back to the wheel either; I still know it's a sh#t way to drive.
I am the author of this article, if you want to see good examples, you should check EHTML
This idea is the core of EHTML framework/library.
It is okayish, but lacks foundation and the template should not say what happens and where but I think it’s totally fine to subject those topics. The framework hell is not a good solution. I am awaiting the proposals that are there for ES to come like the NodeParts, placeholder in templates and the new redesigned html imports.
Yeah. I wonder why they didn't go for LaTeX macros too btw. To define a li with an a and preset attributes. But maybe these will do
I am the author of this article, you can check EHTML to see a really good examples where I am mapping AJAX JSON responses on html templates just using HTML.
That's roughly how I make use of templates where I can't make use of frontend frameworks, but the articles arguments are not really correct because they didn't even solve what those frameworks solve. It's fun to replicate what these frameworks do and I did so myself to understand how Vue, for example, achieves their reactivity.
This idea is the core of EHTML framework/library.
And this guys how we got to 30 javascript frameworks!
Cue XKCD "Standards" comic: 30+1 frameworks, or as JS sometimes processes it...301 frameworks. ;)
and you are the reason i have a crap code base at work
I'm more a designer than a dev today. but my background is in Front End. last time I was doing just. a favor for a friend to help him launch their startup. It was just a website, just a F# website. not an application. it was being dealed by their front-end team. I'm pretty good at HTML/CSS (I know its not programming) so I can draw then build what I done. gosh, how much EASIER would be if I could not use NEXT JS there!!! build processes are horrible. it it was just a static site, they would not be "screaming" at me because THEIR SERVER had an incompatibility with next 14, and I need to go back to 13 and change everything I done just. to help a friend (I'm questioning if it's still my friend btw).
HTMX and etc. seems like a breath of fresh air. a fixing on the hell developers look like they have conspired to make. definitely DONT use these to make just simple websites! it's painful.
The more complex a solution is, the more unlikely it should be the default approach.
According to this logic React doesn’t stand a chance
@@guseynismayylov1945 Sadly, the realms of ought and are, are rarely converging.
Every passing day I get ever more grateful I don't work with web.
Indeed, Webdev is such a convoluted mess of misery and tangled frameworks! Then again... developing for Windows UI, with Microsoft continuously reinventing Windows UI programming in ever worse ways isn't much better. Then you've got the multiheaded abstracted monster that is modern C++... I guess the ticket is: just stick with embedded programming in nice beautiful simple C!
@@ScienceAfterDark The trick is to make your own product and work for yourself so that you can use the tools you want to :)
@@hamm8934 and then you become Rick hahahha
@patorasco6266 i laughed too hard
The web is great, the problem is it's every script-kiddies first exposure to programming so there is going to be a lot of stupid shit.
That said if you are the one setting the rules it's just as fun as any other platform because you can use the smart and throw out the stupid.
mxml and actionscript was the best front end language ever.. databinding both ways, treeviews, treetables, accordion, they have them all you name it.. unfortunately it needed a flash plugin to run in the browser.. and now its dead.. thing is html is like 30 years old and was never meant to build UI.. so what we have now is like a tech soup just to have something decent running in the front end.. i think its time they reinvent the wheel so browsers support better languages so we can use 1 language to build the UI.. i dont understand that they dont understand the problem here..
Omg, here it comes we’re going back to good ole HTML/CSS
Omg
If we let bro cook any longer, Gordon Ramsey's going to burst down the door and scream "IT'S FUCKING RAW"
Re: 10:55 - Virtual DOM is meant to win against `el.innerHTML = ''; el.innerHTML = renderTemplate(data);` (which it does), not against pinpoint data manipulation to do exactly what you need.
congrats guys, they reinvented forgotten knockout js
you can cast an int by just adding a plus sign before the string
I've made a couple projects with web components and wish more developers left frameworks and started using native controls.
This idea is the core of EHTML framework/library.
nothing like typing html inside multi line strings and appending them to the DOM with jquery, good old days
This idea is the core of EHTML framework/library.
If you want to convert a string to a number instead of doing times one. Just add the plus symbol at the start of it. `+variable`
Yeah this is the way I knew how :)
You forgot? @@dandogamer
Without benchmark results from a low level debugger, who is to say which way is better?
@@mkvalorI'd like to see the receipts but I would assume they are similar in cost.
If you consider that all mathematical operations in a computer are just addition operations then adding zero and multiplying by one should end up being the same operation.
The actual conversion that happens before the mathematical operations will probably vary in time but should be consistently tied to the features of the inputted values (like the length of the input).
I hate both. I prefer the code the speak for itself. Unless the programmer is well read on the quirks of Javascript's insane type system. I prefer to just see a parseInt or parseFloat. He's not being clear and concise with his code. He's just being a smartass.
Every time I look at the discussions around front end dev, it just makes me even happier I chose the SRE route.
This idea is the core of EHTML framework/library.
I once worked at a company that used a custom framework that was actually based on php + templates + jQuery, worked pretty much like this. It worked I guess, but all the tags are still in the inspector even though they dont show up on the page. that alone killed it for me, coding for it was a mess.
Really? I also did something like template elements that only show up on inspector, in a previous iteration of my site, I liked it. You could see how templates expanded over time by looking at inspected eelments
@@theodorealenas3171 I mean I wasn't a fan of showing the user code that he shouldn't have access to yet and in a raw form. But it's far from the worst thing I ever worked with lol
@@refeals Shadow DOMs are still accessible to the user so I'm not sure where the concern is of "showing the user code that he shouldn't have access to". Anything client side is inherently viewable.
@@RaveYoda good point. Idk just felt weird i guess
At that point just create a server side PHP application with a competent framework and require a few extra refreshes.
Always funny to see backend guys talking about frontend.
Move to the Phoenix Framework and Liveview and all the js madness goes away, true server side state ... on the server, and handle updates via tiny websocket data calls to make the dom reactive. After 20 year writing JS... Liveview is just so much better
Looks like AlpineJS.
It’s EHTML
LOVE seeing the move toward Native JS! The APIs are SOOO easy these days that there's almost no need to use a framework so long as you just have good code organization habits. A senior has virtually NO problem working in that environment. BTW, most frameworks STARTED OUT as proprietary systems that eventually became abstracted enough to use across any project. (Pssst!... The framework giants don't want you to know this)
I feel like the issue with most modern frameworks being they let applications grow in a natural way.
Using templates and traditional backend services without the need for dependencies generates understanding while developing.
It's like leveling your way to max level instead of using an xp scroll. If you use the scroll you miss out on understanding how the skills work and lose the understanding of how to generate a "symphony". Like my embedded experience relates to writing linux components which relates to writing web servers which informs security and how to write large software projects. I can make a course graph if needed. The reason why "jumping into the deep end" is probably not a wise decision.
This feels very close to AlpineJS to me.
It’s coming from EHTML. I am the author of this article.
Isn't Vue doing similar things like this, but way better?
I've learned Vue during covid and I'm such a fan,
and I feel Vue is doing what this person is trying to do. But better.
Yup :) with the powerhouse of Evan You leading us to the promised land
“He is low key inventing a new framework” 😂
I am the author of this article, you can take a look at EHMTL
This idea is the core of EHTML framework/library.
4:58 that's not true. state = {count:0} puts state on window but const state = {count:0} does not
It meant global in terms of scope, but you're right
A number in string form * 1 basically does Number(stringnumber). It's faster to type, that's all.
All I can say is "hallelujah"! I never understood replicating all the state on the client with complicated frameworks. Sure, it works great for Facebook, but most apps aren't Facebook. So much easier to just bring down the HTML with SSR, and adjust the pages as needed with vanilla js. Btw as a C#/vanilla JS/Azure programmer about 3/4 of Prime's stuff goes right over my head. OK, maybe 7/8....
I am the author of this article, you should check EHTML, probably you would find it very useful
And they joked about me as a programming language - HTML
Noob question but if htmx has to make server requests for html, what happens to a user in Australia using a website which has servers in the US? Isn't it just slow and unresponsive
That'd be an architectural issue. No front-end technology can make that data arrive faster across the globe.
??? It doesn't have to render everything server-side. It's not like every partial update to the DOM must be driven by ajax requests.
No, the difference is the client asking the server for html snippets vs the client asking the server for json. You keep the delay between request and response, but you reduce the javascript overhead. You likely even get a more responsive website with htmx because there is no need any more to have consecutive ajax requests for loading a single page.
Yep - you're hoping that the devs set up infrastructure near Australia
@@basione But you don't need data arrival across the globe if you store the state client side, do you?
These minimal frameworks are and always will be a bad idea.
After almost a decade of trying out all the frameworks under the sun and attempting to make my own probably a dozen times these are my conclusions:
- most websites do not need a framework, npm, or a build system of any kind
- the best libraries are usually the ones that are just a single js/ts file you can hotlink or copy into your project
- forking said minimal libraries to add your own features is the correct approach, don't hack an abstraction layer or plugin system ontop
- typescript is worth it, but only when you're creating libraries
- webcomponents kinda suck, but they are great for implementing progressive enhancements
“You can come back to the good old days and simply enjoy writing HTML”. To me those were never good old days and I absolutely hated writing HTML/CSS. So glad that there are frameworks out there taking care of all that, so I can focus on writing functionality.
Also, the HTML the author was writing was not "good old days html"
i think this days html/ja/css are not so bad because all the features works the same way on each browser
Thanks for reminding me how good React is
or any major frameworks.
Global 'window' is legacy. But that doesn't mean we have to reference it every single time. You can ask window as argument in every function and that's what I prefer to do. This creates the annoying problem of prop passing which I consider a good problem to have because this forces to think about application design.
I love templates! I used them in production multiple times now.
I wrote this article. You should check EHTML, it’s a template language based on the ideas in this article
I hate how the author dismissed the name collision problem. Naming is one of the 2 hardest problems in programming (right besides caching and off-by-1 errors).
"Just name better" bro that only works with a counter button page.
The point of components (doesnt matter if its web-components or JS frameworks) is that I can have a 100 separate counters without bloating the global namespace with counter-1, counter-2 etc.
I also can use a "counter" state in an other component and don't have to worry if it's already been taken in this particular page.
And I can create a component library that matches the company design and build a website like lego. I don't have to copy-paste 10s of lines of complicated markup every time I want to render a datepicker (that argument is pretty weak actually because its solvable by server side templates or whatever this thing he proposes. It's just an argument against vanilla HTML+CSS+JS for more complex sites).
I'm not advocating for a heavy JS framework but I'm saying we need a good system for creating semi-isolated(with access to both global and local state), reusable components. Web components suck, React is a bloated mess and HTMX is just an utils library for vanilla HTML so that you can modify parts of markup without reloading (it doesn't really solve my main issue). There's no good solution.
Also, React has no real alternative in the mobile app world. And btw on mobile you can throw your HTMX mindset of sending hydrated HTML to the client out the window.
don’t you think it would be appropriate to say htmx is like this? instead of this is htmx? coz aren’t those built-in browser web environment?
I still believe that jails-js is a better alternative about "diferent way to think".
There are too many solutions full html or full js, and very less alternative like Jails which is use html and write logic on top of that without losing your mind...
It´s not because I thought about it, but I can´t see anything alike... and I wanted to see more... Not a React/Angular fan... not a htmx fan either... they live too much in the extreme edge for me...
Best conclusion ever !
This idea is the core of EHTML framework/library.
So people really not know about div elements?
A framework i love that is using templates and a way to integrate state into the templates is Lit. I find it to be a more elegant solution and its a very small framework, but not very popular
Initially it was an idea similar from your video called Polimer (the first version of Lit)
This idea is the core of EHTML framework/library.
This is objectively terrible, but I learned something so nice article. We need more people like this in the world.
I am the author of this article. If you want good use cases, check out EHTML
Like HTMX but just native
There's a JS library called reef.js, it adds the concept of signals to vanilla ja and works well with web components because the author is a vanilla js/web component fan
This is one reason we use frameworks, so we don't have to deal with every codebase maintaining its own (to be blunt) crappy solution like this. In vanilla JS, everyone just comes up with a different crappy solution. With a crappy framework, at least we're all using the _same_ crappy solution. (Though it doesn't have to be crappy--some frameworks are good.)
Who is "we all?" Other people on your team? Other users of the framework who use it on their own project?
@@dripcaraybbx Web developers who use a framework.
To elaborate: if an app uses React, even though I don't like React, and React has a _lot_ of problems, at least I can read and contribute to the code (usually). But if an app uses vanilla JS, I probably won't be able to easily decipher their codebase, let alone contribute to it, unless every previous main contributor happened to be excellent at designing and writing maintainable code, as well as documenting it. For example, it would be annoying, if not difficult and very time-consuming, to read or contribute to an app written the way the code in the article is written.
@@GrantGryczan On a large project, I feel like this is what a team should be able to do. The architect or senior devs should be able to define a library or abstractions based on a ubiquitous technology that doesn't lock them into a dependency. So, as long as users have browsers, why not develop the internal framework that works for your entire team? Better than than install all those stupid React files on build (just because that's what Facebook needs) or replicate the DOM.
@@dripcaraybbx Yeah, that's what every great developer should be able to do. And I wouldn't doubt that you, I, or any senior engineer at a big tech company could do that. But many (if not most) developers, at companies that can't afford to be picky, simply don't know how to write maintainable code. A lot of developers I see at workplaces only have experience from courses they took in college for a bachelor's degree. They never touched anything even remotely programming-related outside school, and they still don't outside work. They cruise at the knowledge level school left them with, because hey, they make a living, and that might be the only aspect of software development they care about. Good for them!
So if I were to join a project, I wouldn't trust a vanilla JS project to be enjoyable to work on as much as I would a React project. React is a really crappy framework, but at least the level of crappiness is much more limited by the framework than it would be if written with the freedom of the entire realm of possibility of vanilla JS. When I join a project using a framework, I know exactly what I'm getting into, and I can use my prior knowledge of the framework rather than having to get used to what is most likely going to be a tightly coupled ball of spaghetti written in vanilla JS, such as the not-that-maintainable code from this article (although I've seen much worse).
And that's not to say framework code can't be unmaintainable or tightly coupled, but just that framework code is infinitely more limited in the ways it can be.
@@GrantGryczan If React is a crappy framework compared to other libraries built on the same JavaScript, I would say it's a function of the framework not JavaScript
These people are the motivation why I'm intending to learn HTMX and I really hope the rest of the world will do the same. This madness has to stop. Now.
HTMX is popular because of memes. It’s not “that” good yet, I like it, but full stack devs anyway will fuck up CSS
I am the author of this article, you can check my solution EHTML
@@MissViolettaBI think the philosophy of using http like it was intended is the selling point. The actual library seems like more of a proof of concept. I think you could very easily employ the philosophy of htmx into your vanilla app without actually using the htmx script.
"...only to then turn around and use a library which calculates diff between DOM and Virtual DOM and does those direct manipulations anyway."
First thing, it is not calculating difference between DOM and Virtual DOM, rather it looks for difference between old Virtual DOM and new copy of Virtual DOM that has changes, confirms what the changes are and then updates only what is needed on real DOM. Second, it's not direct manipulation because it's not us directly manipulating it, automatic system does it based on how state changed and that's the whole point of these libraries.
Template element is not readable for me. I like the global state in window.
For anyone still worried about the job market: These are the type of articles that will ”educate” our next generation programmers. You’ll be fine.
For the next 10 years says Robert Martin. That's before I'll retire so I may get to see the sunrise
@@theodorealenas3171 I don't trust Bob to watch over a painted sheep
@@gileee I don't trust you to ship a painted watch
@@theodorealenas3171how are you going to retire, tell a secret
Whew, that first paragraph is the hottest of takes. I do agree that while React is useful, we should all still know vanilla JS.
React is harmful. It solves non existing problems.
I hate when my server returns html. Html response means that you don't have any control of your data on the client side at all. Also, all of your endpoints began to look ugly. Also, it oddly separates logic- and logicless parts of your html. I want my APIs to return some helpful format (mainly json, of course).
But I found the perfect solution for me: use htmx alongside nunjucks in case I need some data manipulations on the client side or use mustache otherwise.
He started off good but then it became another mess of figuring out the magic keywords to do stuff in the templates which I find annoying in all the other frameworks as well. I recently dabbled with something similar but where I instead use java class to define components each with their own template and proxy for model mapping so it can re-render itself in the dom on model changes. Furthermore I used Javascripts lovely untyped prototype stuff to auto generate functions on the fly for the classes so that you can programmatically set styles, classes and update model as if it was a poco (plain old class object). So in a sense it feels more like developing a desktop application in the good old days, here is an example:
class MyApp extends App {
constructor() {
let para = this.add(new Paragraph({ class: 'my-paragraph' }));
this.add(new Button({ text: 'Click me' })).setBorderWidth('5px').setOnClick((button) => {
para.setText('Hey stop clicking me!'); // auto function to template props
button.model.text = 'Ouch!'; // example to set model directly on button
});
}
}
new App();
App inherits a Container class and has a default column layout using FlexBox, but any container can initialize their own FlexBox with whatever layout they want. All base components have functions for setting all style directly or several can be set by using a object, for example para.setStyle({ padding:1, fontSize:2 }). Each container can have their own base unit, default is rem and 100% font-size on body as it is then easy to adjust size of whole UX by just modifying body %. Ofc any can set class (and have helpers for adding/removing) so if you want you can add plain css files yourself as before to style everything.
You can ofc make your own components and even just write your event handlers directly like this:
class MyButton extends Button {
onClick() {
this.setText('Touch me again...');
}
}
Using setOnClick() will override the default onClick implementation. A cool thing is also that the CSS classes are injected in the page head dynamically so it is quite easy to define some variables that is used to parameterize the styles and hence does not need any preprocessors. Basically the goal of the project was to have plain JS without the need to compile anything to get stuff running, although the auto-prototyping on the fly is a sort of compiling I guess. Creating new components ofc requires you to specify your template (simple string expansion from model variables). Still early days but it works quite well and the fun thing is that I can code in plain Javascript to create a frontend with no mucking about with typing in bindings between html code and the javascript code.
Hot take: Everyone in the comments saying "use this or that framework instead" needs to learn JavaScript.
4:59 while const state is "globally" accessible it still doesn't define it on the window object.
Then do it yourself lmfao
true, but you can also do window.state = ...
No, var at the top level of a script is on the window, const and key are block scoped see codepen DOT io SLASH anthonybullard SLASH pen SLASH RwdrGrR (thanks YT for making me do weird stuff to make url appear).
It's not even global in the sense that it's shared across modules if using a script tag with type="module", as modules have their own scope.
@@peterszarvas94 We can use var state instead. I was just clarifying that const is not the same behavior as stated in the video.
is there a reason not to do
parseInt(button.getAttribute('data-Count'))
?
Less to type? :D
try this:
parseInt("0.00000005")
parseInt(0.00000005)
As a veteran programmer with +30 years experience, the entire JavaScript eco system is the biggest pile of shite in the history of computing.
This idea is the core of EHTML framework/library.
Why reinvent the wheel? AlpineJS does this and more!
looks cool, did know about that. I am the author of this article, I created EHTML, it works in a similar manner, but also allows you to fetch JSON and map it to the tamplate.
Not just about what convivences we choose to develop with, these are the crappy performing behaviors making websites we end up being users on.
React , tailwind et al encourage bloat and soppy architecture.
It's obnoxious waiting for a frame to load that then fetches the content, then has to render that content, then update that content, then finally display that content and wait for interactivity; and that that isn't something that occurs only for the first load on a lot of "websites".
Meanwhile memory usage skyrockets and if your one a phone you now have a heater with a dying power source in your hand.
And userscripts and userstyles to fix these sites become harder and harder to make and maintain because of generated html divitis soup because more and more developers are given up on learning how to name things.
4:54 Wrong. Global constants do not become properties of the window object, unlike var variables. You can confirm in in the browser in 2 seconds, have a look at window.constantYouSet - its not on there my guy.
It meant global in terms of scope, but you're right
Wow I actually invented this at a company that refused to allow us to use third party libraries. It was a decent solution imo
I love his first snippet. But I do have beef with the "1"*1. He's being a smartass and sacrificed readability in the process.
*1 to force number conversion so the next + won't try a string concat I guess
I've been saying for a while that Rust's Tonic GRPC framework on the backend with Ruby's Sinatra+HTMX on the frontend is THE stack for 2024
Sinatra? Do you mean Leptos? 🦀
He’s not writing a Solidity backen NGMI
YUCK. I'm done writing client side applications. I'd rather write htmx in an actually comfortable language like ruby than do crazy wasm stuff that's still going to end up calling JS at the end of the day@@thebrowhodoesntlift9613
Would be so funny if chatGPT get so good at turning images into javascript that it kills js frameworks
Well yea Frontend is really.....no engineering. I'm a newbie and I can see that.
depends on how complex it is. eg google docs
try Ollama Llava model and be amazed.
Still waiting for the template demo that shows how it allowed them to build better interactive user interfaces for the user and not the developer
I haven't tried HTMX yet, because I want to build THICC CLIENTS. I'm a novice dev choking to death on React and wondering why the ideas of HTMX aren't more client sided?
All this really needs is an LSP and it could work.
Wait, so you're telling me the things I've been doing for the last two decades, because I hate the state of web dev, might suddenly become hip again? Maybe I better break out that pair of Jenkos and oh! That one t-shirt I still have with the picture on the back!
I did something very similar with vanilla JS that rendered data from microservices - it was before the term microservice was popularized, just little boxes like "address entry box" or "what services are available at your location" kind of boxes.
Later saw hoe people made "microservices" in the "processional" way and nearly vomited how much abstraction layering libraries were involved lol - and they still made more work...
That is definitely not what microservices are.
@@avwie132 It was definitely what microservices really are. Just you guys I am sure do it the suckful way instead.
It was literally a full service with back+frontent that you could plug&play drop onto literally any page or site or whatever and was hosted elsewhere.
What else you want? If you want anything else you are overcomplicating what it really means to do microservices. And guess what - they had to communicate and no still no need for fancy libraries for that.
Originally it is a very good idea that for example enables different companies to work on different parts of much bigger projects and product simple self-contained module-like stuff that is hosted at various places (or the same machine if you configure it that way - but it depends on where you deploy).
Again I really ask what you consider microservices if not this?
PS.: Guess what but you can even do microservices without JS and only using htmx too haha
How does HTMX solve the problem of syncing client & server-side state?
It seems like you're right back in state co-location hell the second you have a client-side action that changes server-side state, but can't wait on HTTP w/o killing UX.
It solves it by not having client side state in js, the state is the html markup. Every click is basically sent to the server, which modifies it's state, and sends back the appropriate html fragment. If you have some highly interactive components like maps or sheets, you need to implement it by vanilla js or some framework. But for any basic state change like count++ or appending a row, it's perfect.
@@peterszarvas94 And if the client's has bad internet, how would you do optimistic updates with HTMX?
@@peterszarvas94what happens when the server decides the state change, and not the client
@@jaeger2278 you can do polling with htmx
I am the author of this article, you can check out EHTML to see a real good examples.
this style can be called creative programming, when you create solution for the problem you meet along the way, rather just use the tool other handed to you and follow instruction
Coming from a perspective of playing with free web hosting that only allowed client-side scripting I can see this would be useful in that context but not to any level of complexity. Having said that I did once generate an IndexedDB by scraping the data- attributes of a massive webpage listing hundreds of publications with multiple ways to filter them down.
Im surprised that a channel called Prime Reacts would even consider to read an article against reactivity.
the fact he did not propose any solution for change detection says a lot about why it seems "less complex"
I am the author of this article. You don’t need a change detection, you need to solve real problems. This is why I created EHTML
The problem is not here, it’s more about security issues I’m using React
Those sort of templates is what ERPs like Odoo uses for its fronted. Nothing else to say really.
I did nearly the same, but with webcomponents, but I did create also a Designer for the templates
This idea is the core of EHTML framework/library.
Just watched the video about "The truth about htmx" then this pops up lmao nice transition 4 months later
"-5.6" * 1 OR +"-5.6" which is my preference
random but the first react example is incorrect iinm; to set state based on previous state, setCount(count + 1) should be setCount(prevCount => prevCount + 1)
Concurrent React*. Not an issue until you use Concurrent React.
Not really, you only need the callback setter if your doing consecutive setState calls
@@wlockuz4467 ahh I see -- I just checked the docs.
"This is not an issue until you attempt to read state soon after you have set it (setting state repeatedly is an easy way to the issue)."
Though, there is an Eslint-react rule against this since it should still never be written like this -- there's no guarantee that someone else later will just know this behavior. react/no-access-state-in-setstate
next post from this author: "honey i made another js framework"
I did, it's called EHTML