5 ms·

You'd be surprised what you can get out of nothing more than Rails + Turbolinks. As long as your site idea follows a "pages" analogy it is pretty much instantan

by tomc1985 5y ago

You'd be surprised what you can get out of nothing more than Rails + Turbolinks. As long as your site idea follows a "pages" analogy it is pretty much instantaneous. Anything more than that and you're trying to make an SPA > the output looks decidedly un-modern You could say that about anything. The output styles to how you style it. Also since when is modernness more important than content?

friedman23 5y ago
>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.
deleted 5y ago
[deleted]

friedman23 5y ago

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

deleted 5y ago

[deleted]