12 ms·

What to expect from your framework

119 points by hejsna 4y ago

darkhorse13 4y ago
This is really great, and I'm really happy people are finally waking up to this. I've stuck with Django through all of this and never looked back. Nowadays with stuff like HTMX, things have never been better! Could we do this for CSS-in-JS next please? With React 18 making a strong push for compiled CSS, we have libraries now that let you write CSS (compiled) using Typescript. This is also absolutely crazy to me because we COULD BE JUST WRITING CSS instead (especially with variable support).
- di4na 4y ago
  I have a whole piece coming down the pipeline on this. I think a huge reason the js crowd got away with the "better DX" spiel is because CSS got left on the side. So doing it CSS-in-JS allowed to paper over the CSS painpoint for componentisation and composition. If you look at it this way, Tailwind make sense. Because what it gives you is mixins and variable. Just... Mixins in html `class`
- cutler 4y ago
  CSS has been mangled so many different ways, including the loathsome Tailwind, that I can't imagine what a newb web dev has to plough through these days. Some of us with longer memories were overjoyed to see browsers finally adopting standards after the erosion of Microsoft's reign but now it appears we're intent on destroying the value of what we waited 15 years for. Fer Kreissakes just write raw, unadulterated CSS and enjoy your freedom from the CSS hacks that were unavoidable back in the late 90s/early 2000s.
  - beezlewax 4y ago
    Refreshing to see someone else who hates Tailwind. It's a nightmare.
    - cutler 4y ago
      The worst Tailwind I've seen is HTML littered with a, a:hover etc. declarations on every hyperlink. OK, you can create a global Tailwind stylesheet in your config but doesn't that defeat Tailwind's purpose?
      - brycewray 4y ago
        According to Adam Wathan himself in 2020, yes, it does: https://twitter.com/adamwathan/status/1226511611592085504 https://twitter.com/adamwathan/status/1226511611592085504
        cutler 4y ago
        Oh, and that's discounting responsive breakpoints. So if you have 3 of those that can be 3 lots of a, a:hover etc. for every hyperlink. You couldn't make this up.
    - earthling8118 4y ago
      From what I can tell, this is a very common take. Especially on this site.
    - naasking 4y ago
      Haha, I love Tailwind and Tachyons! Writing CSS is still a PITA.
    - pydry 4y ago
      What do you prefer & why? As a somewhat outsider to CSS I look at tailwind and don't feel excited but I do wonder if thats as good as it gets.
      - cutler 4y ago
        I prefer CSS. We even have browser support for CSS variables now so what else do you need? Tailwind wipes out half of the features of CSS and replaces them with mindless inline repetition and bloat all in the name of convenience. I call it inconvenience and refuse to work on Tailwind projects.
- Kiro 4y ago
  Wow, I truly hope you are wrong. Non-scoped CSS where you have to come up with names for everything and that doesn't live right next to the markup in the same file as the component is the worst. The whole cascading part is also something I hope I never have to deal with again with conflicting styles being inherited and overridden all over the place. Just let me isolate everything and let me freely copy a component file with all styling included without relying on any global CSS.
  - jstummbillig 4y ago
    What do you do to keep your inter component styling in sync?
    - darkhorse13 4y ago
      In my experience, this is usually solved with more TS/JS abstractions, something like global theming. Often they are hacky and poorly implemented, and always they are leaky.
KrugerDunnings 4y ago
I dislike frameworks for the same reason most of their proponents like frameworks, you can not expect to out-compete all the smart people working together on a common goal. Frameworks are bad at cultivating off-colour ideas, they tend to have a well curated API but are often stuck with a singular architecture. Sometimes the solution is to be found in some lateral dimension. One such example is PostREST, it does away with 80% of API boilerplate by inferring the API from the database schema using functional programming magic. You sort of have to become a Postgresql wizard to get everything out of it, but I feel that this knowledge is somehow more valuable than yet another backend framework.
- mattgreenrocks 4y ago
  Mediocrity enshrined as a process that gets elevated to best practice. And then you get yelled at if you try to improve on it, because it is a best practice. :)
  - revscat 4y ago
    You just described my last employer to a T, and all because of ego. They kept solving problems that the framework they used already had solutions for. You were actively discouraged from coming up with any different solutions, because the VP of development was stupid and didn’t want anybody changing the patterns he used when they started the company. This included things like “using base classes or modules”, any third party libraries, code linters, database views, and many others. It was a huge waste of YC money, but the money kept pouring in.
revskill 4y ago
"Concatenates text and fires it off to the browser in a straightforward and predictable way." What ? It's in 2023, you don't want to concanate text ?
- ziftface 4y ago
  Everything concatenates text before render, including react. I don't think he was implying you have to do it manually.
- mst 4y ago
  That would rule out almost all server side templating systems, and most non-JSX client side ones (svelte, vue and angular all involve it to some extent) so I don't think that's quite right. I think maybe you've misread the author talking about the fact that most server side templating systems are fundamentally fancy ways to concatenate text as meaning writing the literal text concatenation yourself without having a library do it for you?
nickjj 4y ago
I like using `rails middleware` as an example because it's true, tons of things in that list are important. A good example of this is: Rack::MethodOverride Try making your non-JS server rendered view functions and HTML form submissions handle PUT, PATCH and DELETE. Depending on which lightweight alternative to Rails you're using this can become very tricky and you end up spending an entire day of Googling and maybe finding a questionable solution instead of having that available without thinking about it.
- christophilus 4y ago
  Unless I’m misunderstanding you, this is trivial in every stack I’ve used (.NET, Node, Rails, and Go). I can’t imagine why this would be difficult.
  - nickjj 4y ago
    > Unless I’m misunderstanding you, this is trivial in every stack I’ve used (.NET, Node, Rails, and Go). I can’t imagine why this would be difficult. It's trivial in Rails because the middleware mentioned handles it. Forms only allow GET and POST if you submit it from a browser without JavaScript. That means you need to do things like introduce a hidden form field such as _method with the real method you want to use such as PATCH and then your framework's middleware level needs to understand how to translate that to call the correct function to handle the request. There's all sorts of edge cases around dealing with files and detecting if the request needs to be translated, etc.. With Flask this is a huge clusterfuck, https://blog.carsonevans.ca/2020/07/06/request-method-spoofing-in-flask/ https://blog.carsonevans.ca/2020/07/06/request-method-spoofi... has a breakdown on how it's anything but trivial. Sure there's https://flask.palletsprojects.com/en/2.2.x/patterns/methodoverrides/ https://flask.palletsprojects.com/en/2.2.x/patterns/methodov... but this involves setting a header which implies it's submit through JavaScript or another service over an API but in our case we want to submit it through a browser without using JavaScript.
imetatroll 4y ago
And good old Johan wrote many an app, rode off into the sunset victorious and left the job of maintaining his third party soup to some poor soul.
- sodapopcan 4y ago
  This made me lol and maybe I misunderstood but, what? Only once in my career I've come in on a fairly mature project that was, for the most part, done The Rails Way (TM). The code did its boring job quite well and every new place I looked I was able to understand and find things very quickly. On the flipside, people can definitely lean too much into a framework in cases where it doesn't work and leave a mess, so it it's definitely a fine balance of knowing when to break from convention. But I have a hard time sympathizing with people who use a framework and break a bunch of its conventions for no other reason because they think they know better (ie, without even trying to make it work). Even if they are among the rare breed who write good documentation, a lot of frameworks out there have really good documentation I've already read. We're just making web apps here, people.
- frupert52 4y ago
  Don’t worry he hasn’t gone too far he’s just in that studio apartment on the end of your street
KronisLV 4y ago
> So half of this blog post has actually been sitting on my drive for a couple of months because I’ve had a good long sad about the distressingly low bar we’ve set for something to bill itself as a Framework. I suppose this is partly because we’ve never really agreed about what constitutes one, and spoiler alert I don’t have a proper working definition either. But let’s get this out of the way first: React is not a framework. I never got why people care about the difference between a library and framework and try to categorize these offerings, especially when we don't even have meaningful definitions. The way I've seen it, you're usually going to have one front end "base thing" and build everything around it - be it Vue, or React, or Angular, or Svelte, or jQuery, or Next.js, or Nuxt, or JSF, or Vaadin, or Laravel's Blade templates, or the Rails equivalent etc. In some cases, it will try to provide everything out of the box, in other cases you're going to integrate a bunch of other stuff to do what you want, but you're rarely (at least in my experience) going to have something like React combined with Vue, or Vue with Svelte in the same site, which is sometimes touted as one of the advantages of libraries. I think I can recall one micro frontend project in my past like that. Furthermore, I've seen very few cases where integrated libraries are ever swapped out for something else once there's lots of code written against them, so they get coupled with the rest of the codebase regardless (unless you're really good at establishing boundaries/abstractions), so that's another supposed advantage that doesn't always pan out. And even when you use most of the frameworks out there, you still need to think about UI components and such, of which there are many libraries to integrate with your framework, so you still need additional bits introduced. It's almost like saying "Next.js acts 75% like a framework, whereas React only provides 25% of what you'd need for a full batteries included experience and therefore will mostly be treated as a library on its own." Silly way of framing it, I'll admit, but the end result will most likely be the same - one big repo of front end code (possibly a sub-folder), regardless of how many packages it's made up of. Just pick a group of solutions that fit your architecture of choice: Laravel, Rails and Django front end offerings are all good for SSR, whereas for SPAs just pick things depending on how much of an integrated experience you want, anything from Nuxt to barebones Vue, with libraries imported based on needs. Personally, I like the benefits of SSR (how integrated development can feel, easy to reason about), but I dislike the coupling and how you eventually will need to upgrade "the entire thing", which might be a big rewrite (e.g. moving from Spring to Spring Boot, or upgrading Rails/Laravel projects across major versions). I like the ability to throw away and replace SPAs if the need presents itself (AngularJS, anyone?) and the clear decoupling thanks to the API (running the old and new thing side by side is nice for dev). Oh, also SPAs lend themselves nicely for build parallelization, but have the downside of two deployment units (e.g. separate front end and back end containers/packages). Solutions that give you most of what you'll need are great, but only for as long as you don't have to fight against them due to needing to do something different.
ChrisMarshallNY 4y ago
I enjoyed that read! Johan is a great writer. I've written frameworks, libraries, SDKs, APIs, and drivers. Most are not frameworks. Frameworks are a lot of work to write and maintain. The most painful part of writing a framework, is the "rubber meets the road" part, where I suddenly realize that all that TLC I put into developing Guiding Principles, Mental Models, Basic Philosophies, etc. ad nauseam, were for shit, because no one is using my marvelous tool, the way I expect[0], and no one is oohing and ahhing over my masterful implementation. That ends up as a huge smorgasbord, serving a lot of Crow, Egg On Face, and Humble Pie. [0] https://www.theonion.com/bantu-tribesman-uses-ibm-global-uplink-network-modem-to-1819563905 https://www.theonion.com/bantu-tribesman-uses-ibm-global-upl...
howaboutnope 4y ago
A really, really good podcast I listened to recently: https://changelog.com/news/web-developments-lost-decade-LWao https://changelog.com/news/web-developments-lost-decade-LWao > Amal sits down for a one-on-one with Alex Russell, Microsoft Partner on the Edge team, and former Web Standards Tech Lead for Chrome, whose recent post, The Market for Lemons, stirred up a BIG conversation in the web development community. > Have we really lost a decade in potential progress? What happened? Where do we go from here?
mattgreenrocks 4y ago
Rails is probably the best framework still. But it still feels too low-level. I don’t want to care about the mountains of Web gunk there are: JSON serialization, HTTP methods, cookies, etc. Lack of static typing really hurts the maintenance story, too. I really just want to write business logic, wire that up to endpoints in a nice DSL, and move on. Most web frameworks seem to be obsessed with the web platform to the point they feel more like glorified macros, leaking its web gunk everywhere.
- arrowsmith 4y ago
  Cough phoenixframework.org cough
  - mattgreenrocks 4y ago
    It is definitely closest to what I want. I need to give it an honest try.
- ZephyrBlu 4y ago
  There is quite a lot of inherent complexity of web as a platform. If frameworks were any more abstracted they would be too brittle for a lot of use cases. Btw, use Sorbet for Ruby static typing. It's very ergonomic.
  - yoran 4y ago
    We adopted Sorbet for our codebase a couple of months ago, and I couldn't be happier with that choice. Sure, it's not as powerful as Typescript (e.g. no way to specify a union of constants like `type Result = 'ok' | 'error'`), but it's worth it just for the nil-check alone. And it's great for documenting too. It's easy to forget what type a method expects for its parameters.
- Jgrubb 4y ago
  Yes, but - if you don't understand how the web works and that it's made of HTTP and JSON and databases, you're probably going to find yourself trying to solve a problem you don't understand very quickly. I've always wanted to build a nice chair or cabinet, but I don't have the tools or the experience. It's not the tool's fault.
arrowsmith 4y ago
This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA? I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million years with Rails than five minutes with most of the React SPA monstrosities I've had to work with recently. I get it: if you want to build a super-complicated, dynamic front-end, there's only so much you can do with the classic Rails-style approach (server-side rendering of HTML templates with some vanilla Javascript, or perhaps jQuery, sprinkled on top). Once you get past a certain level of complexity I can understand the argument for having totally separate "frontend" and "backend" applications where the frontend is built with something like React and the latter renders nothing more than a JSON API. But why, why, why has the entire industry seemingly decided that the latter, complex approach is the default, perhaps even the only, way to build a web application? The last four companies I've worked for all used the "separate FE/BE" approach for every app, and at all four companies it was a terrible, unnecessary choice that added exponential amounts of complexity and slowed development to a crawl for no discernible benefit. Time and time again I'd get frustrated because the most simple, basic features would take ridiculously long to finish, be a nightmare to test, and be full of infuriating little subtleties and footguns that made the implementation fragile as an eggshell. Even something as simple as adding a <form> would take ten times longer than I knew it would have taken me in Phoenix or Rails. And yet when I try to explain that I don't think we need the "separate FE/BE" approach for the task at hand, people look at me like I've suggested we don't need electricity. It's all they've ever known and they can't imagine there might be a better way, or at least one that isn't so agonisingly, pointlessly complex. What's happened to the industry? Why has web development become like this?
- epiphonium 4y ago
  Side note, but just wondering what you think Rails's flaws are? What did you got sick of?
  - arrowsmith 4y ago
johnteller 4y ago
I was interviewed for a job a few days back and I was told that these heavy JavaScript libraries are the future of the web. I'm still confused. Either my country is just behind or what you read on hackernews is not reflective of the real world.
- fredrikholm 4y ago
  We aren't a homogeneous group that all have identical perspectives on things.
- darkhorse13 4y ago
  Or they have invested so much into some JS "framework" (most likely React) that they are heavily biased to get this to work properly. Same thing happened at the previous place I worked at.
- fuzzy2 4y ago
  > hackernews is not reflective of the real world. Say it isn’t so! :-D Just as an example: When was the last time you read about Angular on the HN frontpage? Basically last decade. Does that mean nobody uses Angular? Hell no. It is extremly widely used by big-ass corps. It’s just that their devs generally aren’t in the HN crowd. What companies do, what their support cycles are and how conservative their tech leaders are is an extremely heavy influence on the programming languages, frameworks and libraries they will use. You can research in advance and adapt your expectations.
  - yurishimo 4y ago
    Can you name some companies that are actively investing in Angular right now besides Google? It feels like React has taken over for many large businesses (non-tech focused) because it's "easier" to hire React devs. I used to work for a company where our manager (a few steps below CTO) was pushing for us to migrate to React from Vue so they could hire more people to come in and help with feature development. We pushed back and afaik the team is still using Vue today.
    - 4y ago
eximius 4y ago
Yeesh, I just want some web components, okay? (But not Web Components, those... Those are not good.)
- hokumguru 4y ago
  You might be surprised with how far custom elements have come. Lit and even Vue work astonishingly well
butz 4y ago
So, is Angular a framework then?

119 points by hejsna 4y ago

This is really great, and I'm really happy people are finally waking up to this. I've stuck with Django through all of this and never looked back. Nowadays with stuff like HTMX, things have never been better! Could we do this for CSS-in-JS next please? With React 18 making a strong push for compiled CSS, we have libraries now that let you write CSS (compiled) using Typescript. This is also absolutely crazy to me because we COULD BE JUST WRITING CSS instead (especially with variable support).

di4na 4y ago
I have a whole piece coming down the pipeline on this. I think a huge reason the js crowd got away with the "better DX" spiel is because CSS got left on the side. So doing it CSS-in-JS allowed to paper over the CSS painpoint for componentisation and composition. If you look at it this way, Tailwind make sense. Because what it gives you is mixins and variable. Just... Mixins in html `class`
cutler 4y ago
CSS has been mangled so many different ways, including the loathsome Tailwind, that I can't imagine what a newb web dev has to plough through these days. Some of us with longer memories were overjoyed to see browsers finally adopting standards after the erosion of Microsoft's reign but now it appears we're intent on destroying the value of what we waited 15 years for. Fer Kreissakes just write raw, unadulterated CSS and enjoy your freedom from the CSS hacks that were unavoidable back in the late 90s/early 2000s.
- beezlewax 4y ago
  Refreshing to see someone else who hates Tailwind. It's a nightmare.
  - cutler 4y ago
    The worst Tailwind I've seen is HTML littered with a, a:hover etc. declarations on every hyperlink. OK, you can create a global Tailwind stylesheet in your config but doesn't that defeat Tailwind's purpose?
    - brycewray 4y ago
      According to Adam Wathan himself in 2020, yes, it does: https://twitter.com/adamwathan/status/1226511611592085504 https://twitter.com/adamwathan/status/1226511611592085504
      - cutler 4y ago
        Oh, and that's discounting responsive breakpoints. So if you have 3 of those that can be 3 lots of a, a:hover etc. for every hyperlink. You couldn't make this up.
  - earthling8118 4y ago
    From what I can tell, this is a very common take. Especially on this site.
  - naasking 4y ago
    Haha, I love Tailwind and Tachyons! Writing CSS is still a PITA.
  - pydry 4y ago
    What do you prefer & why? As a somewhat outsider to CSS I look at tailwind and don't feel excited but I do wonder if thats as good as it gets.
    - cutler 4y ago
      I prefer CSS. We even have browser support for CSS variables now so what else do you need? Tailwind wipes out half of the features of CSS and replaces them with mindless inline repetition and bloat all in the name of convenience. I call it inconvenience and refuse to work on Tailwind projects.
Kiro 4y ago
Wow, I truly hope you are wrong. Non-scoped CSS where you have to come up with names for everything and that doesn't live right next to the markup in the same file as the component is the worst. The whole cascading part is also something I hope I never have to deal with again with conflicting styles being inherited and overridden all over the place. Just let me isolate everything and let me freely copy a component file with all styling included without relying on any global CSS.
- jstummbillig 4y ago
  What do you do to keep your inter component styling in sync?
  - darkhorse13 4y ago
    In my experience, this is usually solved with more TS/JS abstractions, something like global theming. Often they are hacky and poorly implemented, and always they are leaky.

KrugerDunnings 4y ago

I dislike frameworks for the same reason most of their proponents like frameworks, you can not expect to out-compete all the smart people working together on a common goal. Frameworks are bad at cultivating off-colour ideas, they tend to have a well curated API but are often stuck with a singular architecture. Sometimes the solution is to be found in some lateral dimension. One such example is PostREST, it does away with 80% of API boilerplate by inferring the API from the database schema using functional programming magic. You sort of have to become a Postgresql wizard to get everything out of it, but I feel that this knowledge is somehow more valuable than yet another backend framework.

mattgreenrocks 4y ago
Mediocrity enshrined as a process that gets elevated to best practice. And then you get yelled at if you try to improve on it, because it is a best practice. :)
- revscat 4y ago
  You just described my last employer to a T, and all because of ego. They kept solving problems that the framework they used already had solutions for. You were actively discouraged from coming up with any different solutions, because the VP of development was stupid and didn’t want anybody changing the patterns he used when they started the company. This included things like “using base classes or modules”, any third party libraries, code linters, database views, and many others. It was a huge waste of YC money, but the money kept pouring in.

revskill 4y ago

"Concatenates text and fires it off to the browser in a straightforward and predictable way." What ? It's in 2023, you don't want to concanate text ?

ziftface 4y ago
Everything concatenates text before render, including react. I don't think he was implying you have to do it manually.
mst 4y ago
That would rule out almost all server side templating systems, and most non-JSX client side ones (svelte, vue and angular all involve it to some extent) so I don't think that's quite right. I think maybe you've misread the author talking about the fact that most server side templating systems are fundamentally fancy ways to concatenate text as meaning writing the literal text concatenation yourself without having a library do it for you?

nickjj 4y ago

I like using `rails middleware` as an example because it's true, tons of things in that list are important. A good example of this is: Rack::MethodOverride Try making your non-JS server rendered view functions and HTML form submissions handle PUT, PATCH and DELETE. Depending on which lightweight alternative to Rails you're using this can become very tricky and you end up spending an entire day of Googling and maybe finding a questionable solution instead of having that available without thinking about it.

christophilus 4y ago
Unless I’m misunderstanding you, this is trivial in every stack I’ve used (.NET, Node, Rails, and Go). I can’t imagine why this would be difficult.
- nickjj 4y ago
  > Unless I’m misunderstanding you, this is trivial in every stack I’ve used (.NET, Node, Rails, and Go). I can’t imagine why this would be difficult. It's trivial in Rails because the middleware mentioned handles it. Forms only allow GET and POST if you submit it from a browser without JavaScript. That means you need to do things like introduce a hidden form field such as _method with the real method you want to use such as PATCH and then your framework's middleware level needs to understand how to translate that to call the correct function to handle the request. There's all sorts of edge cases around dealing with files and detecting if the request needs to be translated, etc.. With Flask this is a huge clusterfuck, https://blog.carsonevans.ca/2020/07/06/request-method-spoofing-in-flask/ https://blog.carsonevans.ca/2020/07/06/request-method-spoofi... has a breakdown on how it's anything but trivial. Sure there's https://flask.palletsprojects.com/en/2.2.x/patterns/methodoverrides/ https://flask.palletsprojects.com/en/2.2.x/patterns/methodov... but this involves setting a header which implies it's submit through JavaScript or another service over an API but in our case we want to submit it through a browser without using JavaScript.

imetatroll 4y ago

And good old Johan wrote many an app, rode off into the sunset victorious and left the job of maintaining his third party soup to some poor soul.

sodapopcan 4y ago
This made me lol and maybe I misunderstood but, what? Only once in my career I've come in on a fairly mature project that was, for the most part, done The Rails Way (TM). The code did its boring job quite well and every new place I looked I was able to understand and find things very quickly. On the flipside, people can definitely lean too much into a framework in cases where it doesn't work and leave a mess, so it it's definitely a fine balance of knowing when to break from convention. But I have a hard time sympathizing with people who use a framework and break a bunch of its conventions for no other reason because they think they know better (ie, without even trying to make it work). Even if they are among the rare breed who write good documentation, a lot of frameworks out there have really good documentation I've already read. We're just making web apps here, people.
frupert52 4y ago
Don’t worry he hasn’t gone too far he’s just in that studio apartment on the end of your street

KronisLV 4y ago

> So half of this blog post has actually been sitting on my drive for a couple of months because I’ve had a good long sad about the distressingly low bar we’ve set for something to bill itself as a Framework. I suppose this is partly because we’ve never really agreed about what constitutes one, and spoiler alert I don’t have a proper working definition either. But let’s get this out of the way first: React is not a framework. I never got why people care about the difference between a library and framework and try to categorize these offerings, especially when we don't even have meaningful definitions. The way I've seen it, you're usually going to have one front end "base thing" and build everything around it - be it Vue, or React, or Angular, or Svelte, or jQuery, or Next.js, or Nuxt, or JSF, or Vaadin, or Laravel's Blade templates, or the Rails equivalent etc. In some cases, it will try to provide everything out of the box, in other cases you're going to integrate a bunch of other stuff to do what you want, but you're rarely (at least in my experience) going to have something like React combined with Vue, or Vue with Svelte in the same site, which is sometimes touted as one of the advantages of libraries. I think I can recall one micro frontend project in my past like that. Furthermore, I've seen very few cases where integrated libraries are ever swapped out for something else once there's lots of code written against them, so they get coupled with the rest of the codebase regardless (unless you're really good at establishing boundaries/abstractions), so that's another supposed advantage that doesn't always pan out. And even when you use most of the frameworks out there, you still need to think about UI components and such, of which there are many libraries to integrate with your framework, so you still need additional bits introduced. It's almost like saying "Next.js acts 75% like a framework, whereas React only provides 25% of what you'd need for a full batteries included experience and therefore will mostly be treated as a library on its own." Silly way of framing it, I'll admit, but the end result will most likely be the same - one big repo of front end code (possibly a sub-folder), regardless of how many packages it's made up of. Just pick a group of solutions that fit your architecture of choice: Laravel, Rails and Django front end offerings are all good for SSR, whereas for SPAs just pick things depending on how much of an integrated experience you want, anything from Nuxt to barebones Vue, with libraries imported based on needs. Personally, I like the benefits of SSR (how integrated development can feel, easy to reason about), but I dislike the coupling and how you eventually will need to upgrade "the entire thing", which might be a big rewrite (e.g. moving from Spring to Spring Boot, or upgrading Rails/Laravel projects across major versions). I like the ability to throw away and replace SPAs if the need presents itself (AngularJS, anyone?) and the clear decoupling thanks to the API (running the old and new thing side by side is nice for dev). Oh, also SPAs lend themselves nicely for build parallelization, but have the downside of two deployment units (e.g. separate front end and back end containers/packages). Solutions that give you most of what you'll need are great, but only for as long as you don't have to fight against them due to needing to do something different.

ChrisMarshallNY 4y ago

I enjoyed that read! Johan is a great writer. I've written frameworks, libraries, SDKs, APIs, and drivers. Most are not frameworks. Frameworks are a lot of work to write and maintain. The most painful part of writing a framework, is the "rubber meets the road" part, where I suddenly realize that all that TLC I put into developing Guiding Principles, Mental Models, Basic Philosophies, etc. ad nauseam, were for shit, because no one is using my marvelous tool, the way I expect[0], and no one is oohing and ahhing over my masterful implementation. That ends up as a huge smorgasbord, serving a lot of Crow, Egg On Face, and Humble Pie. [0] https://www.theonion.com/bantu-tribesman-uses-ibm-global-uplink-network-modem-to-1819563905 https://www.theonion.com/bantu-tribesman-uses-ibm-global-upl...

howaboutnope 4y ago

A really, really good podcast I listened to recently: https://changelog.com/news/web-developments-lost-decade-LWao https://changelog.com/news/web-developments-lost-decade-LWao > Amal sits down for a one-on-one with Alex Russell, Microsoft Partner on the Edge team, and former Web Standards Tech Lead for Chrome, whose recent post, The Market for Lemons, stirred up a BIG conversation in the web development community. > Have we really lost a decade in potential progress? What happened? Where do we go from here?

mattgreenrocks 4y ago

Rails is probably the best framework still. But it still feels too low-level. I don’t want to care about the mountains of Web gunk there are: JSON serialization, HTTP methods, cookies, etc. Lack of static typing really hurts the maintenance story, too. I really just want to write business logic, wire that up to endpoints in a nice DSL, and move on. Most web frameworks seem to be obsessed with the web platform to the point they feel more like glorified macros, leaking its web gunk everywhere.

arrowsmith 4y ago
Cough phoenixframework.org cough
- mattgreenrocks 4y ago
  It is definitely closest to what I want. I need to give it an honest try.
ZephyrBlu 4y ago
There is quite a lot of inherent complexity of web as a platform. If frameworks were any more abstracted they would be too brittle for a lot of use cases. Btw, use Sorbet for Ruby static typing. It's very ergonomic.
- yoran 4y ago
  We adopted Sorbet for our codebase a couple of months ago, and I couldn't be happier with that choice. Sure, it's not as powerful as Typescript (e.g. no way to specify a union of constants like `type Result = 'ok' | 'error'`), but it's worth it just for the nil-check alone. And it's great for documenting too. It's easy to forget what type a method expects for its parameters.
Jgrubb 4y ago
Yes, but - if you don't understand how the web works and that it's made of HTTP and JSON and databases, you're probably going to find yourself trying to solve a problem you don't understand very quickly. I've always wanted to build a nice chair or cabinet, but I don't have the tools or the experience. It's not the tool's fault.

arrowsmith 4y ago

This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA? I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million years with Rails than five minutes with most of the React SPA monstrosities I've had to work with recently. I get it: if you want to build a super-complicated, dynamic front-end, there's only so much you can do with the classic Rails-style approach (server-side rendering of HTML templates with some vanilla Javascript, or perhaps jQuery, sprinkled on top). Once you get past a certain level of complexity I can understand the argument for having totally separate "frontend" and "backend" applications where the frontend is built with something like React and the latter renders nothing more than a JSON API. But why, why, why has the entire industry seemingly decided that the latter, complex approach is the default, perhaps even the only, way to build a web application? The last four companies I've worked for all used the "separate FE/BE" approach for every app, and at all four companies it was a terrible, unnecessary choice that added exponential amounts of complexity and slowed development to a crawl for no discernible benefit. Time and time again I'd get frustrated because the most simple, basic features would take ridiculously long to finish, be a nightmare to test, and be full of infuriating little subtleties and footguns that made the implementation fragile as an eggshell. Even something as simple as adding a <form> would take ten times longer than I knew it would have taken me in Phoenix or Rails. And yet when I try to explain that I don't think we need the "separate FE/BE" approach for the task at hand, people look at me like I've suggested we don't need electricity. It's all they've ever known and they can't imagine there might be a better way, or at least one that isn't so agonisingly, pointlessly complex. What's happened to the industry? Why has web development become like this?

epiphonium 4y ago
Side note, but just wondering what you think Rails's flaws are? What did you got sick of?
- arrowsmith 4y ago

johnteller 4y ago

I was interviewed for a job a few days back and I was told that these heavy JavaScript libraries are the future of the web. I'm still confused. Either my country is just behind or what you read on hackernews is not reflective of the real world.

fredrikholm 4y ago
We aren't a homogeneous group that all have identical perspectives on things.
darkhorse13 4y ago
Or they have invested so much into some JS "framework" (most likely React) that they are heavily biased to get this to work properly. Same thing happened at the previous place I worked at.
fuzzy2 4y ago
> hackernews is not reflective of the real world. Say it isn’t so! :-D Just as an example: When was the last time you read about Angular on the HN frontpage? Basically last decade. Does that mean nobody uses Angular? Hell no. It is extremly widely used by big-ass corps. It’s just that their devs generally aren’t in the HN crowd. What companies do, what their support cycles are and how conservative their tech leaders are is an extremely heavy influence on the programming languages, frameworks and libraries they will use. You can research in advance and adapt your expectations.
- yurishimo 4y ago
  Can you name some companies that are actively investing in Angular right now besides Google? It feels like React has taken over for many large businesses (non-tech focused) because it's "easier" to hire React devs. I used to work for a company where our manager (a few steps below CTO) was pushing for us to migrate to React from Vue so they could hire more people to come in and help with feature development. We pushed back and afaik the team is still using Vue today.
  - 4y ago

eximius 4y ago

Yeesh, I just want some web components, okay? (But not Web Components, those... Those are not good.)

hokumguru 4y ago
You might be surprised with how far custom elements have come. Lit and even Vue work astonishingly well

butz 4y ago

So, is Angular a framework then?