6 ms·

I'm still learning modern web development but here's a simple demo app that I wrote using only plan vanilla HTML/CSS/JS: https://tgflynn.github.io/AlgoVis/ http

I'm still learning modern web development but here's a simple demo app that I wrote using only plan vanilla HTML/CSS/JS: https://tgflynn.github.io/AlgoVis/ https://tgflynn.github.io/AlgoVis/ (github link: https://github.com/tgflynn/AlgoVis https://github.com/tgflynn/AlgoVis). The fact that this works, didn't take long to write (though I'm very much still learning this stuff) and is very fast leads me to question your statement that "The imperative DOM api just sucks".

guilherme-puida 4y ago
> simple demo app I don't think you can judge if the DOM api sucks if you are using a "simple demo app" as your baseline, though.
- tgflynn 4y ago
  All software is built from simple primitives. If the fundamentals are solid scaling up should be just a matter of managing complexity in your own code. I'm aware that performance problems that I don't have direct control over could occur at some point, but would that be the fault of the DOM API itself ?
  - arbitrage 4y ago
    so, yes, you are not wrong. the issue here is the differential of 'managing complexity' with regards to time. as the functionality of the app progresses beyond a certain complexity (admittedly, this is nebulously defined), increasing changes to complexity require more time to effect. beyond a certain point of functionality, the need for a a framework to manage these things becomes emergent. at that point, a single coder can resume making more complex changes with the aide of the framework, than she could do without it. you're not wrong, you just are not considering a big enough scope over which to evaluate what the manual manipulation of software primitives is worth. in the end, frameworks aide results beyond the ability of a single coder to implement on their own.
  - guilherme-puida 4y ago
    If the DOM api is not expressive enough, you end up having to wrap it with your own custom abstractions. At that point, is it not better to use a battle-proven abstraction?
    - tgflynn 4y ago
      Only if they're clearly better than the abstractions I would come up with. Which is rarely the case, especially if most of these frameworks were developed in an ad hoc manner without deep consideration of what the fundamental problems are that need solving, and even more so if they had to incorporate workarounds for browser issues that are no longer very relevant in 2022.
      - wonnage 4y ago
        sounds like someone has a bad case of not-invented-here
        spoils19 4y ago
        Sounds like someone had a bad case of framework chasing and hype driven development. I support the original poster as developing your own is always better than reusing, no exceptions.
        phist_mcgee 4y ago
        I've worked on codebases like your's before, where in-house 'we can do it better' reigned. In my experience it never was better, and when the grand wizard holding it all together got hit by a bus, everyone was blocked. Frameworks are a common understanding that people can plug and play into. And yes, that's a critical part of maintainable code, the ability for a person to quickly get up to speed and fix things.
        wonnage 4y ago
        This from someone who can’t comprehend why government mandated hard hat safety standards might be good. It all fits.
joshstrange 4y ago
Ok, but surely you see the difference between this very simple/straightforward "demo app" and a real webapp? Something like Zillow, Facebook, Doordash, Spotify, etc. I looked at your code and you had to write your own render loop to accomplish this which would break down if you had interactive stuff that you were rendering out (I know, I've done this before). As it stands your interactions ("New Data", "Run", "Step", "Reset") are completely separate from the rendered data. Once you start combining those it gets harder. It's still possible but you are reinventing the wheel. For a small demo like this vanilla JS might make sense but scaling this up does not work (once your rendered HTML reaches a certain size it's jarring when it re-renders, same deal if you have interactive UI that you are rendering out) and if you need to make 10x of these demo sites you are copy/pasting a bunch of code versus leveraging a framework that handles that stuff for you. Yes, frameworks raise your "floor" of code-size but they provide an excellent foundation to build on and skills you can reuse across projects instead of them all being one-off or having to copy/paste a bunch of code.
- tgflynn 4y ago
  > Ok, but surely you see the difference between this very simple/straightforward "demo app" and a real webapp? Something like Zillow, Facebook, Doordash, Spotify, etc. Yes and no. What are those apps really doing that's fundamentally so much more complicated ? Obviously there's a lot more to their UI's and you'd need to be careful about doing full re-renders. I suspect anything that affects global page layout could become problematic. But I think it should be possible to predetermine the page layout (unless the viewport size changes, then you'd need to re-render everything, but that should be uncommon) and only re-render within div's of preset size. > I looked at your code and you had to write your own render loop to accomplish this which would break down if you had interactive stuff that you were rendering out You mean like generating forms/controls ? I have some other code I'm working on that does that and also doesn't seem particularly hard. For example I'm working on a chrome extension with an options page that updates another page and the local storage as soon as a user changes an option setting.
  - joshstrange 4y ago
    > Yes and no. What are those apps really doing that's fundamentally so much more complicated ? They have more views, more data, more data that needs to be kept in sync across multiple views. You cannot rerender (and inject/replace) every time the underlying data changes. It works up to a point but once you cross that rubicon it because very painful. I don't know how better to say this or explain it. I write webapps professionally and for side-projects, maintaining any of them in vanilla js would be a non-starter. I have even tried that for "smaller" webapps that "don't need a build step", it doesn't work. SCSS is vastly superior to CSS, TS is superior to JS, and templates that support things like `v-for="item of items"` or `v-if="condition"` or `@click="doTheThing"` are superior to HTML templates with event handlers, loops spitting out html, and conditional rendering of blocks. > You mean like generating forms/controls ? Yes. Those things make this all more complicated. I've built exactly what you have in the past and at a certain point it falls down hard. There is a noticeable lag when you change data and go to re-render. If the user is focused on an input and you re-render they lose focus unless you make sure to reset the focus after the render. If you wanted to do something like "As the user types re-render an element to show what they typed" (think example/preview, or even something like putting the name you are typing into the UI as a header) it gets really gross really fast. So you might start having smaller render areas "I'll just re-render this 1 part" but that also gets complicated very quickly and at the end of the day you are just building a worse framework without the benefit of the community.
wonnage 4y ago
I'm always amused at people who spend like a month learning something new and all of a sudden have opinions on the entire state of software development. They are of course the valid opinions of a neophyte but don't expect anyone to take you seriously.
- tgflynn 4y ago
  Being a neophyte at HTML5 web development doesn't make me a neophyte at software development, I've been doing that for well over 20 years. I'm always amused at people who make assumptions about who they're talking to online.
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
6510 4y ago
Well done! Much better than any framework already. A few suggestions! Look how slow the text renders when you hit reload. The content of the <code id="code-container"></code> is not going to change. Just put it inline: <code id="code-container"> <li>async function n2sort( data, view ) {</li> <li> const n = data.length;</li> <li> for( let i = 0; i < n; ++i ) {</li> <li> for( let j = 0; j < n; ++j ) {</li> <li> if( data[i] < data[j] ) {</li> <li> swap( data, i, j );</li> <li> }</li><li> }</li> <li> await view.addRow( data, `Step ${i + 1}` );</li> <li> }</li> <li>}</li> </code> (As a joke you could put the actual <script> tag there and style it like script{white-space:pre;display:block} ) The external <link rel="stylesheet" type="text/css" href="style.css"> can also be pasted inline between <style></style> tags. Same for the script at the end of the page, just put the content between <script></script> tags. All the way at the top a document type would be useful <!DOCTYPE html> If you want the steps could be replaced by rendering the entire table and hide each line with css. Pressing step only has to reveal the next line. I personally consider it a good habit to have the buttons update the location.search part of the url then listen for url changes with window.addEventListener('locationchange', function) and modify the page accordingly. It's not particularly useful for this app but its nice to have an url that represents the state of the application. https://tgflynn.github.io/AlgoVis/?step=2&array=1-2-3-4-5 https://tgflynn.github.io/AlgoVis/?step=2&array=1-2-3-4-5
- tgflynn 4y ago
  I have a suspicion that your entire comment was intended as some kind of joke, but I'll address your points as if you are being serious. > Much better than any framework already. I doubt that. If my first attempt at a dynamic web app in like 10 years is better than the current frameworks than the state of web development must be much worse than I realized. > Look how slow the text renders when you hit reload. You're right, there is a noticeable rendering glitch that I hadn't noticed before, thanks. Maybe this is already an early indication of the limitations of the approach I used here, or at least one of the trade-offs. > The content of the <code id="code-container"></code> is not going to change. Just put it inline: One of my goals with this demo was to display the exact same code in the blurb on the left as was being run on the right. Another goal was to minimize the amount of change needed to the basic algorithm implementation to update the display. I was able to get it down to one extra line, but maybe there's a way to avoid that entirely. > All the way at the top a document type would be useful <!DOCTYPE html> It's there, you must have missed it (in chrome "view page source" colors that line with very low contrast). Your other comments about inlining go against most advice I've seen on best practices (with which I happen to agree). For one thing it's much nicer to edit files that are written in one language than in 2 or 3. > I personally consider it a good habit to have the buttons update the location.search part of the url Interesting, I'll have to give that one some thought.

guilherme-puida 4y ago

> simple demo app I don't think you can judge if the DOM api sucks if you are using a "simple demo app" as your baseline, though.

tgflynn 4y ago
All software is built from simple primitives. If the fundamentals are solid scaling up should be just a matter of managing complexity in your own code. I'm aware that performance problems that I don't have direct control over could occur at some point, but would that be the fault of the DOM API itself ?
- arbitrage 4y ago
  so, yes, you are not wrong. the issue here is the differential of 'managing complexity' with regards to time. as the functionality of the app progresses beyond a certain complexity (admittedly, this is nebulously defined), increasing changes to complexity require more time to effect. beyond a certain point of functionality, the need for a a framework to manage these things becomes emergent. at that point, a single coder can resume making more complex changes with the aide of the framework, than she could do without it. you're not wrong, you just are not considering a big enough scope over which to evaluate what the manual manipulation of software primitives is worth. in the end, frameworks aide results beyond the ability of a single coder to implement on their own.
- guilherme-puida 4y ago
  If the DOM api is not expressive enough, you end up having to wrap it with your own custom abstractions. At that point, is it not better to use a battle-proven abstraction?
  - tgflynn 4y ago
    Only if they're clearly better than the abstractions I would come up with. Which is rarely the case, especially if most of these frameworks were developed in an ad hoc manner without deep consideration of what the fundamental problems are that need solving, and even more so if they had to incorporate workarounds for browser issues that are no longer very relevant in 2022.
    - wonnage 4y ago
      sounds like someone has a bad case of not-invented-here
      - spoils19 4y ago
        Sounds like someone had a bad case of framework chasing and hype driven development. I support the original poster as developing your own is always better than reusing, no exceptions.
        phist_mcgee 4y ago
        I've worked on codebases like your's before, where in-house 'we can do it better' reigned. In my experience it never was better, and when the grand wizard holding it all together got hit by a bus, everyone was blocked. Frameworks are a common understanding that people can plug and play into. And yes, that's a critical part of maintainable code, the ability for a person to quickly get up to speed and fix things.
        wonnage 4y ago
        This from someone who can’t comprehend why government mandated hard hat safety standards might be good. It all fits.

joshstrange 4y ago

Ok, but surely you see the difference between this very simple/straightforward "demo app" and a real webapp? Something like Zillow, Facebook, Doordash, Spotify, etc. I looked at your code and you had to write your own render loop to accomplish this which would break down if you had interactive stuff that you were rendering out (I know, I've done this before). As it stands your interactions ("New Data", "Run", "Step", "Reset") are completely separate from the rendered data. Once you start combining those it gets harder. It's still possible but you are reinventing the wheel. For a small demo like this vanilla JS might make sense but scaling this up does not work (once your rendered HTML reaches a certain size it's jarring when it re-renders, same deal if you have interactive UI that you are rendering out) and if you need to make 10x of these demo sites you are copy/pasting a bunch of code versus leveraging a framework that handles that stuff for you. Yes, frameworks raise your "floor" of code-size but they provide an excellent foundation to build on and skills you can reuse across projects instead of them all being one-off or having to copy/paste a bunch of code.

tgflynn 4y ago
> Ok, but surely you see the difference between this very simple/straightforward "demo app" and a real webapp? Something like Zillow, Facebook, Doordash, Spotify, etc. Yes and no. What are those apps really doing that's fundamentally so much more complicated ? Obviously there's a lot more to their UI's and you'd need to be careful about doing full re-renders. I suspect anything that affects global page layout could become problematic. But I think it should be possible to predetermine the page layout (unless the viewport size changes, then you'd need to re-render everything, but that should be uncommon) and only re-render within div's of preset size. > I looked at your code and you had to write your own render loop to accomplish this which would break down if you had interactive stuff that you were rendering out You mean like generating forms/controls ? I have some other code I'm working on that does that and also doesn't seem particularly hard. For example I'm working on a chrome extension with an options page that updates another page and the local storage as soon as a user changes an option setting.
- joshstrange 4y ago
  > Yes and no. What are those apps really doing that's fundamentally so much more complicated ? They have more views, more data, more data that needs to be kept in sync across multiple views. You cannot rerender (and inject/replace) every time the underlying data changes. It works up to a point but once you cross that rubicon it because very painful. I don't know how better to say this or explain it. I write webapps professionally and for side-projects, maintaining any of them in vanilla js would be a non-starter. I have even tried that for "smaller" webapps that "don't need a build step", it doesn't work. SCSS is vastly superior to CSS, TS is superior to JS, and templates that support things like `v-for="item of items"` or `v-if="condition"` or `@click="doTheThing"` are superior to HTML templates with event handlers, loops spitting out html, and conditional rendering of blocks. > You mean like generating forms/controls ? Yes. Those things make this all more complicated. I've built exactly what you have in the past and at a certain point it falls down hard. There is a noticeable lag when you change data and go to re-render. If the user is focused on an input and you re-render they lose focus unless you make sure to reset the focus after the render. If you wanted to do something like "As the user types re-render an element to show what they typed" (think example/preview, or even something like putting the name you are typing into the UI as a header) it gets really gross really fast. So you might start having smaller render areas "I'll just re-render this 1 part" but that also gets complicated very quickly and at the end of the day you are just building a worse framework without the benefit of the community.

wonnage 4y ago

I'm always amused at people who spend like a month learning something new and all of a sudden have opinions on the entire state of software development. They are of course the valid opinions of a neophyte but don't expect anyone to take you seriously.

tgflynn 4y ago
Being a neophyte at HTML5 web development doesn't make me a neophyte at software development, I've been doing that for well over 20 years. I'm always amused at people who make assumptions about who they're talking to online.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]

6510 4y ago

Well done! Much better than any framework already. A few suggestions! Look how slow the text renders when you hit reload. The content of the <code id="code-container"></code> is not going to change. Just put it inline: <code id="code-container"> <li>async function n2sort( data, view ) {</li> <li> const n = data.length;</li> <li> for( let i = 0; i < n; ++i ) {</li> <li> for( let j = 0; j < n; ++j ) {</li> <li> if( data[i] < data[j] ) {</li> <li> swap( data, i, j );</li> <li> }</li><li> }</li> <li> await view.addRow( data, `Step ${i + 1}` );</li> <li> }</li> <li>}</li> </code> (As a joke you could put the actual <script> tag there and style it like script{white-space:pre;display:block} ) The external <link rel="stylesheet" type="text/css" href="style.css"> can also be pasted inline between <style></style> tags. Same for the script at the end of the page, just put the content between <script></script> tags. All the way at the top a document type would be useful <!DOCTYPE html> If you want the steps could be replaced by rendering the entire table and hide each line with css. Pressing step only has to reveal the next line. I personally consider it a good habit to have the buttons update the location.search part of the url then listen for url changes with window.addEventListener('locationchange', function) and modify the page accordingly. It's not particularly useful for this app but its nice to have an url that represents the state of the application. https://tgflynn.github.io/AlgoVis/?step=2&array=1-2-3-4-5 https://tgflynn.github.io/AlgoVis/?step=2&array=1-2-3-4-5

tgflynn 4y ago
I have a suspicion that your entire comment was intended as some kind of joke, but I'll address your points as if you are being serious. > Much better than any framework already. I doubt that. If my first attempt at a dynamic web app in like 10 years is better than the current frameworks than the state of web development must be much worse than I realized. > Look how slow the text renders when you hit reload. You're right, there is a noticeable rendering glitch that I hadn't noticed before, thanks. Maybe this is already an early indication of the limitations of the approach I used here, or at least one of the trade-offs. > The content of the <code id="code-container"></code> is not going to change. Just put it inline: One of my goals with this demo was to display the exact same code in the blurb on the left as was being run on the right. Another goal was to minimize the amount of change needed to the basic algorithm implementation to update the display. I was able to get it down to one extra line, but maybe there's a way to avoid that entirely. > All the way at the top a document type would be useful <!DOCTYPE html> It's there, you must have missed it (in chrome "view page source" colors that line with very low contrast). Your other comments about inlining go against most advice I've seen on best practices (with which I happen to agree). For one thing it's much nicer to edit files that are written in one language than in 2 or 3. > I personally consider it a good habit to have the buttons update the location.search part of the url Interesting, I'll have to give that one some thought.