1. 10

  2. 8

    JS frameworks are already building on top of these things though. Ember’s components track web components closely, for example.

    You can’t get away from frameworks. At best, you end up with your own bespoke framework.

    Finally, it’s very hard to take ‘I’ve never needed data binding’ seriously. The declarative nature of using two-way binding has been a massive boost to fixing all those weird, out-of-sync behaviors that make using heavy-JS sites terrible to use.

    1. 3

      You can’t get away from frameworks. At best, you end up with your own bespoke framework.

      You can use libraries. Your application does not need a framework.

      1. 2

        If you assemble a bunch of libraries, you have built a framework.

        1. 7

          Libraries compose, I can keep adding more. Frameworks surround, I can have only one.

          1. 2

            Do you consider Rails a framework? It easily composes with any other rack-based framework.

          2. 2

            A library would be a set of functions. What is a framework? I honestly don’t know.

            1. 5

              When you use a bunch of libraries, your application keeps control: your application code calls the library code. With a framework, the control is reverted: the framework calls your application code.

              1. 2

                What does it mean to call my application code? If I pass a function to a library to use, is that library now a framework?

                1. 1

                  Good question. You’re right, my definition is too much restrictive.

                  Let’s consider an HTTP routing library. Each route, for example /article/<id>, is mapped to a function. When the URL matches the route, the library can either return the related function, or simply call it. I would say this is irrelevant to differentiate a framework from a library.

                  What is relevant is your application code calling the routing function itself or not. A framework gives you a ready-to-use “main” function or a “run” binary. You don’t call the routing library yourself. One good example is the Django framework.

                  On the other hand, with a library, the “main” function or binary is written by you. It instantiates the router, handles HTTP requests, call the routing library to get the function matching the URL, etc. This is what I meant in my previous comment. Of course, the library can still accept traditional callbacks. Express.js is a good example of this approach in my opinion.

                  1. 3

                    You have to write the Main module yourself in Haskell, but you have functions to use for the main function. Does that mean Haskell doesn’t have frameworks? Or is Scotty actually a framework in the following code?

                    {-# LANGUAGE OverloadedStrings #-}
                    module Main where
                    handlers :: ScottyM ()
                    handlers = get "/hello" (text "Hello world")
                    main :: IO ()
                    main = scotty 3000 handlers
      2. 8

        I think the author may be missing the point of frameworks.

        They’re not only about solving technical problems, they’re also about setting a baseline. The framework draws a line in the sand: “this is how we do AJAX”, “this is how we render JSON data”.

        For most teams it’s a win because you don’t have to create ad-hoc conventions.

        1. 1

          Agreed on the need create conventions, and the fact that frameworks help create a baseline for the whole team, but do we need so much code (like in Ember or Angular) to achieve this goal?

          1. 1

            Well, I think the problem is nobody ever chose a framework because of its nice conventions. Features sell frameworks.

            Because of this framework writers get sidetracked into thinking they’ve got to add more features, making in turn their frameworks less generic.

            1. 2

              Framework providers also have an implicit contract in that they are responsible for the universe. Doesn’t supply a database driver that plays with the framework ORM and transaction system, it is now the framework author’s responsibility.

        2. 5

          Frameworks aren’t about ignoring the browser platform or papering over inconsistencies. They’re about shared solutions to common problems. Yehuda Katz gave a great explanation of this in his RailsConf 2014 talk. The new specs the author brings up are great things and I’m excited for them also, but they’re ultimately just implementation details. They don’t solve any architectural problems.

          There’s a lot of confusion around this topic because HTML and JS have historically only provided the UI for a server-side application. That’s where this focus on widgets and components comes from. But we’re building apps in the browser now. Any time you write code you have to make decisions about where to put it and how to structure it. Frameworks provide answers to these questions based upon the community’s past experience. Sometimes these decisions aren’t right for your situation — and that’s painful — but a good framework will let you substitute your own solutions for the ones it provides out of the box. What’s more painful for me is realizing that my ad-hoc fix for a problem I may have not even consciously recognized is now preventing me from making forward progress.

          The problem of code being locked up in framework-specific wrappers is a real one, though. I agree that it should be avoided whenever possible. I think Ember has a pretty good story right now for integrating third-party non-Ember code and I know work is being done to allow portability and interoperability of Ember components with other Web Components polyfills.