9 ms·

>Also since when is modernness more important than content? Design is just as important as content. Design in terms of how nice the site looks and design in te

>Also since when is modernness more important than content? Design is just as important as content. Design in terms of how nice the site looks and design in terms of ux and usability. If people ignore your site because it looks cheap then the content is pointless. Most users really expect SPAs, they don't expect having to reload the entire site to see new content. Then you get into usability and many react component libraries really work well with you there. Accessibility for the visually impaired is baked into the library and the popular libraries follow modern UI conventions.

ch4s3 5y ago
Things like Turbolinks, HotWire, LiveView, and similar html over the wire tools don't reload the whole page. LiveView(Elixir/Phoenix) and HotWire (Ruby/Rails) can update something as small as a single html tag attribute and if you want to, a lot of people sprinkle on something like Alpine for purely cosmetic changes in the UI. It's really quite amazing what you can do now with these HTML focused frameworks.
- friedman23 5y ago
  It might be better than I think, I just personally don't want to go back to writing html in custom templating languages. I don't have fond memories of that experience.
  - tomc1985 5y ago
    Funny you say that, I have the same feelings about putting arbitrary HTML in my JS with React. Seems like we've all collectively forgotten about separation of concerns? Give me templated HTML any day of the week please :)
    - friedman23 5y ago
      > separation of concerns I learned it and started developing this way taking separation of concerns as dogma and now I look back and wonder why we ever did it that way.
      - sodapopcan 5y ago
        The thing is that this was never "separation of concerns", it was always "separation of languages". There were cross cutting concerns across each language (CSS doing layout, styling, animations; JS doing business logic, animations, layout, styling; etc). Mixing your JS/Other Language/CSS/HTML into components is a separation of concerns that really matters: separation of business/application concerns. Having everything you need that works together to solve a problem in place is very powerful (not to mention convenient).
        tomc1985 5y ago
        The separation of languages is a natural byproduct of each language being specific to its domain. HTML does layout. CSS does styling. JS does frontend functionality. Server enforces business logic, controllers, and the data model. It's clean, clear-cut, easy for IDE's to parse, and everything is in its place. Dogma or not I still prefer everything in its place vs trying to watch my IDE twist itself in knots trying to figure out which language to use for a given context. To say nothing of all the little eccentricities in the JS engines' reimplemented parsers.
        friedman23 5y ago
        > HTML does layout. CSS does styling. JS does frontend functionality. Server enforces business logic, controllers, and the data model. In practice nothing works out like this. JS and HTML are tightly coupled, the frontend ends up needing to enforce business logic as well for usability reasons, etc. > trying to watch my IDE twist itself in knots trying to figure out which language to use for a given context This is not an actual issue.
        tomc1985 5y ago
        > In practice nothing works out like this. It does and can. Sorry your team sucks > This is not an actual issue. Yes, it is. Why would I bring it up if it wasn't?
    - ch4s3 5y ago
      With thins like LiveView, you're encouraged to have separate Heex files most of the time, and to keep them free of logic, other than the odd if statement.
  - ch4s3 5y ago
    ERB isn't my favorite, but stuff like Elixir/Phoenix's Heex look react like and are mostly just html. I use Phoenix/LiveView for an internal tool at work and dom updates are so fast that it looks like nothing happened sometimes. It's super easy to maintain too, there are well defined ways to handle state changes and the event api is well designed.
    - toqy 5y ago
      Phoenix/LiveView looks pretty great, hopefully things start to swing this way. I recently had to quickly add a front end feature that really should have been a separate web app to my main project at work (Vue SPA) to get ahead of some external audit. Another team hastily built the back end + rest api. There's no filtering / pagination / anything nice in the api, so we just get back 1000s of records and do it all on the front end. Found out prod deployment that it's used exclusively by contractors in India on very low power VDIs. So extremely bad performance. Doing it literally any other way would have probably been better, but something like LiveView would have been great for the interactivity. Although I don't want to go back to a world without static types.
      - ch4s3 5y ago
        I don't really find myself missing static types with LiveView, I just write some Ecto Changesets and anything invalid gets bounced back to the browser with an error. That plus some DB constraints and some structural types in function signatures gives you a ton of safety. I basically never see any errors coming from the CRUD stuff, only the more complicated pieces that touch old parts of the app.

ch4s3 5y ago

Things like Turbolinks, HotWire, LiveView, and similar html over the wire tools don't reload the whole page. LiveView(Elixir/Phoenix) and HotWire (Ruby/Rails) can update something as small as a single html tag attribute and if you want to, a lot of people sprinkle on something like Alpine for purely cosmetic changes in the UI. It's really quite amazing what you can do now with these HTML focused frameworks.

friedman23 5y ago
It might be better than I think, I just personally don't want to go back to writing html in custom templating languages. I don't have fond memories of that experience.
- tomc1985 5y ago
  Funny you say that, I have the same feelings about putting arbitrary HTML in my JS with React. Seems like we've all collectively forgotten about separation of concerns? Give me templated HTML any day of the week please :)
  - friedman23 5y ago
    > separation of concerns I learned it and started developing this way taking separation of concerns as dogma and now I look back and wonder why we ever did it that way.
    - sodapopcan 5y ago
      The thing is that this was never "separation of concerns", it was always "separation of languages". There were cross cutting concerns across each language (CSS doing layout, styling, animations; JS doing business logic, animations, layout, styling; etc). Mixing your JS/Other Language/CSS/HTML into components is a separation of concerns that really matters: separation of business/application concerns. Having everything you need that works together to solve a problem in place is very powerful (not to mention convenient).
      - tomc1985 5y ago
        The separation of languages is a natural byproduct of each language being specific to its domain. HTML does layout. CSS does styling. JS does frontend functionality. Server enforces business logic, controllers, and the data model. It's clean, clear-cut, easy for IDE's to parse, and everything is in its place. Dogma or not I still prefer everything in its place vs trying to watch my IDE twist itself in knots trying to figure out which language to use for a given context. To say nothing of all the little eccentricities in the JS engines' reimplemented parsers.
        friedman23 5y ago
        > HTML does layout. CSS does styling. JS does frontend functionality. Server enforces business logic, controllers, and the data model. In practice nothing works out like this. JS and HTML are tightly coupled, the frontend ends up needing to enforce business logic as well for usability reasons, etc. > trying to watch my IDE twist itself in knots trying to figure out which language to use for a given context This is not an actual issue.
        tomc1985 5y ago
        > In practice nothing works out like this. It does and can. Sorry your team sucks > This is not an actual issue. Yes, it is. Why would I bring it up if it wasn't?
  - ch4s3 5y ago
    With thins like LiveView, you're encouraged to have separate Heex files most of the time, and to keep them free of logic, other than the odd if statement.
- ch4s3 5y ago
  ERB isn't my favorite, but stuff like Elixir/Phoenix's Heex look react like and are mostly just html. I use Phoenix/LiveView for an internal tool at work and dom updates are so fast that it looks like nothing happened sometimes. It's super easy to maintain too, there are well defined ways to handle state changes and the event api is well designed.
  - toqy 5y ago
    Phoenix/LiveView looks pretty great, hopefully things start to swing this way. I recently had to quickly add a front end feature that really should have been a separate web app to my main project at work (Vue SPA) to get ahead of some external audit. Another team hastily built the back end + rest api. There's no filtering / pagination / anything nice in the api, so we just get back 1000s of records and do it all on the front end. Found out prod deployment that it's used exclusively by contractors in India on very low power VDIs. So extremely bad performance. Doing it literally any other way would have probably been better, but something like LiveView would have been great for the interactivity. Although I don't want to go back to a world without static types.
    - ch4s3 5y ago
      I don't really find myself missing static types with LiveView, I just write some Ecto Changesets and anything invalid gets bounced back to the browser with an error. That plus some DB constraints and some structural types in function signatures gives you a ton of safety. I basically never see any errors coming from the CRUD stuff, only the more complicated pieces that touch old parts of the app.