3 ms·

Of course you can do quite a bit with JS. Some of the projects I’ve made You can swap CSS classes in JS. But how do you know which classes are available? You

by bbx 6y ago

Of course you can do quite a bit with JS. Some of the projects I’ve made You can swap CSS classes in JS. But how do you know which classes are available? You can target HTML elements in JS. But how do you know which elements are available? You can set “.innerHTML”. But how do you save the state of the application? As soon as the app grows a little bit in complexity, you’ll end up building functions to keep track of things and functions to perform repeated actions. You end up building a tiny framework that only you know how to use. When it’s time to debug and grow, you’ll need a proper JS framework anyway. The thing I would say about popular JS frameworks, and which I’m surprised about, is how they favour single page app structures rather than “drop-ins” to enhance a page. I’ve yet to see React or Angular be used as part of a page, which is crazy because they would enhance the developer experience so much, without disturbing the classic way of delivering pages server-side with classic routing and classic user experience.

orange8 6y ago
> You can swap CSS classes in JS. But how do you know which classes are available? > You can target HTML elements in JS. But how do you know which elements are available? This assumes someone else is creating the CSS and HTML for you? Have rules or coding and naming conventions like BEM for example. That's what a framework basically is, a set of rules and conventions about how to structure an App. What you need is proper architecture, regardless of whether or not it is based on a popular framework. That's how the popular frameworks started out to begin with.
ehnto 6y ago
There are other frameworks that do favour a "drop in" style of development, with native Web Components being one of them. I used Riot for this for a while, and tried native Web Components as well. My current approach for zero dependency/build, one off UI components is: <div class="some-component" data-props="{}"> ...more HTML... <button class="some-component__button">Click Me</button> <script type=text/javascript"> (function() { var component = document.currentScript.parentNode; var props = component.dataset.props; var button = component.querySelector('.some-component__button'); button.addEventListener('click', function(){ ...doStuff... }); })(); </script> </div> If it needs a global state, or is part of a larger more dynamic UI I'll start looking at a framework. But for an otherwise static website, it's so much easier to do it that way than it is to introduce an entire framework and build pipeline in order to do a handful of JS components. It's also a somewhat defensive approach, useful in legacy applications with lots of hodge podge JS going on. Generally speaking, you don't cause any problems, and don't encounter any conflicts. I used to have a class based/web components way to do this, but I don't even bother with that anymore. You don't gain anything from introducing complexity in this circumstance.
rimliu 6y ago
If someone uses framework because they would write spaghetti code without it, I guarantee that they still write spaghetti code, just served in the framework provided boxes.

by bbx 6y ago

orange8 6y ago

> You can swap CSS classes in JS. But how do you know which classes are available? > You can target HTML elements in JS. But how do you know which elements are available? This assumes someone else is creating the CSS and HTML for you? Have rules or coding and naming conventions like BEM for example. That's what a framework basically is, a set of rules and conventions about how to structure an App. What you need is proper architecture, regardless of whether or not it is based on a popular framework. That's how the popular frameworks started out to begin with.

ehnto 6y ago

There are other frameworks that do favour a "drop in" style of development, with native Web Components being one of them. I used Riot for this for a while, and tried native Web Components as well. My current approach for zero dependency/build, one off UI components is: <div class="some-component" data-props="{}"> ...more HTML... <button class="some-component__button">Click Me</button> <script type=text/javascript"> (function() { var component = document.currentScript.parentNode; var props = component.dataset.props; var button = component.querySelector('.some-component__button'); button.addEventListener('click', function(){ ...doStuff... }); })(); </script> </div> If it needs a global state, or is part of a larger more dynamic UI I'll start looking at a framework. But for an otherwise static website, it's so much easier to do it that way than it is to introduce an entire framework and build pipeline in order to do a handful of JS components. It's also a somewhat defensive approach, useful in legacy applications with lots of hodge podge JS going on. Generally speaking, you don't cause any problems, and don't encounter any conflicts. I used to have a class based/web components way to do this, but I don't even bother with that anymore. You don't gain anything from introducing complexity in this circumstance.

rimliu 6y ago

If someone uses framework because they would write spaghetti code without it, I guarantee that they still write spaghetti code, just served in the framework provided boxes.