5 ms·

>The problem is building proper architecture, so code won't quickly turn into spaghetti [...] With vanilla JS it's the wild west. This is a "problem" that I so

>The problem is building proper architecture, so code won't quickly turn into spaghetti [...] With vanilla JS it's the wild west. This is a "problem" that I solved for myself years ago. It's not even that hard. I've started by noting that most of the issues with JS come from a few sources. - Managing code dependencies. - Navigating DOM. (Manipulating DOM is trivial.) - Managing events. - Synchronizing JS state with DOM state consistently. If you pause to think about those, each of them has a straightforward solution that does not require a framework. - Do not make libraries that directly depend on external code. Use DOM and HTML events for configuration and communication. - Use CSS queries. - Use timers or document-level events. They will continue to operate regardless of how elements change. - Use DOM as your state storage. (Custom attributes + occasionally symbols.) This way your code itself is completely stateless. There is more to it, but this is the foundation. One of my favorite libraries is one that checks for specific attribute that contains a CSS query, then runs it, then outputs the result as a parameter on the original element. Couple dozen lines of code, countless applications. Best of all, you don't have to write any page-specific glue code. You load the library and it just works.

toastal 7y ago
I disagree with storing your state on the DOM. Querying the DOM can be pretty slow, but also now you're state is going to be stringy-typed which will involve parsers and a whole mess of reasons you don't want that. If you want to keep the logic simple, a view should be a function from a state/model to some 'visual' representation (be it DOM, canvas, Qt, ASCII, a quilt pattern, etc).
- seangrogg 7y ago
  A DOM node's attributes are strongly typed, but it is an object and you can still set Node.foo = barObject if you're so inclined. Not saying it's not without it's tradeoffs, but if you want state housed in the DOM rather than another state manager it's not hard to conceptualize.
whatarethembits 7y ago
I hope then someone in your team is responsible for continuously documenting these patterns, however trivial they may seem to the author. I use frameworks for their documentation more than anything else. Maybe it's the UK developer culture but I haven't come across any codebase that has even remotely useful documentation in the past five years in three jobs. These "intuitive patterns" only exist in the senior dev's head. New comers have to either constantly ask or figure it out slowly by going through source files. Homegrown "simple and intuitive" solutions only benefit the rockstar who wrote them, not the other members of the team who are there now and who will come after the rockstar is gone. Please use well documented frameworks, otherwise we're trading away the entire teams productivity in favour of the rockstar to have his say.
- Silhouette 7y ago
  This is a real problem, but I'm not sure the root cause is that senior developer. We've been building software far more complex than any web front-end for many, many years. Much of it was built without the help of all-encompassing frameworks. Much of it has stood the test of time longer than any web app, too. Doing this requires a basic understanding of general programming principles from all developers. It requires a solid understanding of software design and architectural concepts from at least the more senior developers. These things aren't rocket science. Millions of developers around the world have these skills. Many books and conference talks and training courses have been created to pass on the knowledge and the important ideas behind it. Unfortunately, lots of people get into web development without ever learning even the basic skills of their trade. They learn by copying and pasting snippets from Stack Overflow or some YouTube video they found, jumping from one trendy framework or tool stack to the next every five minutes, with no awareness that those snippets were often also written by people who never learned the basics. Rookie mistakes are everywhere, and the culture often favours shiny new things over solid, well built solutions to real problems. You can't really fix this just by getting developers to use a well-documented framework. For one thing, a lot of those frameworks aren't great themselves, either in their design or (not coincidentally) in their longevity, because they too were written by people with limited experience and understanding. But even if you do find a good framework, if your developers don't understand how to use it and the trade-offs it makes, they will still make dumb mistakes. When you have requirements that can't be implemented by just joining one framework dot to another until you're done, you definitely want someone who knows what they're doing writing that code. As is often the case, the key to improving this is probably better training, particularly in the early stages of a career. But that doesn't always work in business, where resume driven development means developers will stick around long enough to add a few buzzwords and then jump ship to a better paid job somewhere else, taking the value of any accumulated experience with them. Until businesses start looking for real skill instead of buzzwords when they're hiring and start rewarding real and growing skill with their compensation packages, unfortunately the cycle will continue.
brylie 7y ago
What is the library you use for running functions based on CSS query? I am working on a project where I initialize some DOM elements with data- attributes and control their visibility in response to a form input change event. It would be nice to somehow run the visibility check in more of a declarative/reactive manner without having to commit to writing my templates with a front end framework and build tooling. Are there any reactive JavaScript frameworks that treat DOM and data- attributes as first-class citizens?
- gambler 7y ago
  >I am working on a project where I initialize some DOM elements with data- attributes and control their visibility in response to a form input change event. It would be nice to somehow run the visibility check in more of a declarative/reactive manner without having to commit to writing my templates with a front end framework and build tooling. Here is an approach you can use: const name = 'check-if'; const aState = name + '-state'; run(); function run() { document.querySelectorAll('[' + name + ']') .forEach(update); setTimeout(run, 50); } function update(target) { let selector = target.getAttribute(name); let matchedSomething = document.querySelector(selector) !== null; if (target.getAttribute(aState) !== matchedSomething.toString()) { //only update when change is necessary target.setAttribute(aState, matchedSomething); } } Usage: <style> [check-if-state="false"].conditionally-visible{ display: none; } </style> <div check-if="#input:valid" class="conditionally-visible"></div> This exact code can be used for any styling based on any CSS query. It only allows one rule per tag, but in practice it's usually sufficient. In case you need multiple rules, you can wrap the original tag in another one. You can use data- attributes instead of customs, which will simplify the library somewhat at the expense of HTML readability. You can use the same approach for enabling/disabling inputs. If you need more fine-grained information to act upon, you simply write another library that adds it to DOM.

toastal 7y ago

I disagree with storing your state on the DOM. Querying the DOM can be pretty slow, but also now you're state is going to be stringy-typed which will involve parsers and a whole mess of reasons you don't want that. If you want to keep the logic simple, a view should be a function from a state/model to some 'visual' representation (be it DOM, canvas, Qt, ASCII, a quilt pattern, etc).

seangrogg 7y ago
A DOM node's attributes are strongly typed, but it is an object and you can still set Node.foo = barObject if you're so inclined. Not saying it's not without it's tradeoffs, but if you want state housed in the DOM rather than another state manager it's not hard to conceptualize.

whatarethembits 7y ago

I hope then someone in your team is responsible for continuously documenting these patterns, however trivial they may seem to the author. I use frameworks for their documentation more than anything else. Maybe it's the UK developer culture but I haven't come across any codebase that has even remotely useful documentation in the past five years in three jobs. These "intuitive patterns" only exist in the senior dev's head. New comers have to either constantly ask or figure it out slowly by going through source files. Homegrown "simple and intuitive" solutions only benefit the rockstar who wrote them, not the other members of the team who are there now and who will come after the rockstar is gone. Please use well documented frameworks, otherwise we're trading away the entire teams productivity in favour of the rockstar to have his say.

Silhouette 7y ago
This is a real problem, but I'm not sure the root cause is that senior developer. We've been building software far more complex than any web front-end for many, many years. Much of it was built without the help of all-encompassing frameworks. Much of it has stood the test of time longer than any web app, too. Doing this requires a basic understanding of general programming principles from all developers. It requires a solid understanding of software design and architectural concepts from at least the more senior developers. These things aren't rocket science. Millions of developers around the world have these skills. Many books and conference talks and training courses have been created to pass on the knowledge and the important ideas behind it. Unfortunately, lots of people get into web development without ever learning even the basic skills of their trade. They learn by copying and pasting snippets from Stack Overflow or some YouTube video they found, jumping from one trendy framework or tool stack to the next every five minutes, with no awareness that those snippets were often also written by people who never learned the basics. Rookie mistakes are everywhere, and the culture often favours shiny new things over solid, well built solutions to real problems. You can't really fix this just by getting developers to use a well-documented framework. For one thing, a lot of those frameworks aren't great themselves, either in their design or (not coincidentally) in their longevity, because they too were written by people with limited experience and understanding. But even if you do find a good framework, if your developers don't understand how to use it and the trade-offs it makes, they will still make dumb mistakes. When you have requirements that can't be implemented by just joining one framework dot to another until you're done, you definitely want someone who knows what they're doing writing that code. As is often the case, the key to improving this is probably better training, particularly in the early stages of a career. But that doesn't always work in business, where resume driven development means developers will stick around long enough to add a few buzzwords and then jump ship to a better paid job somewhere else, taking the value of any accumulated experience with them. Until businesses start looking for real skill instead of buzzwords when they're hiring and start rewarding real and growing skill with their compensation packages, unfortunately the cycle will continue.

brylie 7y ago

What is the library you use for running functions based on CSS query? I am working on a project where I initialize some DOM elements with data- attributes and control their visibility in response to a form input change event. It would be nice to somehow run the visibility check in more of a declarative/reactive manner without having to commit to writing my templates with a front end framework and build tooling. Are there any reactive JavaScript frameworks that treat DOM and data- attributes as first-class citizens?

gambler 7y ago
>I am working on a project where I initialize some DOM elements with data- attributes and control their visibility in response to a form input change event. It would be nice to somehow run the visibility check in more of a declarative/reactive manner without having to commit to writing my templates with a front end framework and build tooling. Here is an approach you can use: const name = 'check-if'; const aState = name + '-state'; run(); function run() { document.querySelectorAll('[' + name + ']') .forEach(update); setTimeout(run, 50); } function update(target) { let selector = target.getAttribute(name); let matchedSomething = document.querySelector(selector) !== null; if (target.getAttribute(aState) !== matchedSomething.toString()) { //only update when change is necessary target.setAttribute(aState, matchedSomething); } } Usage: <style> [check-if-state="false"].conditionally-visible{ display: none; } </style> <div check-if="#input:valid" class="conditionally-visible"></div> This exact code can be used for any styling based on any CSS query. It only allows one rule per tag, but in practice it's usually sufficient. In case you need multiple rules, you can wrap the original tag in another one. You can use data- attributes instead of customs, which will simplify the library somewhat at the expense of HTML readability. You can use the same approach for enabling/disabling inputs. If you need more fine-grained information to act upon, you simply write another library that adds it to DOM.