11 ms·

the DOM was often used to store state. Every once in a while I'm reminded that I'm mostly disconnected from the way "most" people build things. Thanks for th

the DOM was often used to store state. Every once in a while I'm reminded that I'm mostly disconnected from the way "most" people build things. Thanks for this insight. It finally explains why I hear people talking down about "jQuery developers", if that was something that people actually did. But wow. I've been building javascript-heavy web stuff since the mid 90's and it had never occurred to me to do that. You have your object model, and each thing had a reference back to its DOM node and some methods to update itself if necessary. All jQuery did was make it less typing to initially grab the DOM node (or create it), and give you some shorthand for setting classes on them. It also explains why people liked React, which has always seemed completely overcomplicated to me, but which probably simplified things a lot if you didn't ever have a proper place to keep your data model. I can't imagine I was the only one who had things figured out back then, though. The idea you're talking about sounds pretty terrible.

cryptica 7y ago
complexity also kept me away from React. The main reason that it got popular is because it's by Facebook and they know how to manipulate people to use certain products over others (that's their entire business). There have always been simpler and cleaner alternatives. If React was not by Facebook, it would not have gotten popular at all except as a 'cool hack/experiment' - Nobody would have seriously tried to incorporate it into a production application. As soon as you scratch the surface, you understand that it's one of those tools that tries to take away complexity by adding complexity on top. The story has gotten more complicated though because now React has so many components and there is all this conveninent tooling and boilerplate around it but still I would never choose it over VueJS. Anything that comes out of Facebook is just pure manipulation.
- sam0x17 7y ago
  Convenience is to be taken with a grain of salt, though. In the node.js world, "is-odd" can be a package, and it can have 926,000 weekly downloads and 22 dependents.
  - nailer 7y ago
    Makes sense, you don't want to write your own tests for handling zero.
    - fauigerzigerk 7y ago
      is-odd doesn't have any tests for handling zero. What would they be anyway? What is-odd does is to throw an exception if you pass anything that isn't a safe integer or a string representation of a safe integer. Otherwise it just returns n % 2 === 1 (after converting string to int if necessary)
      - DonHopkins 7y ago
        You don't want to start a religious war between the people who believe zero is special, and the ones who believe it should throw an error if you pass a string, and the people who believe it should attempt to convert the string to an integer, and the people who believe you should either round or truncate when the parameter is a floating point number, and the people who disagree about which direction to round, and the people who can't agree whether you should truncate towards zero or negative infinity.
        e12e 7y ago
        > should either round or truncate when the parameter is a floating point number Isn't the parameter always floating point in Javascript? (which does mean a package like isOdd will have to incorporate some level of mysticism...)
        marcosdumay 7y ago
        Let the fight begin! It goes well with some popcorn. I can understand how fundamental education teachers don't grasp modern Algebrism and believe that Math is formed by fundamental, sacred definitions. But programmers ought to know better.
        pcmaffey 7y ago
        And my favorite case - that zero is false. (!!0)
- mellab2 7y ago
  Sorry but what complexity are you talking about? React (particularly in the early days) has always had a comparatively small API surface. You have components with a render method, and in that render method you return other components which you can pass data to via "props" - that's basically react in a nutshell. I've noticed React is often conflated with the wider ecosystem it is a part of (Webpack, Redux, Babel) - perhaps this is the complexity you are referring to, but to be clear React can be used without any of these things. And sure React being developed by Facebook couldn't have hurt in terms of it gaining popularity - but the real reason it took off is that in contrast to what you said it removed a huge amount of complexity by alleviating the burden of developers having to manipulate the DOM directly in ad hoc ways. Instead of having to manually add classes, add elements, remove elements, append children, you could just say given this piece of state, give me this. > Anything that comes out of Facebook is just pure manipulation. This just shows that your issue lies with facebook the company, which is biasing you against react - the technology.
  - cannedslime 7y ago
    Sure you could use react without JSX compilation, State libraries etc. But you'd just end up writing more code to do less. If your app isn't complex enough to merit the use of webpack, redux, babel etc etc. it probably isn't complex enough to even worry about DOM performance.
  - jondubois 7y ago
    >> I've noticed React is often conflated with the wider ecosystem it is a part of (Webpack, Redux, Babel) - perhaps this is the complexity you are referring to, but to be clear React can be used without any of these things. I disagree with this. Everyone claims that you can use React without JSX but no one does it. Aside from ugliness, the main reason why no ones does this is because you would be missing the most useful aspect of React which is compatibility and consistency with the rest of the React ecosystem. So you cannot separate React from its ecosystem. All this complexity has become tightly intertwined. If you use VueJS without a bundler (which is actually feasible), you will be surprised how much simpler and elegant the whole development experience is. Once HTTP servers start supporting static push of scripts, we will not even need bundling in production.
- mercer 7y ago
  Do you really believe all of us React users are patsies and you're conveniently one of the smart guys who hasn't fallen for it? Surely a more reasonable perspective is that React actually solved a real problem, and the fact that there's a big company backing it is actually a benefit because 1) there's a lot of money and experience poured into the project, 2) it's likely to be supported even if the lead dev gets hit by a bus, 3) it's an easier sell to management over <insert alternative by random dev>? I'm no fan of Facebook the company and product, and I avoid client-side code as much as possible (yay Phoenix LiveView), but I think React is quite neat and made my client-side work easier. I'd also argue that it paved the way for an important shift in how front-end frameworks do their thing, and we're all better off for it.
- ralphstodomingo 7y ago
  This is awfully dismissive without sound reasoning, I think. It doesn't take long for anyone working with the old ways outlined above (for example, me five years ago) to see why React was in many ways a step forward, defining what we should expect of any new front-end libraries these days. Also, everything starts out as a cool hack/experiment at some point. > it's one of those tools that tries to take away complexity by adding complexity on top It's one of those tools that purposely abstracts unproductive, inefficient complexity that we were not aware of before into a higher-level one, forcing us to be more mindful of how we do things. A matter of tradeoffs, I would say, and there's gotta be a limit to how 'simple' one thing can be. Also, you're conflating React the library with the ecosystem around it. On a sidenote, all the tooling and boilerplate React came hand-in-hand with was markedly a net positive for me. It was in picking up React, during my career, that I learned why tooling is important, picked up tools like Webpack and grunt, learned myself how to do CI/CD and other stuff.
sam0x17 7y ago
My god, it finally all makes sense! And this is why I've been developing all my modern web applications as essentially an S3 bucket of flat HTML with vanilla javascript and jquery sprinkled in sitting behind cloudfront, connected to a fast API built of cloud functions / lambdas written in crystal/rust/etc. I use a custom routing system (I have S3 set up to respond with a 200 at the index in the event of a 404, so I have unlimited control over pathing from within my js logic) and I never let node touch anything at all. And I'm super happy about it. Never has it been easier to get things done. I don't have to fight with any system because there is no system to get in my way. This gives me: 1. 2-4 second deploys 2. full control over assets pipeline (I call html-minifier, etc., manually in my build script) 3. literally serverless -- S3 or lambda would have to go down for there to be an issue (ignoring db) 4. caching at the edge for everything because of cloudfront 5. zero headaches because I don't have to do battle with node or react or anyone's stupid packages 6. (surprisingly) compatibility with googlebot! It turns out that the googlebot will index js-created content if it is immediate (loaded from a js file that is generated by a lambda and included in the document head tag as an external script, for example) 7. full control over routing, so I don't have to follow some opinionated system's rules and can actually implement the requirements the project manager asks me to implement without making technical excuses. This does not give me: 1. A magical database that has perfect automatic horizontal scaling. Right now there is no magic bullet for that yet. Some come close but eschew the transactional part of ACID, making themselves basically useless for many applications. And the parent post exactly matches my usage of jQuery :D
- avip 7y ago
  Pricing aside (as it's almost unreasonably expansive if your app requires frequent db writes), firestore is indeed "A magical database that has perfect automatic horizontal scaling". But as you have your happy setup on aws it probably makes little sense to switch.
  - sam0x17 7y ago
    Yeah there are a few in that category also Google Cloud Spanner and the stuff by CitusData. All of them work, but are prohibitively expensive to get started. I've harangued them a number of times about how people aren't going to want to use something they can't scale up from $1/month to $10000/month without migrating any data (that's the whole point of an auto-scaling horizontal service imo), but so far no changes from them. Like why would you design potentially infinite auto-scaling, and then lock it up behind a $90/month minimum fee. They could have been making money all along on those $20/month or $40/month or $5/monthers, who vastly outnumber those who _need_ autoscaling, but what the peace of mind that auto-scaling provides.
deleted 7y ago
[deleted]
onion2k 7y ago
Bare in mind that most people using jQuery weren't writing JavaScript applications. They were writing backend-driven applications with jQuery enhancements, so there was no real concept of frontend 'state' that was separate to the DOM itself. If your frontend code needed to work with 'state' like form values or element attributes you had to read them, and because there could be multiple separate bits of code working with the same form or element you had to write values back to the DOM so the next bit of code had the correct 'state'. The thing that changed to make frontend development improve dramatically was hash based routing with ajax, and later the introduction of the history API. That caused frontend development to have a need to retain state between 'pages', so then was a need to find a better way to store it than using DOM attributes.
- Udik 7y ago
  > he thing that changed to make frontend development improve dramatically was hash based routing with ajax... I think that what's changed is simply that people realized that it's way less messy to use the backend only as a data source (with ajax calls), and leave everything else to the frontend. The cognitive overhead of having the server producing html with some implicit state, then updating that state interactively, and then losing everything again by posting the whole page to the server, was simply unbearable. When I started building web applications in 2004 I had some experience in writing desktop apps: I simply created a js library to create and destroy UI elements, and wrote "desktop" apps running in the browser.
  - mercer 7y ago
    While I agree in theory, in practice I find that the frontend still has all sorts of warts that don't quite make it a great solution (yet). I mean, it's better than having to maintain both server- and client-side logic and state (and having to sync all that), and definitely better than the days where we also had to manage DOM diffing manually. But I still get headaches from the NPM/node ecosystem, the build steps, having to decide whether logic goes on the client, server, or both, and to some extent javascript itself. And you can never fully let go of the server-side of things. I'm very intrigued by the alternative idea of moving (almost) everything to the backend, and maintaining the dynamic bits by sending all events to the server and sending back diffs based on that which update the page. Phoenix'/Elixir's LiveView made some great progress in this area, and from what I hear other ecosystems are experimenting with the same thing. It's not a panacea: if you need offline functionality you're gonna have to deal with js and everything that comes with it. But in many projects that's not a deal-breaker, and in practice the approach actually leads to smaller payloads sent between client and server, and significantly simpler codebases.
radicalbyte 7y ago
That's just a symptom of Javascript being the entry-level language. You can be sort of productive without ever understanding how anything works. Where these frameworks really come into their own is when you want to create reusable components and share them outside a team. jQuery did a good job with their plugins back in the day but Angular 2 (and React, and soon native Web Components) so that far better.
- concerned_user 7y ago
  I hear the tale of "soon native Web Components" for years and still none in sight yet. As far as I remember there are some attempts from Chrome and Mozilla but not sure I saw a real cross-platform spec out, so I stopped tracking the news around it really. Can you provide some references maybe?
  - floatboth 7y ago
    https://caniuse.com/#feat=custom-elementsv1 https://caniuse.com/#feat=custom-elementsv1 https://caniuse.com/#feat=shadowdomv1 https://caniuse.com/#feat=shadowdomv1 v1 shipped with Chrome 53, Safari 10 and Firefox 63. (And there's a polyfill.) It's not "soon", it's very much "been in production for a while". A base class like LitElement https://lit-element.polymer-project.org https://lit-element.polymer-project.org is all you need to achieve a sort of "react-like" development style (components with unidirectional data flow) WITHOUT build tools() and WITHOUT dom diffing! :) () if you want to use npm dependencies instead of just plain files with a bundled version of lit, you still need to rewrite import paths, until https://github.com/WICG/import-maps https://github.com/WICG/import-maps becomes a thing at least. I wrote a tiny dev server that does that: https://github.com/myfreeweb/es-module-devserver https://github.com/myfreeweb/es-module-devserver
    - rxgx 7y ago
      Anyone else get a little excited about that Edge v75?!
- ousta 7y ago
LoSboccacc 7y ago
I mean, I use to store data in my model and have the controller doing the rendering like anyone else that has some kind of experience on how ugly the opposite would become, but to outright demonize state within html seems quite misguided as well there are things that are massively annoying to do without sneaking a data-uuid and data-type here and there, like drag&drop or specific customer requests - if anyone has ever written a cms, imagine the customer coming and telling "I want this product image in black and white" - if you had data attributes around, it's a css two liners, if you didn't because you're trapped into a either-or mindset, you have to also add the image-bw class on the rendering code with "customer ==" and "product ==" checks
WA 7y ago
If you’ve ever written a video game, I think it’s quite obvious as well. Video games have a main loop, take input, compute the next state, and then merely render the state to the screen. There is no point in manipulating the "UI". The data flow is very clear. Of course, your game can run entirely "in memory" without a render function, which is basically what the game server does. So I guess, many people have figured it out but didn’t transfer the knowledge from one area to the other. Thanks for the insight, because I also always wondered what’s considered so new about React, although I have to admit that I still wrote my fair share of jQuery Spaghetti code.
- Udik 7y ago
  > Video games have a main loop, take input, compute the next state, and then merely render the state to the screen. There is no point in manipulating the "UI". The data flow is very clear. I always thought this is basically the MVC pattern. And it's obviously the only sane way to do things. Edit: I don't mind the donwvotes, but am I wrong? The MVC pattern simply seems to mandate, at its core, the separation between the model, its graphical representation, and the input from the user. Input -> model -> view. So a game loop where the user input is gathered, the model is updated by calculating the next state, and the view is displayed seems to me an instance of MVC.
  - coldtea 7y ago
    Actually that's one way to do things, the two ways being retained mode and immediate mode. And each has their own use cases and challenges. Traditionally, however, most well known GUIs (most of the apps people use on the desktop) were done with retained mode libraries (GTK, Qt, Cocoa, and so on). >So a game loop where the user input is gathered, the model is updated by calculating the next state, and the view is displayed seems to me an instance of MVC. There's nothing preventing the view being a retained mode UI widget tree -- which is how MVC was commonly implemented iirc.
  - vijaybritto 7y ago
    Though your opinion is mostly right, I think people are downvoting for the sentence "obviously the only same way to do things"
Udik 7y ago
> Thanks for this insight. It finally explains why I hear people talking down about "jQuery developers", if that was something that people actually did. Yes. It seems that most of the frameworks people are so enthusiastic about are invented just to prevent bad developers from writing their awful code. Which they end up doing anyway. Anecdote: years ago, when he decided moving to Angular.js, my boss justified it with "following best practices". Then he proceeded to rewrite all the application components as controllers quering the context to decide how to behave, and talking to everything else through global events. Took me weeks to rewrite everything in a sane way. (Years later it was decided everything was too slow, and it was rewritten in good vanilla js, with a huge performance boost).
citeguised 7y ago
When I got into front-end coming from Design, jQuery just got huge. Due to lack of senior front-end-devs in the company, my JS was this exact pile of jQuery with state in data-attributes. The things weren't really complex (Modals, Tabs, Form-Validation etc.), so it was never a problem. Nowadays I'd still do simpler components this way. For anything heavier I'll grab React from the beginning, because of it's enforcement of modularity and state-management. I'm interested in the way of architecting things you described, since I used to try similar ways, but always ended up state-in-dom. Would you have examples or literature on this?
- mercer 7y ago
  I started out much the same way, and took that approach for quite a while. These days I avoid putting state in my markup even for small stuff. I remember some good articles on the topic, but sadly can't find them. But at its most basic, I just make sure that any jQuery/dynamic component/widget, from the start, is essentially a render function that takes a bunch of data and updates the markup with this data (triggered via some event handler or setInterval(), or something like that). In many cases this doesn't have to be complex or efficient. Sometimes just an .innerHTML() or whatnot is fine. The crucial bit is that I always start with a js data structure and treat it as the single source of truth. In most cases I just use Preact from the beginning, but I've worked on projects where that wasn't possible and I had to use jQuery or plain javascript. Whatever I used, I usually ended up regretting state in my markup.
- im3w1l 7y ago
  If you know you will need the data again store it in some variable, in addition to the dom? For instance if you have a chat, you could have a list of message objects as a normal variable and also show those messages in the dom.
ivanhoe 7y ago
To me the core problem wasn't with the data model, it's just that a declarative approach to binding events and reactive updates that knockout, vue, react, etc. provide reduces significantly the amount of repetitive, boilerplate code that you need to write. All that searching for nodes, adding handlers and callbacks, then updating the DOM when data model changes is now handled by frameworks. As you've said, this is not really jQuery vs React issue at all, jQuery just provides some nice cross-browser shortcuts. The main problem IMHO in jQuery era was in keeping the binding/callback logic separated from the html templates that define the dom structure itself. In big apps it made it difficult to follow which code binds to what part of UI, and there was no way to prevent someone from binding to the same node you're working on from some completely different part of the app. Now with declarative approach it's all in the same place and it's immediately clear what handlers you have in place on any html element, making refactoring much less stressful.
tomaskafka 7y ago
Few years ago I just did a 'react + redux in jquery' on a smaller project. A state of app was in a single object (= super easy debug, undo or save), any user action generates a state delta (which properties of state needs changing), and a central dispatcher updates the UI according to state changes. Quick and painless.

cryptica 7y ago

complexity also kept me away from React. The main reason that it got popular is because it's by Facebook and they know how to manipulate people to use certain products over others (that's their entire business). There have always been simpler and cleaner alternatives. If React was not by Facebook, it would not have gotten popular at all except as a 'cool hack/experiment' - Nobody would have seriously tried to incorporate it into a production application. As soon as you scratch the surface, you understand that it's one of those tools that tries to take away complexity by adding complexity on top. The story has gotten more complicated though because now React has so many components and there is all this conveninent tooling and boilerplate around it but still I would never choose it over VueJS. Anything that comes out of Facebook is just pure manipulation.

sam0x17 7y ago
Convenience is to be taken with a grain of salt, though. In the node.js world, "is-odd" can be a package, and it can have 926,000 weekly downloads and 22 dependents.
- nailer 7y ago
  Makes sense, you don't want to write your own tests for handling zero.
  - fauigerzigerk 7y ago
    is-odd doesn't have any tests for handling zero. What would they be anyway? What is-odd does is to throw an exception if you pass anything that isn't a safe integer or a string representation of a safe integer. Otherwise it just returns n % 2 === 1 (after converting string to int if necessary)
    - DonHopkins 7y ago
      You don't want to start a religious war between the people who believe zero is special, and the ones who believe it should throw an error if you pass a string, and the people who believe it should attempt to convert the string to an integer, and the people who believe you should either round or truncate when the parameter is a floating point number, and the people who disagree about which direction to round, and the people who can't agree whether you should truncate towards zero or negative infinity.
      - e12e 7y ago
        > should either round or truncate when the parameter is a floating point number Isn't the parameter always floating point in Javascript? (which does mean a package like isOdd will have to incorporate some level of mysticism...)
      - marcosdumay 7y ago
        Let the fight begin! It goes well with some popcorn. I can understand how fundamental education teachers don't grasp modern Algebrism and believe that Math is formed by fundamental, sacred definitions. But programmers ought to know better.
      - pcmaffey 7y ago
        And my favorite case - that zero is false. (!!0)
mellab2 7y ago
Sorry but what complexity are you talking about? React (particularly in the early days) has always had a comparatively small API surface. You have components with a render method, and in that render method you return other components which you can pass data to via "props" - that's basically react in a nutshell. I've noticed React is often conflated with the wider ecosystem it is a part of (Webpack, Redux, Babel) - perhaps this is the complexity you are referring to, but to be clear React can be used without any of these things. And sure React being developed by Facebook couldn't have hurt in terms of it gaining popularity - but the real reason it took off is that in contrast to what you said it removed a huge amount of complexity by alleviating the burden of developers having to manipulate the DOM directly in ad hoc ways. Instead of having to manually add classes, add elements, remove elements, append children, you could just say given this piece of state, give me this. > Anything that comes out of Facebook is just pure manipulation. This just shows that your issue lies with facebook the company, which is biasing you against react - the technology.
- cannedslime 7y ago
  Sure you could use react without JSX compilation, State libraries etc. But you'd just end up writing more code to do less. If your app isn't complex enough to merit the use of webpack, redux, babel etc etc. it probably isn't complex enough to even worry about DOM performance.
- jondubois 7y ago
  >> I've noticed React is often conflated with the wider ecosystem it is a part of (Webpack, Redux, Babel) - perhaps this is the complexity you are referring to, but to be clear React can be used without any of these things. I disagree with this. Everyone claims that you can use React without JSX but no one does it. Aside from ugliness, the main reason why no ones does this is because you would be missing the most useful aspect of React which is compatibility and consistency with the rest of the React ecosystem. So you cannot separate React from its ecosystem. All this complexity has become tightly intertwined. If you use VueJS without a bundler (which is actually feasible), you will be surprised how much simpler and elegant the whole development experience is. Once HTTP servers start supporting static push of scripts, we will not even need bundling in production.
mercer 7y ago
Do you really believe all of us React users are patsies and you're conveniently one of the smart guys who hasn't fallen for it? Surely a more reasonable perspective is that React actually solved a real problem, and the fact that there's a big company backing it is actually a benefit because 1) there's a lot of money and experience poured into the project, 2) it's likely to be supported even if the lead dev gets hit by a bus, 3) it's an easier sell to management over <insert alternative by random dev>? I'm no fan of Facebook the company and product, and I avoid client-side code as much as possible (yay Phoenix LiveView), but I think React is quite neat and made my client-side work easier. I'd also argue that it paved the way for an important shift in how front-end frameworks do their thing, and we're all better off for it.
ralphstodomingo 7y ago
This is awfully dismissive without sound reasoning, I think. It doesn't take long for anyone working with the old ways outlined above (for example, me five years ago) to see why React was in many ways a step forward, defining what we should expect of any new front-end libraries these days. Also, everything starts out as a cool hack/experiment at some point. > it's one of those tools that tries to take away complexity by adding complexity on top It's one of those tools that purposely abstracts unproductive, inefficient complexity that we were not aware of before into a higher-level one, forcing us to be more mindful of how we do things. A matter of tradeoffs, I would say, and there's gotta be a limit to how 'simple' one thing can be. Also, you're conflating React the library with the ecosystem around it. On a sidenote, all the tooling and boilerplate React came hand-in-hand with was markedly a net positive for me. It was in picking up React, during my career, that I learned why tooling is important, picked up tools like Webpack and grunt, learned myself how to do CI/CD and other stuff.

sam0x17 7y ago

My god, it finally all makes sense! And this is why I've been developing all my modern web applications as essentially an S3 bucket of flat HTML with vanilla javascript and jquery sprinkled in sitting behind cloudfront, connected to a fast API built of cloud functions / lambdas written in crystal/rust/etc. I use a custom routing system (I have S3 set up to respond with a 200 at the index in the event of a 404, so I have unlimited control over pathing from within my js logic) and I never let node touch anything at all. And I'm super happy about it. Never has it been easier to get things done. I don't have to fight with any system because there is no system to get in my way. This gives me: 1. 2-4 second deploys 2. full control over assets pipeline (I call html-minifier, etc., manually in my build script) 3. literally serverless -- S3 or lambda would have to go down for there to be an issue (ignoring db) 4. caching at the edge for everything because of cloudfront 5. zero headaches because I don't have to do battle with node or react or anyone's stupid packages 6. (surprisingly) compatibility with googlebot! It turns out that the googlebot will index js-created content if it is immediate (loaded from a js file that is generated by a lambda and included in the document head tag as an external script, for example) 7. full control over routing, so I don't have to follow some opinionated system's rules and can actually implement the requirements the project manager asks me to implement without making technical excuses. This does not give me: 1. A magical database that has perfect automatic horizontal scaling. Right now there is no magic bullet for that yet. Some come close but eschew the transactional part of ACID, making themselves basically useless for many applications. And the parent post exactly matches my usage of jQuery :D

avip 7y ago
Pricing aside (as it's almost unreasonably expansive if your app requires frequent db writes), firestore is indeed "A magical database that has perfect automatic horizontal scaling". But as you have your happy setup on aws it probably makes little sense to switch.
- sam0x17 7y ago
  Yeah there are a few in that category also Google Cloud Spanner and the stuff by CitusData. All of them work, but are prohibitively expensive to get started. I've harangued them a number of times about how people aren't going to want to use something they can't scale up from $1/month to $10000/month without migrating any data (that's the whole point of an auto-scaling horizontal service imo), but so far no changes from them. Like why would you design potentially infinite auto-scaling, and then lock it up behind a $90/month minimum fee. They could have been making money all along on those $20/month or $40/month or $5/monthers, who vastly outnumber those who _need_ autoscaling, but what the peace of mind that auto-scaling provides.

deleted 7y ago

[deleted]

onion2k 7y ago

Bare in mind that most people using jQuery weren't writing JavaScript applications. They were writing backend-driven applications with jQuery enhancements, so there was no real concept of frontend 'state' that was separate to the DOM itself. If your frontend code needed to work with 'state' like form values or element attributes you had to read them, and because there could be multiple separate bits of code working with the same form or element you had to write values back to the DOM so the next bit of code had the correct 'state'. The thing that changed to make frontend development improve dramatically was hash based routing with ajax, and later the introduction of the history API. That caused frontend development to have a need to retain state between 'pages', so then was a need to find a better way to store it than using DOM attributes.

Udik 7y ago
> he thing that changed to make frontend development improve dramatically was hash based routing with ajax... I think that what's changed is simply that people realized that it's way less messy to use the backend only as a data source (with ajax calls), and leave everything else to the frontend. The cognitive overhead of having the server producing html with some implicit state, then updating that state interactively, and then losing everything again by posting the whole page to the server, was simply unbearable. When I started building web applications in 2004 I had some experience in writing desktop apps: I simply created a js library to create and destroy UI elements, and wrote "desktop" apps running in the browser.
- mercer 7y ago
  While I agree in theory, in practice I find that the frontend still has all sorts of warts that don't quite make it a great solution (yet). I mean, it's better than having to maintain both server- and client-side logic and state (and having to sync all that), and definitely better than the days where we also had to manage DOM diffing manually. But I still get headaches from the NPM/node ecosystem, the build steps, having to decide whether logic goes on the client, server, or both, and to some extent javascript itself. And you can never fully let go of the server-side of things. I'm very intrigued by the alternative idea of moving (almost) everything to the backend, and maintaining the dynamic bits by sending all events to the server and sending back diffs based on that which update the page. Phoenix'/Elixir's LiveView made some great progress in this area, and from what I hear other ecosystems are experimenting with the same thing. It's not a panacea: if you need offline functionality you're gonna have to deal with js and everything that comes with it. But in many projects that's not a deal-breaker, and in practice the approach actually leads to smaller payloads sent between client and server, and significantly simpler codebases.

radicalbyte 7y ago

That's just a symptom of Javascript being the entry-level language. You can be sort of productive without ever understanding how anything works. Where these frameworks really come into their own is when you want to create reusable components and share them outside a team. jQuery did a good job with their plugins back in the day but Angular 2 (and React, and soon native Web Components) so that far better.

concerned_user 7y ago
I hear the tale of "soon native Web Components" for years and still none in sight yet. As far as I remember there are some attempts from Chrome and Mozilla but not sure I saw a real cross-platform spec out, so I stopped tracking the news around it really. Can you provide some references maybe?
- floatboth 7y ago
  https://caniuse.com/#feat=custom-elementsv1 https://caniuse.com/#feat=custom-elementsv1 https://caniuse.com/#feat=shadowdomv1 https://caniuse.com/#feat=shadowdomv1 v1 shipped with Chrome 53, Safari 10 and Firefox 63. (And there's a polyfill.) It's not "soon", it's very much "been in production for a while". A base class like LitElement https://lit-element.polymer-project.org https://lit-element.polymer-project.org is all you need to achieve a sort of "react-like" development style (components with unidirectional data flow) WITHOUT build tools() and WITHOUT dom diffing! :) () if you want to use npm dependencies instead of just plain files with a bundled version of lit, you still need to rewrite import paths, until https://github.com/WICG/import-maps https://github.com/WICG/import-maps becomes a thing at least. I wrote a tiny dev server that does that: https://github.com/myfreeweb/es-module-devserver https://github.com/myfreeweb/es-module-devserver
  - rxgx 7y ago
    Anyone else get a little excited about that Edge v75?!
ousta 7y ago

LoSboccacc 7y ago

I mean, I use to store data in my model and have the controller doing the rendering like anyone else that has some kind of experience on how ugly the opposite would become, but to outright demonize state within html seems quite misguided as well there are things that are massively annoying to do without sneaking a data-uuid and data-type here and there, like drag&drop or specific customer requests - if anyone has ever written a cms, imagine the customer coming and telling "I want this product image in black and white" - if you had data attributes around, it's a css two liners, if you didn't because you're trapped into a either-or mindset, you have to also add the image-bw class on the rendering code with "customer ==" and "product ==" checks

WA 7y ago

If you’ve ever written a video game, I think it’s quite obvious as well. Video games have a main loop, take input, compute the next state, and then merely render the state to the screen. There is no point in manipulating the "UI". The data flow is very clear. Of course, your game can run entirely "in memory" without a render function, which is basically what the game server does. So I guess, many people have figured it out but didn’t transfer the knowledge from one area to the other. Thanks for the insight, because I also always wondered what’s considered so new about React, although I have to admit that I still wrote my fair share of jQuery Spaghetti code.

Udik 7y ago
> Video games have a main loop, take input, compute the next state, and then merely render the state to the screen. There is no point in manipulating the "UI". The data flow is very clear. I always thought this is basically the MVC pattern. And it's obviously the only sane way to do things. Edit: I don't mind the donwvotes, but am I wrong? The MVC pattern simply seems to mandate, at its core, the separation between the model, its graphical representation, and the input from the user. Input -> model -> view. So a game loop where the user input is gathered, the model is updated by calculating the next state, and the view is displayed seems to me an instance of MVC.
- coldtea 7y ago
  Actually that's one way to do things, the two ways being retained mode and immediate mode. And each has their own use cases and challenges. Traditionally, however, most well known GUIs (most of the apps people use on the desktop) were done with retained mode libraries (GTK, Qt, Cocoa, and so on). >So a game loop where the user input is gathered, the model is updated by calculating the next state, and the view is displayed seems to me an instance of MVC. There's nothing preventing the view being a retained mode UI widget tree -- which is how MVC was commonly implemented iirc.
- vijaybritto 7y ago
  Though your opinion is mostly right, I think people are downvoting for the sentence "obviously the only same way to do things"

Udik 7y ago

> Thanks for this insight. It finally explains why I hear people talking down about "jQuery developers", if that was something that people actually did. Yes. It seems that most of the frameworks people are so enthusiastic about are invented just to prevent bad developers from writing their awful code. Which they end up doing anyway. Anecdote: years ago, when he decided moving to Angular.js, my boss justified it with "following best practices". Then he proceeded to rewrite all the application components as controllers quering the context to decide how to behave, and talking to everything else through global events. Took me weeks to rewrite everything in a sane way. (Years later it was decided everything was too slow, and it was rewritten in good vanilla js, with a huge performance boost).

citeguised 7y ago

When I got into front-end coming from Design, jQuery just got huge. Due to lack of senior front-end-devs in the company, my JS was this exact pile of jQuery with state in data-attributes. The things weren't really complex (Modals, Tabs, Form-Validation etc.), so it was never a problem. Nowadays I'd still do simpler components this way. For anything heavier I'll grab React from the beginning, because of it's enforcement of modularity and state-management. I'm interested in the way of architecting things you described, since I used to try similar ways, but always ended up state-in-dom. Would you have examples or literature on this?

mercer 7y ago
I started out much the same way, and took that approach for quite a while. These days I avoid putting state in my markup even for small stuff. I remember some good articles on the topic, but sadly can't find them. But at its most basic, I just make sure that any jQuery/dynamic component/widget, from the start, is essentially a render function that takes a bunch of data and updates the markup with this data (triggered via some event handler or setInterval(), or something like that). In many cases this doesn't have to be complex or efficient. Sometimes just an .innerHTML() or whatnot is fine. The crucial bit is that I always start with a js data structure and treat it as the single source of truth. In most cases I just use Preact from the beginning, but I've worked on projects where that wasn't possible and I had to use jQuery or plain javascript. Whatever I used, I usually ended up regretting state in my markup.
im3w1l 7y ago
If you know you will need the data again store it in some variable, in addition to the dom? For instance if you have a chat, you could have a list of message objects as a normal variable and also show those messages in the dom.

ivanhoe 7y ago

To me the core problem wasn't with the data model, it's just that a declarative approach to binding events and reactive updates that knockout, vue, react, etc. provide reduces significantly the amount of repetitive, boilerplate code that you need to write. All that searching for nodes, adding handlers and callbacks, then updating the DOM when data model changes is now handled by frameworks. As you've said, this is not really jQuery vs React issue at all, jQuery just provides some nice cross-browser shortcuts. The main problem IMHO in jQuery era was in keeping the binding/callback logic separated from the html templates that define the dom structure itself. In big apps it made it difficult to follow which code binds to what part of UI, and there was no way to prevent someone from binding to the same node you're working on from some completely different part of the app. Now with declarative approach it's all in the same place and it's immediately clear what handlers you have in place on any html element, making refactoring much less stressful.

tomaskafka 7y ago

Few years ago I just did a 'react + redux in jquery' on a smaller project. A state of app was in a single object (= super easy debug, undo or save), any user action generates a state delta (which properties of state needs changing), and a central dispatcher updates the UI according to state changes. Quick and painless.