16 ms·

The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state. That's it - that's the problem they solve. People s

The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state. That's it - that's the problem they solve. People started writing vanilla HTML/CSS/JS and struggling to make "reactivity" (hence React) work well when web applications got complex with a lot of state to manage. So we started building frameworks on frameworks and abstractions on abstractions and ended up where we are today. It's gone a bit far but the overall purpose is a valid one. (From someone who has used React professionally but uses vanilla HTML/CSS/JS for his personal website)

dbxkcichhdfufu 4y ago
Browsers already managed state just fine. We just didn't like the way it looked.
- have_faith 4y ago
  Browsers do nothing to help us manage state outside of individual elements.
  - hellcow 4y ago
    That’s actually all I use for state management. Elements pass data to children through attributes and bubble data up through events. It’s worked well for us on a complex front-end using native web components.
    - bornfreddy 4y ago
      That's basically a home-made React (& co.) duplicate (which is great). This simplifies development considerably, because you break the original problem into a) updating the state and b) translating the state into UI elements, and the framework (hopefully) automatically updates UI as needed.
    - have_faith 4y ago
      This is called prop drilling. It technically works for any size or complexity of app if you're willing to make every intermediate component have knowledge about every possible piece of state that might be wanted by a component lower in the tree. It's extremely cumbersome though.
      - P5fRxh5kUvp2th 4y ago
        Back in my day we could search for child elements with specific attributes without needing the intermediate elements to know anything about it. What REALLY happened is the shadow DOM. People decided it was too slow and created an intermediate representation. That then created all kinds of OTHER problems that started resulting in solutions that wouldn't have been necessary without the shadow DOM. A shadow DOM is basically a cache, with all the problems that entails.
        dalmo3 4y ago
        > Note that the shadow DOM is not a new thing by any means — browsers have used it for a long time to encapsulate the inner structure of an element. https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
        P5fRxh5kUvp2th 4y ago
        And for even longer than that, it was a term describing the technique of keeping a tree-like structure that would gather updates so you could eventually update the actual DOM all in one go because updating the DOM piecemeal was slow. The term was popularized long before "web components" was a thing, and in fact, that's where they got the name.
        creatable 4y ago
        Do you mean virtual DOM?
      - deleted 4y ago
        [deleted]
- ozim 4y ago
  Which state are you referring to? I feel parent poster is talking about different state than what you have in mind.
  - dbxkcichhdfufu 4y ago
    The state that matters to users. All the rest is lies we tell ourselves. There's a reason developers are constantly inventing ways to remove state from their code. Managing state is messy. Frameworks simply move it around. Most react apps would be better off written in PHP, html, and progressively enhanced JS. This is coming from a react developer. Most of what I do is bullshit work someone else invented for me. But it pays well so ohwell.
jraph 4y ago
> The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state. I think that's it. I wonder how far we could go with vanilla js + a dead simple central store implementation that would help update the UI at different places when a value changes. You might end up re-inventing Svelte by attempting this though.
- CraigJPerry 4y ago
  Someone posted this here a while back: https://github.com/1Marc/todomvc-vanillajs-2022/tree/main/js https://github.com/1Marc/todomvc-vanillajs-2022/tree/main/js - i bookmarked it because i thought it was well done
  - jraph 4y ago
    Very interesting indeed. That's some food for thought. Though I should note that if this code has a "store.js" file, this is not the kind of store that I had in mind. More like the Svelte store [1], or Redux (which I find awfully complex). I didn't know the "storage" event on Window [2] (which, for the record, triggers when localStorage is modified from another page. Does not trigger when modified from the same page, which makes localStorage not sufficient as-is to build the kind of store I'm referring to). [1] https://svelte.dev/tutorial/writable-stores https://svelte.dev/tutorial/writable-stores [2] https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event https://developer.mozilla.org/en-US/docs/Web/API/Window/stor...
    - CraigJPerry 4y ago
      >> Does not trigger when modified from the same page I'm thinking that's the purpose of https://github.com/1Marc/todomvc-vanillajs-2022/blob/main/js/store.js#L25 https://github.com/1Marc/todomvc-vanillajs-2022/blob/main/js... - without dispatching that custom save event, there wouldn't be a way to react at any other locations on the same page to the store updating.
- numtel 4y ago
  In a recent project, I wrote my own template class that works kind of like Lithtml but without any kind of magic reactivity. It just rerenders when properties are updated through the "set()" method. https://github.com/numtel/democratic-capital/blob/master/src/utils/Template.js https://github.com/numtel/democratic-capital/blob/master/src... An example template: https://github.com/numtel/democratic-capital/blob/master/src/components/Overview.js https://github.com/numtel/democratic-capital/blob/master/src...
samwillis 4y ago
> keep the UI in sync with state This is absolutely true, however there are some newer tools that are appearing that make this much easer with vanilla html - htmx, hyperscript, alpine.js for example (links below). These newer tools are all made possible due to the “new”(ish) MutationObserver api, it allows you to intercept new dom elements being placed into the document. These libraries let you simple decorate your “real” html with extra attributes enabling easer client side state management. No build step required. My hope is that a combination of these type of tools, js modules and web components will result in dropping all js build tools. With http2/3 we don’t really need bundling. In many ways it the bundling and transpiling process that has contributed the most to the friction with JS development. My other observation would be that as js frameworks have evolved they have become more “enterprise” ready, adding tooling (complex central state management, strict typing) to make working in large teams on very large codebases easer. Much of this isn’t really necessary for the majority of we development. https://htmx.org/ https://htmx.org/ https://hyperscript.org/ https://hyperscript.org/ https://alpinejs.dev/ https://alpinejs.dev/
- xmonkee 4y ago
  It's crazy that we posted almost the exact same thing at the same time: https://news.ycombinator.com/item?id=32781674 https://news.ycombinator.com/item?id=32781674
  - 9935c101ab17a66 4y ago
    Both your comments are very helpful, so I’m glad you did :)
- shafyy 4y ago
  To that list I'd add Hotwire (especially Stimulus: https://stimulus.hotwired.dev https://stimulus.hotwired.dev). I use with Rails, but it's framework/backend agnostic.
- symlinkk 4y ago
  But if you’re going to use a framework like HTMX and the others you mentioned, why not just use React? Vanilla JS is great because it’s universally available, if you’re choosing to drop that advantage I would just go with React.
daveslash 4y ago
Re >> From someone who has used React professionally but uses vanilla HTML/CSS/JS for his personal website" What a refreshing perspective. My personal site is also vanilla HTML/CSS/JS on a self hosted server. I constantly catch flak from all of my software engineering friends for it too, and I'm a little burned out on it. Edit: I'm a bit burned out on the flak and defending my position; not burned out on the approach :-)
- jraph 4y ago
  Please don't burn out for this. Vanilla HTML/CSS/JS is just a very right way of building a website. I don't know how we ended up having to even debate about this. Don't worry, just enjoy the simplicity, the zen and the lightness of this. (from a professional web developer, if it even matters - but the web, especially JS, was not targeted at professional web developers, which is the reason why JS is so "forgiving" - or was intended as such, but that failed miserably if you ask me)
  - rodolphoarruda 4y ago
    Yes. Some things should be designed as simple as possible so they can last. https://jeffhuang.com/designed_to_last https://jeffhuang.com/designed_to_last
  - daveslash 4y ago
    I've updated my comment to reflect that I'm burned out on catching the flak, but not the work itself. Personally, I love basking in the zen of the simplicity! I used to be a professional web developer in a former life, but these days I'm more medical-device and embedded focused. I moved out of the web space around the time that AngularJS was becoming the hot-new-thing, for better or worse.
- DanAtC 4y ago
  A good engineer knows which tools are right for the job.
- kaeruct 4y ago
  Those are some strange friends. Who cares what you use on your own website?
pier25 4y ago
> to make "reactivity" (hence React) You put it in quotes but some might be missing the point you're making which is that React is not reactive. See this quote from the docs: > There is an internal joke in the team that React should have been called “Schedule” because React does not want to be fully “reactive”. https://reactjs.org/docs/design-principles.html#scheduling https://reactjs.org/docs/design-principles.html#scheduling
- pier25 4y ago
  Another point I'd like to make is that you don't really need reactivity. Frameworks like Mithril or Imba are not reactive, at all, and they work just fine for many use cases. The advantage is that state can be just vanilla JS. No need for any abstraction. For example Mithril re-renders everything to the VDOM after a user event (click, etc) automatically. You can also tell Mithril to redraw [0] eg if you have a WS handler or something state change not related to user input. I think Imba works very similarly but I don't have much experience with it. It's a super simple mental model which I like a lot more than anything else. I'm mainly using Svelte now though for other reasons. [0] https://mithril.js.org/redraw.html https://mithril.js.org/redraw.html
xmonkee 4y ago
>The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state. This isn't wrong, but going one level down, this is how it bites you: - The imperative DOM api just suuuucks. Please try it for yourself to see. Even if you're writing a very limited bit of reactivity in your app, you will be forced to invent your own declarative framework very soon. - Very hard to make reusable components (at least before webcomponents, which I haven't used personally) If you want to stay close to vanilla, I recommend one of the following solutions: 1) https://htmx.org/ https://htmx.org/ 2) https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript 3) https://github.com/vuejs/petite-vue https://github.com/vuejs/petite-vue
- soulofmischief 4y ago
  If you like hyperscript, it's worth checking out mithril. https://mithril.js.org https://mithril.js.org
  - gzer0 4y ago
    What about adamant? I heard that is the next level above mithril.
    - Legion 4y ago
      This sequence of comments is the JS ecosystem in a nutshell. Hear about something new, then immediately hear about its multiple successors/replacements.
      - soulofmischief 4y ago
        Mithril uses hyperscript as its foundation, it builds upon it as opposed to replacing/succeeding it :) Check it out, it's the kind of framework you pick and stick with for 20+ years. Zero bullshit compared to its peers.
        ovao 4y ago
alfonsodev 4y ago
I'm in web development since 2000s, at that time there was pretty good web authoring tools like Macromedia Dreamweaver. Everything got complicated because a fundamental limitation of the HTML document model: having dynamic pages. Imagine creating and maintaining a catalog by having a single .html file for each item in the catalog. I believe with Dreamweaver MX you could have sort of a template and generate the static pages. I think this solution wasn't massively adopted because you had to rely on Macromedia server side ( Cold Fusion ). That was when PHP and ASP entered the scene allowing you to have dynamic pages in a linux or windows server. At that time, javascript implementations and rendering engines had massive discrepancies, Internet Explorer, Mozilla .., and to solve that emerge the first (that I recall) massively adopted javascript libraries, jQuery & Motools. Then Ajax[1] became popular because it made posible to interact with the server without refreshing the page, and that's when managing state became a problem in the browser as SPA started to become more and more complex. It's amusing seeing how we went full circle when SPAs have gotten so heavy and slow that now static page generation it's sold as a killer feature in Nextjs. When we could do this in 99's version of Dreamweaver with a nice UI. Maybe it's not a fair comparison, but you get my point, >20 years and see where we are.
- rcarmo 4y ago
  $DIVINITY, how I miss Dreamweaver and Fireworks. Dreamweaver was good, but the way Fireworks let you edit images in both bitmap and vector mode and saved it all as extended info in PNG files you were always able to view everywhere… So sad that Adobe killed them off. I would still be using Fireworks today if I could.
  - water8 4y ago
    Fireworks lives on but Adobe has like 90 products and I forget which one it became
  - wwweston 4y ago
    I am still using Fireworks, it's the main reason I'm hanging back on Mac OS Mojave on my personal machine (Catalina drops support along w/ all the 32 bit apps). And I'm waffling between getting a hold of the Windows version and using that indefinitely or just learning something else that has raster / vector combined.
tantaman 4y ago
Hits the nail on the head. Client side frameworks are still missing it, however, when it comes to: 1. Supporting persistent client side state 2. Syncing local state to the server and back 3. Variation of (2) but collaborative state Aside -- Reactivity could be straightforward in vanilla js with some tweaks to event handling and in-browser support for dom diffing. I made this reactive vanilla js todomvc in ~200 sloc to explore the idea: https://tantaman.com/2021-02-12-Todo-MVC.html https://tantaman.com/2021-02-12-Todo-MVC.html
- gremlinsinc 4y ago
  okay, sure you did it.. congrats... but I could do in much less work/lines of code the same: see: https://jsfiddle.net/patrickcurl/zoastuLr/11/ https://jsfiddle.net/patrickcurl/zoastuLr/11/ html: 104 lines css: 39 lines js: 62 lines. The major difference is I can easily 'read' and understand and 'grok' what my code is doing, yours needs more brain power to tie everything together. The majority is layout, css, etc. Sure vue/react are overkill but alpinejs, etc makes closer to vanilla options viable that still at least have some eye-candy/syntactical-sugar that makes coding sweeter. But, I hate ugly code - I'll abstract away ugly code just to have code that's self-documenting and easy to understand.
ak39 4y ago
Well explained, thank you. When did "data binding" become "reactivity" (why the need to create a whole new lexicon for the same ol' thing)? A lot of this confusion (as per the OP) could have simply been explained away by saying we needed frameworks to bind HTML (visual components) to data. Two-way binding existed in many desktop frameworks before SPAs were even thought of.
- deleted 4y ago
  [deleted]
- fiddlerwoaroof 4y ago
  React is intentionally not two-way binding.
  - ak39 4y ago
    And yet, after all these years, Svelte is a response precisely to that design philosophy: taking us back to accepting that two-way binding is nothing to be scared of. The endless loop of thinking in the JS community is expensive.
tgflynn 4y ago
> The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state. That's a very interesting comment, but it is rather abstract. I think it would be very helpful if you (or someone else) could provide a simple example that illustrates the problem.
- mixmastamyk 4y ago
  If you load an HTML page and modify it over and over with Javascript, eventually the code and page will disagree with each other as to what is what. To the point where only a refresh of the page will get it back to the starting point. Remember doing that a lot 10+ years ago? This happens often with pages meant to be an app, rather than a page. When they grow beyond a certain size or complexity, it becomes a given.
- renaudpawlak 4y ago
  In a UI, you usually apply some sort of MVC pattern (Model-View-Controller), which means that you have a Model (your data, which usually comes from a server, or can be created by the user interacting with the UI), and the View, which is implemented with some HTML / DOM elements and reflects what the user sees. Then you have some sort of components (playing the role of Controllers) that are responsible (amongst other things) of syncing the Model and the View both ways (when the users interacts, with the view, it might update the data, but also, when the data changes for some reason, it might update the view). The strength of the frameworks (React, View, Angular), is to provide a way to create well-scoped (local/small) components that take care of the Model (the data), the View (generally what is called a template), and have a built-in reactive capability that facilites the sync of the Model and the View. That reactivity is extremely powerful because it "watches" all changes of the Model and knows when a change is impactful for the View. It then refreshes the view automatically so that the user instantly sees the impact of its action or any state change in the application. When you don't have reactivity, it is of course possible to build a UI, however, you will have to rigorously and explicitly update the view yourself. You can use an observer pattern to do so (btw, under the hood, reactivity is provided by an implicit and automated observer pattern, so that all data of the model become "observable"). In any case, when you don't have reactivity, it gets more complicated and you have to really know what you are doing because your UI code can become a big mess really easily. You asked for an example. Imagine you have a UI with the check box and when the user checks it, it shows an input so that the user can enter some text to precise some data. In general, you can implement that behavior really easily with a reactive framework. Here is the pseudo code (not meant to be compiled). The view: <input type="check" model="checkvalue" /><IF condition="checkvalue"><input type="text" model="textvalue" /></IF> The model: { checkvalue: false, textvalue: undefined} The important here is the IF tag, which depends on the checkvalue of the model. When this value is false, the text input does not show and vice-versa. It is fully automatic thanks to reactivity. If you don't have reactivity, you need to refresh the view manually when checkvalue changes, and you can imagine it can become quite messy when the view and the model get bigger :) All that being said, reactivity, if employed poorly, can also become a mess and tigger a lot of unnecessary updates of the views. That's probably why some people complain about framework performances. Of course the role of the framework is also to give you a "frame of work"... if you go out of the frame, that's usually quite bad... And finally, you can completely develop a small UI with no reactivity applying a MVC pattern with explicit update. That would just make the code more verbose, but IMO, it is doable if you know what you are doing. And it can probably be more efficient in some cases because you don't rely on the framework magic (you can decide in your program when to update the view).
deleted 4y ago
[deleted]
masswerk 4y ago
Personally, I find it easier and faster and more flexible doing it vanilla style. However, you still have to come up with your own abstractions (those you actually need), meaning, you have to own the stack. This may be a good thing, but is it is also challenging regarding human resources. As I see it, frameworks are really about making code accessible, while owning as little as possible of it, by this favouring sharing and the interchangeability of work force. Also, they establish a code policy and the kind of general approach, which is again favourable with regard to human resources. (Now you can have multiple phases of development, where neither team knows anything of the other, which would be hardly possible, if you had to own and maintain the stack. In the old paradigm of art versus engineering, it's a massive shift towards the latter. Which certainly is in line with the general trend.)
- jcpst 4y ago
  I think it’s a great exercise to come up with declarative abstractions over the DOM API. I had quite a bit of fun doing this. It only took a few hundred lines of JS to make a core for a useful web app.
  - masswerk 4y ago
    Moreover, `Object.handleEvent()` allows you to handle any events centralised inside an object and in its specific context since the days of Netscape 4.0. (Which is something many frameworks try to fix, ignoring that it's already in the core language. Admittedly, IE didn't support this before IE6, but by now this is really cargo cult. If there is `addEventListener`, there's also `handleEvent` and no need for extra bindings.)
yuan43 4y ago
Redux is a simple, framework-free pattern for achieving this synchronization. You can use a library that implements, but the pattern is simple enough that you can (and probably should) implement it yourself. https://egghead.io/courses/fundamentals-of-redux-course-from-dan-abramov-bd5cc867 https://egghead.io/courses/fundamentals-of-redux-course-from...
blueprint 4y ago
> it's very hard to keep the UI in sync with state says who??? UIKit used properly is beyond complete. React just introduces more problems. it's funny because it was invented because people just dont understand how to write code. UI is literally the same as model code. it's all views.
jasonm23 4y ago
This perfectly explains why, incredibly smart engineers at ThoughtWorks and the like are using React components to build stateless documentation sites Perfectly reasonable isn't it?
XCSme 4y ago
> that it's very hard to keep the UI in sync with state I don't think that's the hard part, component reusability and templating is what makes me use a UI framework (also the extra goodies that come with it like accessability, sensible design frameworks, etc.).

dbxkcichhdfufu 4y ago

Browsers already managed state just fine. We just didn't like the way it looked.

have_faith 4y ago
Browsers do nothing to help us manage state outside of individual elements.
- hellcow 4y ago
  That’s actually all I use for state management. Elements pass data to children through attributes and bubble data up through events. It’s worked well for us on a complex front-end using native web components.
  - bornfreddy 4y ago
    That's basically a home-made React (& co.) duplicate (which is great). This simplifies development considerably, because you break the original problem into a) updating the state and b) translating the state into UI elements, and the framework (hopefully) automatically updates UI as needed.
  - have_faith 4y ago
    This is called prop drilling. It technically works for any size or complexity of app if you're willing to make every intermediate component have knowledge about every possible piece of state that might be wanted by a component lower in the tree. It's extremely cumbersome though.
    - P5fRxh5kUvp2th 4y ago
      Back in my day we could search for child elements with specific attributes without needing the intermediate elements to know anything about it. What REALLY happened is the shadow DOM. People decided it was too slow and created an intermediate representation. That then created all kinds of OTHER problems that started resulting in solutions that wouldn't have been necessary without the shadow DOM. A shadow DOM is basically a cache, with all the problems that entails.
      - dalmo3 4y ago
        > Note that the shadow DOM is not a new thing by any means — browsers have used it for a long time to encapsulate the inner structure of an element. https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
        P5fRxh5kUvp2th 4y ago
        And for even longer than that, it was a term describing the technique of keeping a tree-like structure that would gather updates so you could eventually update the actual DOM all in one go because updating the DOM piecemeal was slow. The term was popularized long before "web components" was a thing, and in fact, that's where they got the name.
      - creatable 4y ago
        Do you mean virtual DOM?
    - deleted 4y ago
      [deleted]
ozim 4y ago
Which state are you referring to? I feel parent poster is talking about different state than what you have in mind.
- dbxkcichhdfufu 4y ago
  The state that matters to users. All the rest is lies we tell ourselves. There's a reason developers are constantly inventing ways to remove state from their code. Managing state is messy. Frameworks simply move it around. Most react apps would be better off written in PHP, html, and progressively enhanced JS. This is coming from a react developer. Most of what I do is bullshit work someone else invented for me. But it pays well so ohwell.

jraph 4y ago

> The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state. I think that's it. I wonder how far we could go with vanilla js + a dead simple central store implementation that would help update the UI at different places when a value changes. You might end up re-inventing Svelte by attempting this though.

CraigJPerry 4y ago
Someone posted this here a while back: https://github.com/1Marc/todomvc-vanillajs-2022/tree/main/js https://github.com/1Marc/todomvc-vanillajs-2022/tree/main/js - i bookmarked it because i thought it was well done
- jraph 4y ago
  Very interesting indeed. That's some food for thought. Though I should note that if this code has a "store.js" file, this is not the kind of store that I had in mind. More like the Svelte store [1], or Redux (which I find awfully complex). I didn't know the "storage" event on Window [2] (which, for the record, triggers when localStorage is modified from another page. Does not trigger when modified from the same page, which makes localStorage not sufficient as-is to build the kind of store I'm referring to). [1] https://svelte.dev/tutorial/writable-stores https://svelte.dev/tutorial/writable-stores [2] https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event https://developer.mozilla.org/en-US/docs/Web/API/Window/stor...
  - CraigJPerry 4y ago
    >> Does not trigger when modified from the same page I'm thinking that's the purpose of https://github.com/1Marc/todomvc-vanillajs-2022/blob/main/js/store.js#L25 https://github.com/1Marc/todomvc-vanillajs-2022/blob/main/js... - without dispatching that custom save event, there wouldn't be a way to react at any other locations on the same page to the store updating.
numtel 4y ago
In a recent project, I wrote my own template class that works kind of like Lithtml but without any kind of magic reactivity. It just rerenders when properties are updated through the "set()" method. https://github.com/numtel/democratic-capital/blob/master/src/utils/Template.js https://github.com/numtel/democratic-capital/blob/master/src... An example template: https://github.com/numtel/democratic-capital/blob/master/src/components/Overview.js https://github.com/numtel/democratic-capital/blob/master/src...

samwillis 4y ago

> keep the UI in sync with state This is absolutely true, however there are some newer tools that are appearing that make this much easer with vanilla html - htmx, hyperscript, alpine.js for example (links below). These newer tools are all made possible due to the “new”(ish) MutationObserver api, it allows you to intercept new dom elements being placed into the document. These libraries let you simple decorate your “real” html with extra attributes enabling easer client side state management. No build step required. My hope is that a combination of these type of tools, js modules and web components will result in dropping all js build tools. With http2/3 we don’t really need bundling. In many ways it the bundling and transpiling process that has contributed the most to the friction with JS development. My other observation would be that as js frameworks have evolved they have become more “enterprise” ready, adding tooling (complex central state management, strict typing) to make working in large teams on very large codebases easer. Much of this isn’t really necessary for the majority of we development. https://htmx.org/ https://htmx.org/ https://hyperscript.org/ https://hyperscript.org/ https://alpinejs.dev/ https://alpinejs.dev/

xmonkee 4y ago
It's crazy that we posted almost the exact same thing at the same time: https://news.ycombinator.com/item?id=32781674 https://news.ycombinator.com/item?id=32781674
- 9935c101ab17a66 4y ago
  Both your comments are very helpful, so I’m glad you did :)
shafyy 4y ago
To that list I'd add Hotwire (especially Stimulus: https://stimulus.hotwired.dev https://stimulus.hotwired.dev). I use with Rails, but it's framework/backend agnostic.
symlinkk 4y ago
But if you’re going to use a framework like HTMX and the others you mentioned, why not just use React? Vanilla JS is great because it’s universally available, if you’re choosing to drop that advantage I would just go with React.

daveslash 4y ago

Re >> From someone who has used React professionally but uses vanilla HTML/CSS/JS for his personal website" What a refreshing perspective. My personal site is also vanilla HTML/CSS/JS on a self hosted server. I constantly catch flak from all of my software engineering friends for it too, and I'm a little burned out on it. Edit: I'm a bit burned out on the flak and defending my position; not burned out on the approach :-)

jraph 4y ago
Please don't burn out for this. Vanilla HTML/CSS/JS is just a very right way of building a website. I don't know how we ended up having to even debate about this. Don't worry, just enjoy the simplicity, the zen and the lightness of this. (from a professional web developer, if it even matters - but the web, especially JS, was not targeted at professional web developers, which is the reason why JS is so "forgiving" - or was intended as such, but that failed miserably if you ask me)
- rodolphoarruda 4y ago
  Yes. Some things should be designed as simple as possible so they can last. https://jeffhuang.com/designed_to_last https://jeffhuang.com/designed_to_last
- daveslash 4y ago
  I've updated my comment to reflect that I'm burned out on catching the flak, but not the work itself. Personally, I love basking in the zen of the simplicity! I used to be a professional web developer in a former life, but these days I'm more medical-device and embedded focused. I moved out of the web space around the time that AngularJS was becoming the hot-new-thing, for better or worse.
DanAtC 4y ago
A good engineer knows which tools are right for the job.
kaeruct 4y ago
Those are some strange friends. Who cares what you use on your own website?

pier25 4y ago

> to make "reactivity" (hence React) You put it in quotes but some might be missing the point you're making which is that React is not reactive. See this quote from the docs: > There is an internal joke in the team that React should have been called “Schedule” because React does not want to be fully “reactive”. https://reactjs.org/docs/design-principles.html#scheduling https://reactjs.org/docs/design-principles.html#scheduling

pier25 4y ago
Another point I'd like to make is that you don't really need reactivity. Frameworks like Mithril or Imba are not reactive, at all, and they work just fine for many use cases. The advantage is that state can be just vanilla JS. No need for any abstraction. For example Mithril re-renders everything to the VDOM after a user event (click, etc) automatically. You can also tell Mithril to redraw [0] eg if you have a WS handler or something state change not related to user input. I think Imba works very similarly but I don't have much experience with it. It's a super simple mental model which I like a lot more than anything else. I'm mainly using Svelte now though for other reasons. [0] https://mithril.js.org/redraw.html https://mithril.js.org/redraw.html

xmonkee 4y ago

>The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state. This isn't wrong, but going one level down, this is how it bites you: - The imperative DOM api just suuuucks. Please try it for yourself to see. Even if you're writing a very limited bit of reactivity in your app, you will be forced to invent your own declarative framework very soon. - Very hard to make reusable components (at least before webcomponents, which I haven't used personally) If you want to stay close to vanilla, I recommend one of the following solutions: 1) https://htmx.org/ https://htmx.org/ 2) https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript 3) https://github.com/vuejs/petite-vue https://github.com/vuejs/petite-vue

soulofmischief 4y ago
If you like hyperscript, it's worth checking out mithril. https://mithril.js.org https://mithril.js.org
- gzer0 4y ago
  What about adamant? I heard that is the next level above mithril.
  - Legion 4y ago
    This sequence of comments is the JS ecosystem in a nutshell. Hear about something new, then immediately hear about its multiple successors/replacements.
    - soulofmischief 4y ago
      Mithril uses hyperscript as its foundation, it builds upon it as opposed to replacing/succeeding it :) Check it out, it's the kind of framework you pick and stick with for 20+ years. Zero bullshit compared to its peers.
      - ovao 4y ago

alfonsodev 4y ago

I'm in web development since 2000s, at that time there was pretty good web authoring tools like Macromedia Dreamweaver. Everything got complicated because a fundamental limitation of the HTML document model: having dynamic pages. Imagine creating and maintaining a catalog by having a single .html file for each item in the catalog. I believe with Dreamweaver MX you could have sort of a template and generate the static pages. I think this solution wasn't massively adopted because you had to rely on Macromedia server side ( Cold Fusion ). That was when PHP and ASP entered the scene allowing you to have dynamic pages in a linux or windows server. At that time, javascript implementations and rendering engines had massive discrepancies, Internet Explorer, Mozilla .., and to solve that emerge the first (that I recall) massively adopted javascript libraries, jQuery & Motools. Then Ajax[1] became popular because it made posible to interact with the server without refreshing the page, and that's when managing state became a problem in the browser as SPA started to become more and more complex. It's amusing seeing how we went full circle when SPAs have gotten so heavy and slow that now static page generation it's sold as a killer feature in Nextjs. When we could do this in 99's version of Dreamweaver with a nice UI. Maybe it's not a fair comparison, but you get my point, >20 years and see where we are.

rcarmo 4y ago
$DIVINITY, how I miss Dreamweaver and Fireworks. Dreamweaver was good, but the way Fireworks let you edit images in both bitmap and vector mode and saved it all as extended info in PNG files you were always able to view everywhere… So sad that Adobe killed them off. I would still be using Fireworks today if I could.
- water8 4y ago
  Fireworks lives on but Adobe has like 90 products and I forget which one it became
- wwweston 4y ago
  I am still using Fireworks, it's the main reason I'm hanging back on Mac OS Mojave on my personal machine (Catalina drops support along w/ all the 32 bit apps). And I'm waffling between getting a hold of the Windows version and using that indefinitely or just learning something else that has raster / vector combined.

tantaman 4y ago

Hits the nail on the head. Client side frameworks are still missing it, however, when it comes to: 1. Supporting persistent client side state 2. Syncing local state to the server and back 3. Variation of (2) but collaborative state Aside -- Reactivity could be straightforward in vanilla js with some tweaks to event handling and in-browser support for dom diffing. I made this reactive vanilla js todomvc in ~200 sloc to explore the idea: https://tantaman.com/2021-02-12-Todo-MVC.html https://tantaman.com/2021-02-12-Todo-MVC.html

gremlinsinc 4y ago
okay, sure you did it.. congrats... but I could do in much less work/lines of code the same: see: https://jsfiddle.net/patrickcurl/zoastuLr/11/ https://jsfiddle.net/patrickcurl/zoastuLr/11/ html: 104 lines css: 39 lines js: 62 lines. The major difference is I can easily 'read' and understand and 'grok' what my code is doing, yours needs more brain power to tie everything together. The majority is layout, css, etc. Sure vue/react are overkill but alpinejs, etc makes closer to vanilla options viable that still at least have some eye-candy/syntactical-sugar that makes coding sweeter. But, I hate ugly code - I'll abstract away ugly code just to have code that's self-documenting and easy to understand.

ak39 4y ago

Well explained, thank you. When did "data binding" become "reactivity" (why the need to create a whole new lexicon for the same ol' thing)? A lot of this confusion (as per the OP) could have simply been explained away by saying we needed frameworks to bind HTML (visual components) to data. Two-way binding existed in many desktop frameworks before SPAs were even thought of.

deleted 4y ago
[deleted]
fiddlerwoaroof 4y ago
React is intentionally not two-way binding.
- ak39 4y ago
  And yet, after all these years, Svelte is a response precisely to that design philosophy: taking us back to accepting that two-way binding is nothing to be scared of. The endless loop of thinking in the JS community is expensive.

tgflynn 4y ago

> The key reason web frameworks dominate these days is that it's very hard to keep the UI in sync with state. That's a very interesting comment, but it is rather abstract. I think it would be very helpful if you (or someone else) could provide a simple example that illustrates the problem.

mixmastamyk 4y ago
If you load an HTML page and modify it over and over with Javascript, eventually the code and page will disagree with each other as to what is what. To the point where only a refresh of the page will get it back to the starting point. Remember doing that a lot 10+ years ago? This happens often with pages meant to be an app, rather than a page. When they grow beyond a certain size or complexity, it becomes a given.
renaudpawlak 4y ago
In a UI, you usually apply some sort of MVC pattern (Model-View-Controller), which means that you have a Model (your data, which usually comes from a server, or can be created by the user interacting with the UI), and the View, which is implemented with some HTML / DOM elements and reflects what the user sees. Then you have some sort of components (playing the role of Controllers) that are responsible (amongst other things) of syncing the Model and the View both ways (when the users interacts, with the view, it might update the data, but also, when the data changes for some reason, it might update the view). The strength of the frameworks (React, View, Angular), is to provide a way to create well-scoped (local/small) components that take care of the Model (the data), the View (generally what is called a template), and have a built-in reactive capability that facilites the sync of the Model and the View. That reactivity is extremely powerful because it "watches" all changes of the Model and knows when a change is impactful for the View. It then refreshes the view automatically so that the user instantly sees the impact of its action or any state change in the application. When you don't have reactivity, it is of course possible to build a UI, however, you will have to rigorously and explicitly update the view yourself. You can use an observer pattern to do so (btw, under the hood, reactivity is provided by an implicit and automated observer pattern, so that all data of the model become "observable"). In any case, when you don't have reactivity, it gets more complicated and you have to really know what you are doing because your UI code can become a big mess really easily. You asked for an example. Imagine you have a UI with the check box and when the user checks it, it shows an input so that the user can enter some text to precise some data. In general, you can implement that behavior really easily with a reactive framework. Here is the pseudo code (not meant to be compiled). The view: <input type="check" model="checkvalue" /><IF condition="checkvalue"><input type="text" model="textvalue" /></IF> The model: { checkvalue: false, textvalue: undefined} The important here is the IF tag, which depends on the checkvalue of the model. When this value is false, the text input does not show and vice-versa. It is fully automatic thanks to reactivity. If you don't have reactivity, you need to refresh the view manually when checkvalue changes, and you can imagine it can become quite messy when the view and the model get bigger :) All that being said, reactivity, if employed poorly, can also become a mess and tigger a lot of unnecessary updates of the views. That's probably why some people complain about framework performances. Of course the role of the framework is also to give you a "frame of work"... if you go out of the frame, that's usually quite bad... And finally, you can completely develop a small UI with no reactivity applying a MVC pattern with explicit update. That would just make the code more verbose, but IMO, it is doable if you know what you are doing. And it can probably be more efficient in some cases because you don't rely on the framework magic (you can decide in your program when to update the view).

deleted 4y ago

[deleted]

masswerk 4y ago

Personally, I find it easier and faster and more flexible doing it vanilla style. However, you still have to come up with your own abstractions (those you actually need), meaning, you have to own the stack. This may be a good thing, but is it is also challenging regarding human resources. As I see it, frameworks are really about making code accessible, while owning as little as possible of it, by this favouring sharing and the interchangeability of work force. Also, they establish a code policy and the kind of general approach, which is again favourable with regard to human resources. (Now you can have multiple phases of development, where neither team knows anything of the other, which would be hardly possible, if you had to own and maintain the stack. In the old paradigm of art versus engineering, it's a massive shift towards the latter. Which certainly is in line with the general trend.)

jcpst 4y ago
I think it’s a great exercise to come up with declarative abstractions over the DOM API. I had quite a bit of fun doing this. It only took a few hundred lines of JS to make a core for a useful web app.
- masswerk 4y ago
  Moreover, `Object.handleEvent()` allows you to handle any events centralised inside an object and in its specific context since the days of Netscape 4.0. (Which is something many frameworks try to fix, ignoring that it's already in the core language. Admittedly, IE didn't support this before IE6, but by now this is really cargo cult. If there is `addEventListener`, there's also `handleEvent` and no need for extra bindings.)

yuan43 4y ago

Redux is a simple, framework-free pattern for achieving this synchronization. You can use a library that implements, but the pattern is simple enough that you can (and probably should) implement it yourself. https://egghead.io/courses/fundamentals-of-redux-course-from-dan-abramov-bd5cc867 https://egghead.io/courses/fundamentals-of-redux-course-from...

blueprint 4y ago

> it's very hard to keep the UI in sync with state says who??? UIKit used properly is beyond complete. React just introduces more problems. it's funny because it was invented because people just dont understand how to write code. UI is literally the same as model code. it's all views.

jasonm23 4y ago

This perfectly explains why, incredibly smart engineers at ThoughtWorks and the like are using React components to build stateless documentation sites Perfectly reasonable isn't it?

XCSme 4y ago

> that it's very hard to keep the UI in sync with state I don't think that's the hard part, component reusability and templating is what makes me use a UI framework (also the extra goodies that come with it like accessability, sensible design frameworks, etc.).