8 ms·

I don't know who originally said it but "If you're not using a framework, you're building a framework". This repo even has the following caveat: (2) These usual

I don't know who originally said it but "If you're not using a framework, you're building a framework". This repo even has the following caveat: (2) These usually end up becoming a custom micro-framework, thereby questioning why you didn't use one of the established and tested libraries/frameworks in the first place. That said, I don't hate it. For quite some time, I've taken the stance that a web development team needs an opinionated framework, but it's fine for it to be a bespoke creation rather than off-the-shelf. The biggest value of choosing React, Vue, Svelte, etc is, in my opinion, less about it doing the heavy lifting for you with the DOM and more about adopting an established valid opinion to guide the team's development.

dukoid 6y ago
Can I claim I don't violate the "No general-purpose utility functions related to the DOM/UI" if I use only one such function? O:) https://github.com/stefanhaustein/notemplate https://github.com/stefanhaustein/notemplate (the demo is just TodoMVC, though)
- morrvs 6y ago
  :D just to be clear, the rules were made just for the case study. I'd never recommend following these rules in a professional project. They are part of the method of the case study, not its outcome; the outcome is a couple of (hopefully) interesting patterns and insights, without trying to prescribe anything.
morrvs 6y ago
Thanks for reading - original author here. For the precise quote you mentioned I came up with somewhat format rules which prevented building a framework (code-wise) for this case study. The "caveat" you mention is just an explanation for the chosen ruleset; I believe I haven't introduced any general-purpose DOM/UI code in the case study and instead only describe patterns (correct me if I'm wrong!). I agree with your view of framework value as I professionally use React on a daily basis and will continue to do so, for similar reasons :)
noir_lord 6y ago
Of the three you listed Vue is the most 'opinionated' in that it ships with official router, official store (vuex) etc and that is a huge deal. With React and particulary svelte (for now) it's a mishmash of possible choices. Where that bites is when you have 3 choices to make with 4 options. 4^3 === 64 - so any project you pick up/come onto has a 1/64 chance of using a stack you've seen before.
- nicoburns 6y ago
  True, but routing libraries don't tend to be that complex. Picking up a different is not exactly a big deal.
madoublet 6y ago
Framework churn is real. I no longer recommend JS frameworks simply b/c the opinion of the framework developer drastically changes over time. So, you are constantly re-writing completely valid and working code to keep up with the latest version of the framework. The JS language itself, on the other hand, seems to be very stable with long deprecation cycles and steady improvements. So, it is much easier to build on.
- nicoburns 6y ago
  React has been stable since ~2015, and there are no signs of that changing.
  - madoublet 6y ago
    I can't speak to React. But, both Vue and Angular have seen dramatic changes over the last few years.
    - NiceNamesOrg 6y ago
      Most of the code people have written in Vue 2 is compatible with Vue 3. Vue 3 has just added some additional features. Sure, there are breaking changes, but not to an alarming degree.
      - madoublet 6y ago
        My opinion comes strictly as an indy dev with very limited time and resources. So, any breaking change is frustrating.
      - onion2k 6y ago
        Most of the code people have written in Vue 2 is compatible with Vue 3. All of the code written with React 15 is compatible with React 16. And React 17. And React 18. And so on probably.
        nicoburns 6y ago
ehnto 6y ago
Using frameworks is far more about hiring and human resources than technology I feel. However, if your "micro framework" follows language idioms and is thin enough you get the best of both worlds, whilst releasing yourself from some of the downsides that come with using a general purpose framework.
- treespace89 6y ago
  Frameworks make hiring a bit easier it's true. I'm amazed at the number of developers who can't seem to cope with working with custom in house frameworks. I'm talking about fully working systems, with full source code and being walked through the code by the author / maintainer. They fall apart, constantly complaining that the approach is non standard, deprecated, dangerous, unprofessional, untestable. So we are trying more and more to use frameworks, just to be able to hire more easily.
  - Vrondi 6y ago
    This just displays the core incompetence in basics that many devs who are dependent on frameworks have.
  - ehnto 6y ago
    Definitely agree, developers can get away with a lot of missing knowledge and not realise it, if they're using frameworks from the start of their career. Ideally you could hire senior developers with the skills to work inside boutique software, but I have found "legacy" code turns a lot of people off a project, and most boutique software eventually gets called "legacy" even if it's well architected and running perfectly fine. The skill which I think new devs could differentiate themselves with, is debugging. Familiarising yourself with software patterns definitely puts you ahead, but being able to use debuggers to understand code that has no pattern, that's when you become the kind of bug-squasher/problem-solver that projects like that require. If you have good debugging skills, you can work on any project, because you can find out all the information you need by stepping through the code.
shams93 6y ago
With es6 template strings you can do a lot of heavy lifting with some very simple code. This example still uses es5 to mr that’s insane who on the web is still using ie6?
- vanadium 6y ago
  IE11. IE11 remains the problem.
  - DarkWiiPlayer 6y ago
    In the corporate world, yes (sadly), but for personal and free projects I'd say it's acceptable to just ignore IE entirely and at most include some JS snippet to tell its users to get a real browser.
  - throw_m239339 6y ago
    IE11 is an unsecure browser and doesn't even support numerous HTML5 security features. Any business that still relies on IE11 is asking to be hacked, no more, no less, because it also means that these businesses are still running older versions of Windows. Now IE11 isn't even an excuse because $current_year ES version can be transpiled to older ES versions.
wtetzner 6y ago
> These usually end up becoming a custom micro-framework, thereby questioning why you didn't use one of the established and tested libraries/frameworks in the first place. Often a custom micro-framework better suits the needs of a particular project. I've written micro-frameworks for specific projects intentionally, because they did a few things that the established frameworks either didn't do, or it was very difficult to get them to do. An additional benefit was that using the micro frameworks ended up being simpler, and the startup time was much, much faster. Whether or not you use an existing framework depends on how much effort it is to write and test a custom framework vs the amount of effort you'd need to put in to use an existing framework. The ones I've written have been pretty quick to develop, and were also intended to be used for a few different projects that had similar needs. Edit: Just for clarification, the micro frameworks I've written are server-side, if that makes any difference.
- notJim 6y ago
  > Often a custom micro-framework better suits the needs of a particular project. Fitting the needs of a particular project is frequently a local optimum however. Often, it's much more optimal to focus on the needs of a whole team or even whole company. You can hire people who already know React/Vue/whatever, but there is no one in the world who knows your micro-framework.
  - CmdrKrool 6y ago
    But due to its micro-size, it won't take long to learn.
    - notJim 6y ago
      Micro-frameworks have a nasty habit of outgrowing the description, IME.
  - randall 6y ago
    It's always "tear it down" or "build it up" at the end of the day. Which one takes more effort is the right one to optimize for with your particular use case. Rails vs Sinatra is a great example.
overgard 6y ago
I think the problem with bespoke frameworks is that many career driven developers won't want to become a specialist in proprietary tools that won't transfer. However... I have this strong suspicion that most projects that use something like React don't really need it. Like, if you're creating something that actually acts like an application and data might be shown in many places it makes a lot of sense, but for something that's just displaying data from a db on a page hit it can be massive overkill.
_the_inflator 6y ago
> adopting an established valid opinion to guide the team's development Different requirements allow for different settings. Coming from an Enterprise Application background, I found this being more often the case or the only case. Working with different teams, developer fluctuation, different time zones, different skill sets, a framework guides the development process far better. Vanilla JS is something that should be avoided in team setups. There is too much mental overload that is usually not justified by the benefits. It is like deliberately choosing assembler language when Java or C# would do the job better. Frameworks got a bad rep. For me, they are tools that should be used.
- morrvs 6y ago
  I've heard the Assembly vs. C analogy a couple times now, and find it hard to apply: Assembly languages come in many flavors whereas C is a single, standard abstraction over these. DOM is a single, standard API whereas frameworks/libraries come in many, ever-changing flavors and provide different abstractions over the DOM. It's a very different situation. Also, the level of abstraction that C provides over assembly is amazing. The level of abstraction that React provides over the DOM is comparably low (they are based on the same programming language).
mcjkrw 6y ago
I have experimented with something like this for a new side project. The plan was to have a TypeScript class for each component, and a render function to render them on dom. Then the listeners would be handled directly via addEventListener. Eventually I started having thoughts like - "maybe I could have the render function parse attributes and auto-attach dom events". It became obvious it would become a side project of its own and not a smart use of my time. I settled down for Svelte and I love it.

dukoid 6y ago

Can I claim I don't violate the "No general-purpose utility functions related to the DOM/UI" if I use only one such function? O:) https://github.com/stefanhaustein/notemplate https://github.com/stefanhaustein/notemplate (the demo is just TodoMVC, though)

morrvs 6y ago
:D just to be clear, the rules were made just for the case study. I'd never recommend following these rules in a professional project. They are part of the method of the case study, not its outcome; the outcome is a couple of (hopefully) interesting patterns and insights, without trying to prescribe anything.

morrvs 6y ago

Thanks for reading - original author here. For the precise quote you mentioned I came up with somewhat format rules which prevented building a framework (code-wise) for this case study. The "caveat" you mention is just an explanation for the chosen ruleset; I believe I haven't introduced any general-purpose DOM/UI code in the case study and instead only describe patterns (correct me if I'm wrong!). I agree with your view of framework value as I professionally use React on a daily basis and will continue to do so, for similar reasons :)

noir_lord 6y ago

Of the three you listed Vue is the most 'opinionated' in that it ships with official router, official store (vuex) etc and that is a huge deal. With React and particulary svelte (for now) it's a mishmash of possible choices. Where that bites is when you have 3 choices to make with 4 options. 4^3 === 64 - so any project you pick up/come onto has a 1/64 chance of using a stack you've seen before.

nicoburns 6y ago
True, but routing libraries don't tend to be that complex. Picking up a different is not exactly a big deal.

madoublet 6y ago

Framework churn is real. I no longer recommend JS frameworks simply b/c the opinion of the framework developer drastically changes over time. So, you are constantly re-writing completely valid and working code to keep up with the latest version of the framework. The JS language itself, on the other hand, seems to be very stable with long deprecation cycles and steady improvements. So, it is much easier to build on.

nicoburns 6y ago
React has been stable since ~2015, and there are no signs of that changing.
- madoublet 6y ago
  I can't speak to React. But, both Vue and Angular have seen dramatic changes over the last few years.
  - NiceNamesOrg 6y ago
    Most of the code people have written in Vue 2 is compatible with Vue 3. Vue 3 has just added some additional features. Sure, there are breaking changes, but not to an alarming degree.
    - madoublet 6y ago
      My opinion comes strictly as an indy dev with very limited time and resources. So, any breaking change is frustrating.
    - onion2k 6y ago
      Most of the code people have written in Vue 2 is compatible with Vue 3. All of the code written with React 15 is compatible with React 16. And React 17. And React 18. And so on probably.
      - nicoburns 6y ago

ehnto 6y ago

Using frameworks is far more about hiring and human resources than technology I feel. However, if your "micro framework" follows language idioms and is thin enough you get the best of both worlds, whilst releasing yourself from some of the downsides that come with using a general purpose framework.

treespace89 6y ago
Frameworks make hiring a bit easier it's true. I'm amazed at the number of developers who can't seem to cope with working with custom in house frameworks. I'm talking about fully working systems, with full source code and being walked through the code by the author / maintainer. They fall apart, constantly complaining that the approach is non standard, deprecated, dangerous, unprofessional, untestable. So we are trying more and more to use frameworks, just to be able to hire more easily.
- Vrondi 6y ago
  This just displays the core incompetence in basics that many devs who are dependent on frameworks have.
- ehnto 6y ago
  Definitely agree, developers can get away with a lot of missing knowledge and not realise it, if they're using frameworks from the start of their career. Ideally you could hire senior developers with the skills to work inside boutique software, but I have found "legacy" code turns a lot of people off a project, and most boutique software eventually gets called "legacy" even if it's well architected and running perfectly fine. The skill which I think new devs could differentiate themselves with, is debugging. Familiarising yourself with software patterns definitely puts you ahead, but being able to use debuggers to understand code that has no pattern, that's when you become the kind of bug-squasher/problem-solver that projects like that require. If you have good debugging skills, you can work on any project, because you can find out all the information you need by stepping through the code.

shams93 6y ago

With es6 template strings you can do a lot of heavy lifting with some very simple code. This example still uses es5 to mr that’s insane who on the web is still using ie6?

vanadium 6y ago
IE11. IE11 remains the problem.
- DarkWiiPlayer 6y ago
  In the corporate world, yes (sadly), but for personal and free projects I'd say it's acceptable to just ignore IE entirely and at most include some JS snippet to tell its users to get a real browser.
- throw_m239339 6y ago
  IE11 is an unsecure browser and doesn't even support numerous HTML5 security features. Any business that still relies on IE11 is asking to be hacked, no more, no less, because it also means that these businesses are still running older versions of Windows. Now IE11 isn't even an excuse because $current_year ES version can be transpiled to older ES versions.

wtetzner 6y ago

> These usually end up becoming a custom micro-framework, thereby questioning why you didn't use one of the established and tested libraries/frameworks in the first place. Often a custom micro-framework better suits the needs of a particular project. I've written micro-frameworks for specific projects intentionally, because they did a few things that the established frameworks either didn't do, or it was very difficult to get them to do. An additional benefit was that using the micro frameworks ended up being simpler, and the startup time was much, much faster. Whether or not you use an existing framework depends on how much effort it is to write and test a custom framework vs the amount of effort you'd need to put in to use an existing framework. The ones I've written have been pretty quick to develop, and were also intended to be used for a few different projects that had similar needs. Edit: Just for clarification, the micro frameworks I've written are server-side, if that makes any difference.

notJim 6y ago
> Often a custom micro-framework better suits the needs of a particular project. Fitting the needs of a particular project is frequently a local optimum however. Often, it's much more optimal to focus on the needs of a whole team or even whole company. You can hire people who already know React/Vue/whatever, but there is no one in the world who knows your micro-framework.
- CmdrKrool 6y ago
  But due to its micro-size, it won't take long to learn.
  - notJim 6y ago
    Micro-frameworks have a nasty habit of outgrowing the description, IME.
- randall 6y ago
  It's always "tear it down" or "build it up" at the end of the day. Which one takes more effort is the right one to optimize for with your particular use case. Rails vs Sinatra is a great example.

overgard 6y ago

I think the problem with bespoke frameworks is that many career driven developers won't want to become a specialist in proprietary tools that won't transfer. However... I have this strong suspicion that most projects that use something like React don't really need it. Like, if you're creating something that actually acts like an application and data might be shown in many places it makes a lot of sense, but for something that's just displaying data from a db on a page hit it can be massive overkill.

_the_inflator 6y ago

> adopting an established valid opinion to guide the team's development Different requirements allow for different settings. Coming from an Enterprise Application background, I found this being more often the case or the only case. Working with different teams, developer fluctuation, different time zones, different skill sets, a framework guides the development process far better. Vanilla JS is something that should be avoided in team setups. There is too much mental overload that is usually not justified by the benefits. It is like deliberately choosing assembler language when Java or C# would do the job better. Frameworks got a bad rep. For me, they are tools that should be used.

morrvs 6y ago
I've heard the Assembly vs. C analogy a couple times now, and find it hard to apply: Assembly languages come in many flavors whereas C is a single, standard abstraction over these. DOM is a single, standard API whereas frameworks/libraries come in many, ever-changing flavors and provide different abstractions over the DOM. It's a very different situation. Also, the level of abstraction that C provides over assembly is amazing. The level of abstraction that React provides over the DOM is comparably low (they are based on the same programming language).

mcjkrw 6y ago

I have experimented with something like this for a new side project. The plan was to have a TypeScript class for each component, and a render function to render them on dom. Then the listeners would be handled directly via addEventListener. Eventually I started having thoughts like - "maybe I could have the render function parse attributes and auto-attach dom events". It became obvious it would become a side project of its own and not a smart use of my time. I settled down for Svelte and I love it.