This reminds me of http://vanilla-js.com/ š. I do agree with the sentiment when possible though ā keep your footprint as small and sleek as possible so long as it doesnāt cripple your ability to maintain and scale.
My favorite part about this website has always been that the gzipped version is 25 bytes due to the compression header. I think I checked once they it was correct by gzipping an empty file.
It sounds like this is hovering between an experiment and a recommendation. The first part says:
In this article, I suggest doing the inverse and use just a simple index.html file
The body changes it to a question:
How much harder would life be if a single index.html was used to drive all of the development instead of all those Create-React-App/Babel/WebPack/npm/yarn/d/sass/styled-components/optimizers?
So Iād rather see the authorās examples and use cases in this style first. (And yes Iām skeptical that they used it for anything with users.)
This is veering into the genre of post: āI am going to advocate something without realizing how wide the problem space isā. Sure this could be good for some problems. But itās not good for others.
Show us what you did first ā i.e. is there a deployed app with users, or a throwaway weekend project ā and then let the reader decide if that approach applies to their problem.
Those of you who really canāt stand web development can always filter. Unsupported categorical statements like this donāt reflect well on the lobsters community. I ask that people who upvoted it reconsider. The author may have left themselves open to misinterpretation by not providing context in the article. However, looking at their other blog posts, it seems theyāre working on some non-trivial graphics, which might warrant some of the technical choices they describe.
Web developers are the only category of programmer who have to endure this level of condescension frequently. I feel like Iām seeing posts shaming developers for their supposedly bloated JS or mocking users of JS/frameworks/electron on a daily basis on the lobste.rs front page nowadays.
This may be because the ecosystem is deeply fucked, many developers are complicit in this, and all of us are victims of the previous two points to one degree or another.
Iāve been doing web development, front-end and back-end, for a while now, and I agree with the root comment. That said, the author probably has a reason for tackling things this way, and we got to see some neat notes on using <template>.
No lib is going to be used for routing. Routing is going to consist of simple manipulations of the browser history with popstate and pushstate. The basic approach is: [four increasingly complex steps that donāt even do error handling]
ā¦if only there was some sort of semantic element that allowed us to tell the browser to do the navigation for usā¦
Iām assuming your sarcasm is aimed at what you presume to be overlooked anchor tags. Depending on what the author is building, it may be necessary to support in-app transitions without loading a whole new page. However, the articleās lack of context make it difficult to assess the appropriateness of their technology choices.
But you could still do <a href=ā#some_idā> to transition on the same page, right? And use CSS to dictate what section is visible to make it āapp-likeā rather than just one long page. But yeah, itās hard to tell if the author is against this for some reason.
Thatās an interesting idea, but it assumes the routing is directly related to DOM content. If the routing is in relation to canvas content, some kind of JS-based routing will be necessary. But again, I donāt think any meaningful assessments can be made without more context.
I recently had a taste of this on my own site; I vented about it a bit in the commit log. Even standards for seemingly simple things like icons have grown to include way too many things.
This also goes beyond standards. The growth of huge frameworks and prioritization of developer speed and convenience over the quality of the software itself has been awful for progressive enhancement. CSS, images, JS, etc. all may or may not load; they are optional enhancements that pages should work well without. Exceptions exist, but they shouldnāt be common.
Most sites donāt even need to be complex enough to warrant advanced cross-browser testing; they just need to be marked-up text documents. I posted a blog post to lobsters a few weeks ago that summarized my views.
I think the core message here, that html offers a lot of features and flexibility, is quite relevant.
Mind you I donāt think the author is advocating for just using html everywhere, as much as he is showcasing itās limits to encourage people to use it more.
Personal rant/anecdote:
Personally Iām able to maintain a blog website with comments (5 supported logins), a livee markdown editor, reactions, frontend content caching, frontend navigation and article filtering, subscriptions, social media sharingā¦etc (basically most features Iād expect from medium), and the whole thing is a 1k lines html file, including the style and javascripts (and a much simpler python backend). And it handles spikes of ~5,000 requests per minute quite alright, despite being ran on a tiny ARM server, I doubt wordpress and itās hundreds of API and database calls could do that. The kind of volume I serve for 10$ would run me hundreds of dollars even with a cheap platform like wix or ghost.
A slow and complicated frontend also causes a slow and overly complex backend.
Granted, I donāt think I could have managed with pure html, probably not even pure html and css, but I think mixing the 3 in one file has a lot of leeway given new browser features and compatibility.
/Rant
Many websites which are sprawling codebases of dozens or hundreds of lines of code could probably just be a single index.html and do just fine, better even.
So itās worth remembering just how much one can do even with pure html.
This reminds me of http://vanilla-js.com/ š. I do agree with the sentiment when possible though ā keep your footprint as small and sleek as possible so long as it doesnāt cripple your ability to maintain and scale.
Thatās amazing
My favorite part about this website has always been that the gzipped version is 25 bytes due to the compression header. I think I checked once they it was correct by gzipping an empty file.
It sounds like this is hovering between an experiment and a recommendation. The first part says:
The body changes it to a question:
So Iād rather see the authorās examples and use cases in this style first. (And yes Iām skeptical that they used it for anything with users.)
This is veering into the genre of post: āI am going to advocate something without realizing how wide the problem space isā. Sure this could be good for some problems. But itās not good for others.
Show us what you did first ā i.e. is there a deployed app with users, or a throwaway weekend project ā and then let the reader decide if that approach applies to their problem.
Web developers really are a parody of themselves. Everything they create must be a Rube Goldberg machine.
Those of you who really canāt stand web development can always filter. Unsupported categorical statements like this donāt reflect well on the lobsters community. I ask that people who upvoted it reconsider. The author may have left themselves open to misinterpretation by not providing context in the article. However, looking at their other blog posts, it seems theyāre working on some non-trivial graphics, which might warrant some of the technical choices they describe.
Web developers are the only category of programmer who have to endure this level of condescension frequently. I feel like Iām seeing posts shaming developers for their supposedly bloated JS or mocking users of JS/frameworks/electron on a daily basis on the lobste.rs front page nowadays.
This may be because the ecosystem is deeply fucked, many developers are complicit in this, and all of us are victims of the previous two points to one degree or another.
Iāve been doing web development, front-end and back-end, for a while now, and I agree with the root comment. That said, the author probably has a reason for tackling things this way, and we got to see some neat notes on using
<template>.I stopped reading when I reached
ā¦if only there was some sort of semantic element that allowed us to tell the browser to do the navigation for usā¦
Iām assuming your sarcasm is aimed at what you presume to be overlooked anchor tags. Depending on what the author is building, it may be necessary to support in-app transitions without loading a whole new page. However, the articleās lack of context make it difficult to assess the appropriateness of their technology choices.
But you could still do <a href=ā#some_idā> to transition on the same page, right? And use CSS to dictate what section is visible to make it āapp-likeā rather than just one long page. But yeah, itās hard to tell if the author is against this for some reason.
Thatās an interesting idea, but it assumes the routing is directly related to DOM content. If the routing is in relation to canvas content, some kind of JS-based routing will be necessary. But again, I donāt think any meaningful assessments can be made without more context.
So you stopped right before the recommendation not to use that technique for the most part, because ordinarily you just need a link and no JS.
I recently had a taste of this on my own site; I vented about it a bit in the commit log. Even standards for seemingly simple things like icons have grown to include way too many things.
This also goes beyond standards. The growth of huge frameworks and prioritization of developer speed and convenience over the quality of the software itself has been awful for progressive enhancement. CSS, images, JS, etc. all may or may not load; they are optional enhancements that pages should work well without. Exceptions exist, but they shouldnāt be common.
Most sites donāt even need to be complex enough to warrant advanced cross-browser testing; they just need to be marked-up text documents. I posted a blog post to lobsters a few weeks ago that summarized my views.
what are you, a non-web developer making desktop applications using non-web protocols or what?
I think the core message here, that html offers a lot of features and flexibility, is quite relevant.
Mind you I donāt think the author is advocating for just using html everywhere, as much as he is showcasing itās limits to encourage people to use it more.
Personal rant/anecdote:
Personally Iām able to maintain a blog website with comments (5 supported logins), a livee markdown editor, reactions, frontend content caching, frontend navigation and article filtering, subscriptions, social media sharingā¦etc (basically most features Iād expect from medium), and the whole thing is a 1k lines html file, including the style and javascripts (and a much simpler python backend). And it handles spikes of ~5,000 requests per minute quite alright, despite being ran on a tiny ARM server, I doubt wordpress and itās hundreds of API and database calls could do that. The kind of volume I serve for 10$ would run me hundreds of dollars even with a cheap platform like wix or ghost.
A slow and complicated frontend also causes a slow and overly complex backend.
Granted, I donāt think I could have managed with pure html, probably not even pure html and css, but I think mixing the 3 in one file has a lot of leeway given new browser features and compatibility.
/Rant
Many websites which are sprawling codebases of dozens or hundreds of lines of code could probably just be a single index.html and do just fine, better even.
So itās worth remembering just how much one can do even with pure html.
Wasnāt this submitted fairly recently? Or maybe something that looked a lot like it.
Itās pretty common and straightforward for an āindex.htmlā file to get spat out at the end of a build process by something like react-scripts
I think, what OP is saying with this is, āwhen the hell did we decide that next.js or gatsby setup were necessary to re-do your homepageā?
Whatās the context? Is the implication that all web apps should be built without frameworks?
From my perspective the article implicates that all websites should use JavaScript and invent convoluted solutions to non-existing problems.
Is the template approach works on older browser?