1. 27

  2. 13

    I’m not involved in web development and am not familiar with the issues here, but from the point of view of the outsider reading this post, I got the impression of:

    1. A system exists that is unwieldy and complex written in $FRAMEWORK
    2. A team looks at this and works to replace it in $FRAMEWORK + 1
    3. The result is relatively simple, clean and well understood, so people are happy
    4. Over time the complexity increases, and the people familiar with original decisions move on, so people are less familiar with what exists
    5. Goto 1

    Although it’s possible that a new framework really will fix it, the impression that I’m getting is the challenge is maintaining a system over time in the presence of employee turnover and evolving requirements. It’s generally easier to write new code than to read and fully understand old code, so the bias of new developers looking at old code is to believe it’s very complex and they can do better. Unfortunately from the perspective of somebody who has to read both versions, the improvement might not be so dramatic, and the only fair way to compare complexity is once the complete set of functionality exists in both.

    1. 2

      I think the saying goes “devil is in the detail”. I.e. it’s really hard to distinguish between meaningful changes and busywork when you’re not in the context.

      1. 1

        IDK, from my reading it’s like it is the original team that wrote a React application now rewrites it into simple HTML pages with some interactivity. Looks like they’ve spent a few years with their React-based application and know all the things there

      2. 3

        Why not both? There’s Next.js which is definitely not as light as the framework described in the post, but the page is still initially rendered on the server and client-side React takes over only for further interactions. It’s not perfect, but I think it’s a good compromise. Though obviously your custom framework will serve you better than massive framework like Next.

        1. 3

          But that’s what we had before! It still makes life of a simple Android user a pain. :)

          1. 1

            As someone who mostly left frontend web development ~5 years ago, I enjoyed using Next.js as it was relatively easy to build internal management applications with React (and Typescript as well as AntD in my case). So my perspective is from someone who’s not doing JavaScript fulltime.

            That said, rendering data server side and “hydrating” it later on with lots of JavaScript can easily lead to several megabytes per page load. Next.js solution with getStaticProps / getStaticPaths / getServerSideProps seems flexible enough to handle it, but some trade-offs might be involved.

          2. 2

            I have done a fair bit of react over the years and have cooled on it. Many web sites don’t need react in the way that folks tend to use it. SPAs are really great when applied to the appropriate context, but so many people use react (or angular, ember, whatever else) as a silver bullet solution for anything browser-related. It introduces so much complexity that you really may not even need.

            The problem I see is that some folks are gung-ho on it and try to encourage it all over when they don’t really understand the requirements.

            React router and a monolithic UI is often a mistake.

            1. 2

              We do React/Preact but decided that our site will definitely be segmented in to separate apps for different parts of the site.

              No mega react router for everything. No code splitting (if you need code splitting, I think the question is whether your app is too big to start with). We had to solve SSO to get between separate apps without annoying the user.

              Ferociously inline all CSS and images (and don’t allow mega PNG images, only SVG). Be extremely careful with 3rd party libraries component libraries. Always monitor page size when adding/updating libraries – in fact monitor it in CI.

              Our main entry point users hit is 223kb zipped SPA needing no extra assets to render. The other parts come in at less than that.

              Webpage speed is not about libs, server side or client side rendering, but about discipline. Discipline to not allow bloat, cause it doesn’t matter where the bloat comes from.

              1. 4

                That is certainly a way to do it! Why React though in this case? I’ve been thinking hard about this and decided that no client side rendering is actually a plus. You get page reloads but there is no “boot” phase like with client side frameworks. It’s just better from this point of view and composes well enough from developer point of view.

                1. 3

                  I think it comes down to what kind of thing you’re building. Our site has some pages which are just lists of things – that’s certainly a server side. But then we have some rather interactive “editors”, which are more interactive applications.

                  There’s definitely a case for people reaching for React/Vue/whatever “too early” out there.

                  We have an internal admin tool, and I decided it was going to be server side rendered. All operations are request-response, url parameters, posting forms etc. The funny thing was how awkward this was at first for some of my colleagues. Like… we’re collectively forgetting how to build a website like it’s 1999? People are more clued up to unidirectional flow using “reducers” and shadow DOM than just a bog standard request-response site :)

                  1. 4

                    we’re collectively forgetting how to build a website like it’s 1999?

                    This is definitely the case. :-) Just see this tweet somebody wrote to me:


                    I think the problem here is the hype. Hype around React generated a whole new generation of front-end developers who don’t know anything else - they just don’t have the perspective. Their perspective is React vs Vue. I tweeted a week ago a spoiler of that post saying “we’re dropping React” and a number of people asked “what is it, Vue? Angular?!” Ha-ha, surprise!

                    What is partially needed is more (platform-independent) tooling around that request-response stuff, so that it’s more convenient. And I think this crop of tools (intercooler, htmx, and twinspark) are a step in right direction. I’m wary of adding more features (like hyperscript or alpine.js), but this also could be a right solution for the job.

              2. 1

                I was blown away by the mention that it only took 4 months, but I was thinking about the kind of product my company builds, enterprise web frontends. The Kasta website seems like the perfect use case for this.

                1. 3

                  Please elaborate? :-)

                  1. 3

                    The frontend we’re porting to React is a 15 year old mess of jQuery and Prototype.js. It’s huge and has many recurring components. React’s composability is key for us. Some individual controls take us 4 man-months to port. We have planned to do the whole port in over 4 total years.

                    So when I read that you could implement the framework and port your site in 4 months and thought that that was a lot I was a bit surprised. But then I checked out the Kasta site. I don’t think I had ever before realized that use case can make such a difference for which framework would be best suited.

                    A choice between the big frameworks today (React, Vue, Ember…) would mainly depend on what the dev would prefer to work with. The use case doesn’t really matter for those. I only think of that with things like Elm, which open up very new possibilities.

                    From the examples in your docs, I can easily imagine what the Kasta source would look like, and how it wouldn’t work for our frontend. It sounds like something I’d want to use for a small hobby project. React has become my default expectation of what webdev should be like, but it’s so much hassle to start something.

                    1. 1

                      Some individual controls take us 4 man-months to port.

                      Wow, that’s huge. Can you share what component is that?

                      1. 2

                        For example, a seemingly simple thing like a value selector dropdown. The old UI code is so tightly coupled that it takes weeks to analyze where to even start. It’s also overloaded a bunch for specific cases, but with low cohesion and stuff like “if type==bla” in the supertype. And we can’t do everything at once so we have to figure out how to make it work with other parts of the old UI. And then we notice that some client projects inject js in the dropdowns which depends on the HTML structure of it and we have to make decisions about what we want to break…

                        We’re never just porting a component. OP very likely never has to deal with this. No matter how nasty the original jQuery code, he can just port the functionality in one go without even looking at the old logic.

                        1. 3

                          No matter how nasty the original jQuery code, he can just port the functionality in one go without even looking at the old logic.

                          It’s not exactly this easy. :) First, original right now is React code (it was jQuery 5 years ago, but that was an old story). Second, we’re making same code work with both React and TwinSpark, so components are reused. Which sometimes is hard because this means you have to kill weird React idioms - and that’s not easy.

                      2. 1

                        but it’s so much hassle to start something

                        oh yes, a “simple setup” is already so huge

                  2. 1

                    Back in 2011, I happened to get a job writing Backbone.js app. If you never did that, don’t. I was complaining about difficulties with composition left and right to whoever would listen.

                    I’ve written a fairly big SPA (my one and only) with most of it’s development from 2011 until somewhere in 2014. At the time, Backbone.js was in vogue, but there was a steady stream of new daily JS frameworks coming out. Angular did not exist yet. Backbone is not perfect, but the fact that it’s a digestible and well documented 2096 line library that simply let’s you organize user action and behaviour into views, and business logic into models and collections, makes it fit in any framework or way you like to compose it. This means you really have to come up with the architecture of the application all by yourself. This can be a pro or a con depending on experience and skills.

                    Recently we’ve started refactoring the UI and I’m all into Backbone again and find myself very pleased that it is still maintained, small and digestible, and sort of done so I’m happy to keep using it. Even if in the worst case Backbone maintenance is dropped, it is conceivable that I can maintain the 2k lines myself. This is in stark contrast with the liability you get when using fully fledged frameworks. Instead of having to learn a framework now I can just focus on native Javascript, the DOM and the application at hand.