3 ms·

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

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.

6510 4y ago
> > 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. The state of webdev is indeed terrible, there is progress being made but its hard to tell where and if it is real progress. There was a fun article the other day onhere that explained why React became popular and how that no longer necessarily applies but the popularity persists because it is well known. I cant objectively tell how true that is. What is the better stuff is like... peoples opinion? Frameworks are there because html/css and js have their shortcomings (what those are is more opinions) but I much prefer working with those over hiding them. An abstraction on top of something bad doesn't make it great. People can glue code fantastic things really fast nowadays but when it stops working it takes a wizard to fix things. With many components of your thing getting updated it is easier for conflicts to arise. Perhaps the question is: How much performance and stability can you exchange for fast development? Guessing how much performance you are going to lose is not easy to guess, it might be completely irrelevant for the use case, it might be horrific. Will you be around to fix things in the future? Will others have to work on your code? A reasonably sane standard way of doing something is going to be a huge advantage there. > 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. Nah, its all the same. You are gaining nothing. You could ask : how much editing files are you going to do vs how many times are people going to load the page? A http request takes time, the browser doesn't know it has to load a css file and 2 scripts until it receives and parses the html, a new request is made which takes time again. Depending where the user and the server are located a request may take a long time. I find it quite silly how we need a gaming pc to parse websites nowadays. The user is also in some remote corner of some remote country on ancient hardware. You should absolutely have external css and js if the user is likely to browse multiple pages. Inline they would have to load it for every page view. People may also block external js and css files. Add blockers may get rid of your code section and if your app is many files spread out over many folders it is much more likely to break than a single file that contains everything. The single file will either load and work or the server is not working. In an ideal world we could have things inline on the front page and tie it to an url so that it can be cached and used on other pages.
- tgflynn 4y ago
  I would never accept poor code organization as a trade-off for performance. If using linked resources becomes a performance issue I would probably use a server side bundler, or write my own.

6510 4y ago

> > 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. The state of webdev is indeed terrible, there is progress being made but its hard to tell where and if it is real progress. There was a fun article the other day onhere that explained why React became popular and how that no longer necessarily applies but the popularity persists because it is well known. I cant objectively tell how true that is. What is the better stuff is like... peoples opinion? Frameworks are there because html/css and js have their shortcomings (what those are is more opinions) but I much prefer working with those over hiding them. An abstraction on top of something bad doesn't make it great. People can glue code fantastic things really fast nowadays but when it stops working it takes a wizard to fix things. With many components of your thing getting updated it is easier for conflicts to arise. Perhaps the question is: How much performance and stability can you exchange for fast development? Guessing how much performance you are going to lose is not easy to guess, it might be completely irrelevant for the use case, it might be horrific. Will you be around to fix things in the future? Will others have to work on your code? A reasonably sane standard way of doing something is going to be a huge advantage there. > 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. Nah, its all the same. You are gaining nothing. You could ask : how much editing files are you going to do vs how many times are people going to load the page? A http request takes time, the browser doesn't know it has to load a css file and 2 scripts until it receives and parses the html, a new request is made which takes time again. Depending where the user and the server are located a request may take a long time. I find it quite silly how we need a gaming pc to parse websites nowadays. The user is also in some remote corner of some remote country on ancient hardware. You should absolutely have external css and js if the user is likely to browse multiple pages. Inline they would have to load it for every page view. People may also block external js and css files. Add blockers may get rid of your code section and if your app is many files spread out over many folders it is much more likely to break than a single file that contains everything. The single file will either load and work or the server is not working. In an ideal world we could have things inline on the front page and tie it to an url so that it can be cached and used on other pages.

tgflynn 4y ago
I would never accept poor code organization as a trade-off for performance. If using linked resources becomes a performance issue I would probably use a server side bundler, or write my own.