7 ms·

Lots of reasons: 1) No need for 3.7GB of node_modules to crank out a simple site 2) Single solution, easier to bring on junior developers and reason about app

by kirse 5y ago

Lots of reasons: 1) No need for 3.7GB of node_modules to crank out a simple site 2) Single solution, easier to bring on junior developers and reason about application logic 3) Caching much easier, too many people think they need real-time push when NRT-polling + caching is far easier and more performant Broadly speaking it's often a case of YAGNI. The JS ecosystem really does still suck for its complexity, I remember that every time I ramp up a new developer onto a React project. It's smoothed out with tooling but the litany of JSON configuration files and the mess created by hot-reload + proxying + microservices etc etc. Often just YAGNI. People today don't remember the VB6 IDE days where you could slap a button on a Form, write a line of code for a MessageBox, and smash that play button with zero effort. JS development is often about working your way through a tangled spider-web of helper utilities and config files and JS modules at which point when it finally works you're afraid to rev anything.

recursivedoubts 5y ago
bang on, especially that last part a bit focus of htmx, alpinejs (and htmx's sister project, https://hyperscript.org https://hyperscript.org) is putting the logic on the element, so you can see exactly what a button, etc. does just by looking at it, and without trawling through ten files of indirection i am trying to popularize the term Locality of Behavior to describe this design goal: https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/
- lhorie 5y ago
  I'm curious about your thoughts on that locality of behavior idea vs aspects of precision and composability. For example, the argument goes that the behavior of `hx-get` is obvious upon inspection, but the terseness is achieved by omitting the event type (i.e. it's assumed/implied that hx-get runs on click). The quintessential widget where that breaks down is the table w/ checkboxes for batch operations over an arbitrary subset of rows. That's where less DSL-ish frameworks' abstraction via state management tend to shine, since they allow the developer to more precisely specify how disparate checkboxes relate to a bigger picture that may also involve table sorting (both client and server varieties) or nested modal structures or other forms of complexity.
- EugeneOZ 5y ago
  Button should not have any behavior, it should generate an event. Your app can have one or multiple listeners for this event. This pattern is battle-tested for decades.
  - recursivedoubts 5y ago
    OK, but the response to that event should be localized to the button. https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/
  - JasonCannon 5y ago
    Why? Have any reading on this?
    - EugeneOZ 5y ago
      Of course :) Have you tried to find something before asking? https://en.m.wikipedia.org/wiki/Reactive_programming https://en.m.wikipedia.org/wiki/Reactive_programming https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener https://developer.mozilla.org/en-US/docs/Web/API/EventTarget...
      - JasonCannon 5y ago
        1.) Don't be a jackass. 2.) I know what reactive programming is, I make extensive use of RxJS at work. And I obviously know what an event listener is. I was asking why is it wrong to have the button have functionality and only emit events. And I did google that, but nothing from your comment you posted that I googled lead to anything about reactive programming.
        EugeneOZ 5y ago
        1) You started it :) Your sarcastic tone was ridiculously obvious :) I gave you the links - where is your gratitude? You’ve only brought your sarcasm here. 2) Oh, RxJS is synonymous with reactive programming for you? Lol, keep learning :)
snowl 5y ago
If your node_modules is 3.7GB, you are doing something seriously wrong. My node_modules for a 100k+ line app is 243MB and that includes all my dependencies, compiler and testing frameworks which seems very reasonable. All compiled down to a 4MB blob which seems pretty reasonable for a big app :)
- kirse 5y ago
  Certainly. My hope is things like WASM eventually make Javascript obsolete if we're into pushing giant blobs of client UI over the wire. Blazor / Bolero in C#/F# are promising starts in that direction.
- sadn1ck 5y ago
  How do you compile it to a single blob?
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - ruszki 5y ago
    With tree shaking, and it is usually split into several files for caching purposes and to download only what's really necessary.
- drcongo 5y ago
  3.7GB was obviously an exaggeration for comic effect, however, I laughed just as hard at 243MB. How on earth do you think that's OK?
- rak1507 5y ago
  243 MB?! If that's all code (which is unlikely, sure) and it has an average line length of 100, that's 2.4 MILLION lines! Do you really need that, (no), or have you just 'stockholm syndrome'-d yourself into believing this is not a problem?
egeozcan 5y ago
As a developer who worked both with Windows Forms and React, IMO the only explanation for longing for the former could be that lovely nostalgia feeling when you already know what react offers. I think people approach it with prejudice (ew, Javascript!) and never properly learn it. There are projects where react would be overkill but many benefit from the clear separation of the front end. Also configuring a react project is easier than many other projects I've seen in my career. People just love getting internet points by constantly talking about left-pad, node_modules size, config files etc. I personally know how crazy managing maven or gradle (.gradle folder hell) or nuget or composer or pip (venv or virtualenv...) or [name of your favorite package manager] can get, so I'm thankful for the great community that work on the problems with the npm.
- brylie 5y ago
  I believe the Model View Controller or Model Template View architectures provide sufficient separation of concerns without requiring separate codebases, teams, tooling, and project management.
  - egeozcan 5y ago
    I didn't mean the classic separation of concerns. I meant that front-end development should be taken seriously enough to (sometimes) warrant its own focused team. A proper FE developer who knows about accessibility (not just ARIA-attributes but also contrast and usability), UX, semantics, and also being capable of delivering performant user interfaces is rare these days, because people think full-stack development really is a thing. I think it is one of those mythical things like a 1000x engineer. People think that they can get away with 90s style websites, but please test stuff with a screen-reader, and also while you're there get some front-end consulting, you will be surprised how badly you may be doing. IMHO, many need dedicated FE development. Whether they use React or not, I think many do. You can distribute many responsibilities on non-technical members of the team, but then you start thinking "couldn't they just learn a bit templating so I don't invest so much time on implementing their seemingly never-ending requirements"! BTW, this separation is of course also possible with your traditional MVC stack, which I also use in my personal projects a lot, in which React is indeed overkill, and there are many cases that a bunch of templates deliver all the things you may ever need. If it gets complicated enough some day, return your View Model as JSON and there you have a perfect API. IMHO REST APIs aren't suitable for any dynamic front-end development anyway. The only reason I wrote that single sentence in my previous original comment is that React forces your hand a bit, in this matter. It's a small point among other things.
EugeneOZ 5y ago
1) Who cares about the size of node_modules? What is the reason to care about it at all? 2) “Junior-centered” app has to be simple as a “ToDo list example”, all the time. It's not possible for the real apps - they constantly evolve, and to keep their code readable and clean you need skilled developers, not the other way around.
pjmlp 5y ago
Using JS/CSS in classical Java and .NET frameworks is so easy (and bleeding fast) when compared with dealing with 1). Unfortunely it is an option I can only dictacte on personal projects.

by kirse 5y ago

recursivedoubts 5y ago

bang on, especially that last part a bit focus of htmx, alpinejs (and htmx's sister project, https://hyperscript.org https://hyperscript.org) is putting the logic on the element, so you can see exactly what a button, etc. does just by looking at it, and without trawling through ten files of indirection i am trying to popularize the term Locality of Behavior to describe this design goal: https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/

lhorie 5y ago
I'm curious about your thoughts on that locality of behavior idea vs aspects of precision and composability. For example, the argument goes that the behavior of `hx-get` is obvious upon inspection, but the terseness is achieved by omitting the event type (i.e. it's assumed/implied that hx-get runs on click). The quintessential widget where that breaks down is the table w/ checkboxes for batch operations over an arbitrary subset of rows. That's where less DSL-ish frameworks' abstraction via state management tend to shine, since they allow the developer to more precisely specify how disparate checkboxes relate to a bigger picture that may also involve table sorting (both client and server varieties) or nested modal structures or other forms of complexity.
EugeneOZ 5y ago
Button should not have any behavior, it should generate an event. Your app can have one or multiple listeners for this event. This pattern is battle-tested for decades.
- recursivedoubts 5y ago
  OK, but the response to that event should be localized to the button. https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/
- JasonCannon 5y ago
  Why? Have any reading on this?
  - EugeneOZ 5y ago
    Of course :) Have you tried to find something before asking? https://en.m.wikipedia.org/wiki/Reactive_programming https://en.m.wikipedia.org/wiki/Reactive_programming https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener https://developer.mozilla.org/en-US/docs/Web/API/EventTarget...
    - JasonCannon 5y ago
      1.) Don't be a jackass. 2.) I know what reactive programming is, I make extensive use of RxJS at work. And I obviously know what an event listener is. I was asking why is it wrong to have the button have functionality and only emit events. And I did google that, but nothing from your comment you posted that I googled lead to anything about reactive programming.
      - EugeneOZ 5y ago
        1) You started it :) Your sarcastic tone was ridiculously obvious :) I gave you the links - where is your gratitude? You’ve only brought your sarcasm here. 2) Oh, RxJS is synonymous with reactive programming for you? Lol, keep learning :)

snowl 5y ago

If your node_modules is 3.7GB, you are doing something seriously wrong. My node_modules for a 100k+ line app is 243MB and that includes all my dependencies, compiler and testing frameworks which seems very reasonable. All compiled down to a 4MB blob which seems pretty reasonable for a big app :)

kirse 5y ago
Certainly. My hope is things like WASM eventually make Javascript obsolete if we're into pushing giant blobs of client UI over the wire. Blazor / Bolero in C#/F# are promising starts in that direction.
sadn1ck 5y ago
How do you compile it to a single blob?
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- ruszki 5y ago
  With tree shaking, and it is usually split into several files for caching purposes and to download only what's really necessary.
drcongo 5y ago
3.7GB was obviously an exaggeration for comic effect, however, I laughed just as hard at 243MB. How on earth do you think that's OK?
rak1507 5y ago
243 MB?! If that's all code (which is unlikely, sure) and it has an average line length of 100, that's 2.4 MILLION lines! Do you really need that, (no), or have you just 'stockholm syndrome'-d yourself into believing this is not a problem?

egeozcan 5y ago

As a developer who worked both with Windows Forms and React, IMO the only explanation for longing for the former could be that lovely nostalgia feeling when you already know what react offers. I think people approach it with prejudice (ew, Javascript!) and never properly learn it. There are projects where react would be overkill but many benefit from the clear separation of the front end. Also configuring a react project is easier than many other projects I've seen in my career. People just love getting internet points by constantly talking about left-pad, node_modules size, config files etc. I personally know how crazy managing maven or gradle (.gradle folder hell) or nuget or composer or pip (venv or virtualenv...) or [name of your favorite package manager] can get, so I'm thankful for the great community that work on the problems with the npm.

brylie 5y ago
I believe the Model View Controller or Model Template View architectures provide sufficient separation of concerns without requiring separate codebases, teams, tooling, and project management.
- egeozcan 5y ago
  I didn't mean the classic separation of concerns. I meant that front-end development should be taken seriously enough to (sometimes) warrant its own focused team. A proper FE developer who knows about accessibility (not just ARIA-attributes but also contrast and usability), UX, semantics, and also being capable of delivering performant user interfaces is rare these days, because people think full-stack development really is a thing. I think it is one of those mythical things like a 1000x engineer. People think that they can get away with 90s style websites, but please test stuff with a screen-reader, and also while you're there get some front-end consulting, you will be surprised how badly you may be doing. IMHO, many need dedicated FE development. Whether they use React or not, I think many do. You can distribute many responsibilities on non-technical members of the team, but then you start thinking "couldn't they just learn a bit templating so I don't invest so much time on implementing their seemingly never-ending requirements"! BTW, this separation is of course also possible with your traditional MVC stack, which I also use in my personal projects a lot, in which React is indeed overkill, and there are many cases that a bunch of templates deliver all the things you may ever need. If it gets complicated enough some day, return your View Model as JSON and there you have a perfect API. IMHO REST APIs aren't suitable for any dynamic front-end development anyway. The only reason I wrote that single sentence in my previous original comment is that React forces your hand a bit, in this matter. It's a small point among other things.

EugeneOZ 5y ago

1) Who cares about the size of node_modules? What is the reason to care about it at all? 2) “Junior-centered” app has to be simple as a “ToDo list example”, all the time. It's not possible for the real apps - they constantly evolve, and to keep their code readable and clean you need skilled developers, not the other way around.

pjmlp 5y ago

Using JS/CSS in classical Java and .NET frameworks is so easy (and bleeding fast) when compared with dealing with 1). Unfortunely it is an option I can only dictacte on personal projects.