1. 21
  1.  

  2. 9

    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.

    1. 3

      That’s amazing

      1. 1

        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.

    2. 7

      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.

      1. 29

        Web developers really are a parody of themselves. Everything they create must be a Rube Goldberg machine.

        1. 33

          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.

          1. 16

            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.

            1. 18

              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.

            2. 9

              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>.

            3. 12

              I stopped reading when I reached

              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…

              1. 8

                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.

                1. 2

                  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.

                  1. 3

                    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.

                2. 3

                  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.

                3. 5

                  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.

                  1. 4

                    what are you, a non-web developer making desktop applications using non-web protocols or what?

                  2. 4

                    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.

                    1. 3

                      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

                      1. 2

                        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”?

                        1. 2

                          What’s the context? Is the implication that all web apps should be built without frameworks?

                          1. 8

                            From my perspective the article implicates that all websites should use JavaScript and invent convoluted solutions to non-existing problems.

                          2. 1

                            Is the template approach works on older browser?