5 ms·

I'm an experienced React developer. I wanted to try out writing a plain vanilla JavaScript application - I enjoy plain JavaScript, it feels close to the metal.

I'm an experienced React developer. I wanted to try out writing a plain vanilla JavaScript application - I enjoy plain JavaScript, it feels close to the metal. It wasn't long before I was craving an application framework that allowed me to cleanly organise and structure my application instead of it rapidly becoming a spaghetti. I also craved the ability to write small simple functions for making components. And I wanted a sensible way to organise data flow through the application. And I really, really wanted to be able to write in a declarative programming style instead of imperative - this is something you don't come to appreciate fully until you've lived it. And I don't care what anyone else says - I love JSX - it's totally makes sense to me. So despite a solid effort to try to go to vanilla JavaScript I've decided that a really good JavaScript application framework - whatever one you like - is a good thing. I'll leave vanilla JavaScript to the birds.

triceratops 6y ago
Pretty much this. I knew all of the things she wrote about but all I could think was "I can't imagine writing foo.classList.add and remove 100 times. That's going to create some major spaghetti code once that project grows beyond a couple of pages"
- deleted 6y ago
  [deleted]
- bigiain 6y ago
  There;s some deep truth here, and I suspect it's about a fundamental difference between "writing a plain vanilla JavaScript application" and "I wanted to use the same HTML to generate both a PDF (with Prince) and to make an interactive version of the questions." Reimplementing gmail or slack in html/css/vanilla-javascript, without an "application frameowrk is no doubt an exercise in futility. At the same time, reaching for React/Fluttr/Angular/frontend-framework-de-jour when all you need is to show and hide divs and maybe do css or scroll animations between them is, in my mind, an equally bad decision. (I can totally see why the framework-de-jour option gets chosen so often though - because no matter how written-in-stone the original specs saying "There wil be no functinality required beyond showing/hiding divs and css animations between them" are, we've all seen projects where a last minute critical/showstopper requirement for the web page to include something insane like a fully functional email client gets dropped in the FE dev's lap the Friday afternoon before launch Monday. Sure, the FE dev made the choice to use React, and while some (perhaps a lot?) of that is "resume driven development", at least some of the blame is on bad sales people and project managers as well...)
  - deleted 6y ago
    [deleted]
  - triceratops 6y ago
    > reaching for React/Fluttr/Angular/frontend-framework-de-jour when all you need is to show and hide divs and maybe do css or scroll animations between them is, in my mind, an equally bad decision. Do people really do that? To me, that reflects bad frontend engineering practice. Even so for something like that, I'd use jQuery or something similar, because it's a much nicer API than the DOM.
    - dgb23 6y ago
      How do you generate html in the first place? With React you have the same UI logic in one uniform framework. Whether you render statically, on request or in the client doesn’t split up your code. Everything plays together nicely. You get sensible editor support with linting and static analysis and more comprehensive error messages.
    - adrianhel 6y ago
      Why bother with jQuery? I don't see the value add anymore.
      - tambourine_man 6y ago
        Read this whole thread. People are rewriting it over and over again because it’s out of fashion.
  - tonyedgecombe 6y ago
    >Reimplementing gmail or slack in html/css/vanilla-javascript, without an "application frameowrk is no doubt an exercise in futility. I'm pretty sure gmail started out without a framework.
    - bigiain 6y ago
      > I'm pretty sure gmail started out without a framework. I'm pretty sure you're right. I'm also pretty sure it's not only one of the big reasons frameworks exists as they do today (because it's perhaps one of the earliest and probably the most famous example of a web app that 100% _needs_ a framework for all the reasons discussed everywhere in this thread), but that it's also the poster child case of why every ambitious/opinionated/inexperienced FE dev builds their own framework (Of _course_ I can't use jQuery/Angular/React/Fluttr! _My_ ToDo list app is _groundbreaking and special_ - just like gmail was in 2004, I'll need to write my own framework for this. Stand back! <flexes>") ;-)
- rimliu 6y ago
  And now we witness everyday spaghetti code written on the top of some framework and each noodle is wrapped five times in a needless abstraction. There is nothing preventing you to write nice and clean code in plain JS.
  - BigJono 6y ago
    Yeah no shit. JS is the only community I've seen where code size scales with dependency count in the positive direction. It's ridiculous.
    - deleted 6y ago
      [deleted]
jonny383 6y ago
> it feels close to the metal. Please tell me you're joking?
- andrewstuart 6y ago
  Cmon. Close the the "browser metal". I of course don't mean close to the CPU that would be silly.
  - steve_adams_86 6y ago
    "Close to the Chrome"
- rasz 6y ago
  I mean he is a React developer after all, less than 3 levels of abstraction is greased lightning.
  - andrewstuart 6y ago
    As a React developer I have the strictest policy to never go lower level than the browser and I never touch other fields of computing. I started my computing career in 1986 knowing only React and I'll get to the end of it knowing nothing else.
    - bigiain 6y ago
      >> it feels close to the metal > never go lower level than the browser So maybe "close to the DOM" rather than "close to the metal"? :-) On the other hand, if you ever want a project to get you out of your comfort-zone(/rut?) - check this out: https://www.espruino.com/ https://www.espruino.com/ You _can_ go "bare metal" and still use your hard won javascript skills... > I started my computing career in 1986 knowing only React That's a big gap in your memory between 1986 and when React was first released in 2013. Or _maybe_ 2010 or 2011 if you were working inside Facebook back before they released it publicly...
      - 6y ago
orange8 6y ago
Kudos on pushing yourself beyond your comfort zone. I think you were still thinking in terms of React though, with statements like "I also craved the ability to write small simple functions for making components". Maybe explore a template based approach instead, with the help of a library like Mustache.js so that you're not overwhelmed by having to do it all the first time.
stefano 6y ago
You can have a nicely organized JS project without using a framework, albeit you can expect a bit more boilerplate. There are many approaches you can take. The following is an MVC approach I'm trying out in a personal project. It's organized as follows: There's a subscribe/emit system, where you can link functions to run when an object sends an emit signal. This can be done in a couple dozen lines of code. Example: https://gist.github.com/stefano/32cbe9bef5a68ecb3286113369d8cf0b https://gist.github.com/stefano/32cbe9bef5a68ecb3286113369d8... Models are JavaScript objects. They have methods to read their state and to update it. The methods that update the state need to call emit() so all subscribers are notified. Views are functions. They return an object with 2 properties: a DOM node (the root of the view), and an update function. The update function takes a model instance, and updates the DOM structure accordingly. If a view supports user interaction, it'll take a delegate object as a parameter. The view will add event handlers which call the delegate object. Example of a text input with a label and optional validation error: https://gist.github.com/stefano/2135cc15470cceba4ac2d344fe2e26dd https://gist.github.com/stefano/2135cc15470cceba4ac2d344fe2e... The controller is a function or class. It returns an object with its root view and a function to run when the controller is destroyed for cleanup. It can either take a model as a parameter or instantiate it. It also instantiates the root view, passing itself (or another object) as the delegate. In the delegate methods, it calls the model update methods. The controller subscribes the view to model changes, and unsubscribes them when it's destroyed. Alternatively, the view can subscribe/unsubscribe itself. With this approach, views can be composed by calling the view functions from inside another view, passing down a delegate and adding the root DOM node to the parent view DOM structure. The controller and the model are completely independent of the DOM. The model can be tested independently. The controller can be tested with a mock view. The view can be tested by passing in a mock model. Views only depend on their initial state and the state of the model passed to the update function.
- z3t4 6y ago
  The trick is to make as much as possible static. Just pure functions. Second trick is to have only one way direction, eg components only listen to events, they don't emit events, then they don't have to depend on each other, which in turn will lead to better reusability and less spaghetti.
christophilus 6y ago
I had the same experience recently. I love using lightweight web apps. But I much prefer writing with React-like technology. Inferno is a great React alternative, FYI that keeps the app a little lighter while still providing a sane developer experience.
rhlsthrm 6y ago
It seems like WebAssembly will allow high level languages to get close to the "browser metal", so I think we will see declarative frameworks that are closer to the metal compared to React. I'm wondering if Rust is the best language to learn to get a headstart on that.
elwell 6y ago
> I enjoy plain JavaScript, it feels close to the metal Never thought I'd hear the day...

triceratops 6y ago

Pretty much this. I knew all of the things she wrote about but all I could think was "I can't imagine writing foo.classList.add and remove 100 times. That's going to create some major spaghetti code once that project grows beyond a couple of pages"

deleted 6y ago
[deleted]
bigiain 6y ago
There;s some deep truth here, and I suspect it's about a fundamental difference between "writing a plain vanilla JavaScript application" and "I wanted to use the same HTML to generate both a PDF (with Prince) and to make an interactive version of the questions." Reimplementing gmail or slack in html/css/vanilla-javascript, without an "application frameowrk is no doubt an exercise in futility. At the same time, reaching for React/Fluttr/Angular/frontend-framework-de-jour when all you need is to show and hide divs and maybe do css or scroll animations between them is, in my mind, an equally bad decision. (I can totally see why the framework-de-jour option gets chosen so often though - because no matter how written-in-stone the original specs saying "There wil be no functinality required beyond showing/hiding divs and css animations between them" are, we've all seen projects where a last minute critical/showstopper requirement for the web page to include something insane like a fully functional email client gets dropped in the FE dev's lap the Friday afternoon before launch Monday. Sure, the FE dev made the choice to use React, and while some (perhaps a lot?) of that is "resume driven development", at least some of the blame is on bad sales people and project managers as well...)
- deleted 6y ago
  [deleted]
- triceratops 6y ago
  > reaching for React/Fluttr/Angular/frontend-framework-de-jour when all you need is to show and hide divs and maybe do css or scroll animations between them is, in my mind, an equally bad decision. Do people really do that? To me, that reflects bad frontend engineering practice. Even so for something like that, I'd use jQuery or something similar, because it's a much nicer API than the DOM.
  - dgb23 6y ago
    How do you generate html in the first place? With React you have the same UI logic in one uniform framework. Whether you render statically, on request or in the client doesn’t split up your code. Everything plays together nicely. You get sensible editor support with linting and static analysis and more comprehensive error messages.
  - adrianhel 6y ago
    Why bother with jQuery? I don't see the value add anymore.
    - tambourine_man 6y ago
      Read this whole thread. People are rewriting it over and over again because it’s out of fashion.
- tonyedgecombe 6y ago
  >Reimplementing gmail or slack in html/css/vanilla-javascript, without an "application frameowrk is no doubt an exercise in futility. I'm pretty sure gmail started out without a framework.
  - bigiain 6y ago
    > I'm pretty sure gmail started out without a framework. I'm pretty sure you're right. I'm also pretty sure it's not only one of the big reasons frameworks exists as they do today (because it's perhaps one of the earliest and probably the most famous example of a web app that 100% _needs_ a framework for all the reasons discussed everywhere in this thread), but that it's also the poster child case of why every ambitious/opinionated/inexperienced FE dev builds their own framework (Of _course_ I can't use jQuery/Angular/React/Fluttr! _My_ ToDo list app is _groundbreaking and special_ - just like gmail was in 2004, I'll need to write my own framework for this. Stand back! <flexes>") ;-)
rimliu 6y ago
And now we witness everyday spaghetti code written on the top of some framework and each noodle is wrapped five times in a needless abstraction. There is nothing preventing you to write nice and clean code in plain JS.
- BigJono 6y ago
  Yeah no shit. JS is the only community I've seen where code size scales with dependency count in the positive direction. It's ridiculous.
  - deleted 6y ago
    [deleted]

jonny383 6y ago

> it feels close to the metal. Please tell me you're joking?

andrewstuart 6y ago
Cmon. Close the the "browser metal". I of course don't mean close to the CPU that would be silly.
- steve_adams_86 6y ago
  "Close to the Chrome"
rasz 6y ago
I mean he is a React developer after all, less than 3 levels of abstraction is greased lightning.
- andrewstuart 6y ago
  As a React developer I have the strictest policy to never go lower level than the browser and I never touch other fields of computing. I started my computing career in 1986 knowing only React and I'll get to the end of it knowing nothing else.
  - bigiain 6y ago
    >> it feels close to the metal > never go lower level than the browser So maybe "close to the DOM" rather than "close to the metal"? :-) On the other hand, if you ever want a project to get you out of your comfort-zone(/rut?) - check this out: https://www.espruino.com/ https://www.espruino.com/ You _can_ go "bare metal" and still use your hard won javascript skills... > I started my computing career in 1986 knowing only React That's a big gap in your memory between 1986 and when React was first released in 2013. Or _maybe_ 2010 or 2011 if you were working inside Facebook back before they released it publicly...
    - 6y ago

orange8 6y ago

Kudos on pushing yourself beyond your comfort zone. I think you were still thinking in terms of React though, with statements like "I also craved the ability to write small simple functions for making components". Maybe explore a template based approach instead, with the help of a library like Mustache.js so that you're not overwhelmed by having to do it all the first time.

stefano 6y ago

You can have a nicely organized JS project without using a framework, albeit you can expect a bit more boilerplate. There are many approaches you can take. The following is an MVC approach I'm trying out in a personal project. It's organized as follows: There's a subscribe/emit system, where you can link functions to run when an object sends an emit signal. This can be done in a couple dozen lines of code. Example: https://gist.github.com/stefano/32cbe9bef5a68ecb3286113369d8cf0b https://gist.github.com/stefano/32cbe9bef5a68ecb3286113369d8... Models are JavaScript objects. They have methods to read their state and to update it. The methods that update the state need to call emit() so all subscribers are notified. Views are functions. They return an object with 2 properties: a DOM node (the root of the view), and an update function. The update function takes a model instance, and updates the DOM structure accordingly. If a view supports user interaction, it'll take a delegate object as a parameter. The view will add event handlers which call the delegate object. Example of a text input with a label and optional validation error: https://gist.github.com/stefano/2135cc15470cceba4ac2d344fe2e26dd https://gist.github.com/stefano/2135cc15470cceba4ac2d344fe2e... The controller is a function or class. It returns an object with its root view and a function to run when the controller is destroyed for cleanup. It can either take a model as a parameter or instantiate it. It also instantiates the root view, passing itself (or another object) as the delegate. In the delegate methods, it calls the model update methods. The controller subscribes the view to model changes, and unsubscribes them when it's destroyed. Alternatively, the view can subscribe/unsubscribe itself. With this approach, views can be composed by calling the view functions from inside another view, passing down a delegate and adding the root DOM node to the parent view DOM structure. The controller and the model are completely independent of the DOM. The model can be tested independently. The controller can be tested with a mock view. The view can be tested by passing in a mock model. Views only depend on their initial state and the state of the model passed to the update function.

z3t4 6y ago
The trick is to make as much as possible static. Just pure functions. Second trick is to have only one way direction, eg components only listen to events, they don't emit events, then they don't have to depend on each other, which in turn will lead to better reusability and less spaghetti.

christophilus 6y ago

I had the same experience recently. I love using lightweight web apps. But I much prefer writing with React-like technology. Inferno is a great React alternative, FYI that keeps the app a little lighter while still providing a sane developer experience.

rhlsthrm 6y ago

It seems like WebAssembly will allow high level languages to get close to the "browser metal", so I think we will see declarative frameworks that are closer to the metal compared to React. I'm wondering if Rust is the best language to learn to get a headstart on that.

elwell 6y ago

> I enjoy plain JavaScript, it feels close to the metal Never thought I'd hear the day...