4 ms·

Compilers are a common project for university CS students. That doesn't mean GCC is overly complicated. There's a huge difference between making a simple proto

Compilers are a common project for university CS students. That doesn't mean GCC is overly complicated. There's a huge difference between making a simple prototype of a concept and making an actual production app that fulfills a myriad of requirements that help you run a successful business.

troad 2y ago
Agreed, but not even a battle-hardened production compiler requires a particle accelerator or an optical fibre cable to the Webb space telescope. Similarly, a shopping site or text-based social media does not require a soup of web frameworks. It just doesn't - it's not a solution commensurate with the scale of the problem. Complexity is expense, and this doesn't remove complexity, it introduces it, reams of it, and totally needlessly. No one has ever sat in front of a shopping site and thought - 'you know what this needs? A dozen extra mb of JavaScript that introduce no actual new customer-facing features, but that put a noticeable delay in every interaction, break the user's scrollbars and screen readers, and dramatically complicate maintenance.'
- jakubmazanec 2y ago
  > soup of web frameworks What a beautiful Straw man. What are these social media sites with more than one framework? > ever sat in front of a shopping site and thought But do you know what actually think? That they want to have products filtering, they want to have more products loaded with a simple button click, they want to add reviews and comments, they want to see product photos (or maybe even 3D models) - all fast without unnecessary page reloads. It's your problem you can't build it without breaking user experience.
  - troad 2y ago
    All of the things you list can be achieved with minimal or no JavaScript, and many are completely trivial (filtering? adding reviews and comments?). In general, if a prospective employee told me they needed React to implement website comments, I would not walk away with a very high opinion of that dev's abilities.
    - jakubmazanec 2y ago
      They cannot be achieved without JavaScript and still be fast (good luck having product filtering with full-page reloads, your users will flee) - that was the whole point. And I didn't say you have to use React specifically. But without framework you in the end just create a custom one (as was said multiple times by other commenters).
      - troad 2y ago
        As I said, minimal to no JS. Something like HTMX or Turbo* is more than sufficient to solve this fictitious full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons). Ask the average person whether websites have gotten better or worse since 2014. That's their opinion of SPAs. > But without framework you in the end just create a custom one Only if you've only ever written React-style webpages, and can't imagine any other way a website may work. Which, needless to say, would reflect a very limited experience of the web. * Or just a plain XMLHttpRequest call? Dynamic loading is exceedingly simple, and certainly doesn't require a convoluted web framework.
        jakubmazanec 2y ago
        But we're not talking about SPAs, we're talking about e-commerce websites. > full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons) I'm simply saying user wants performant websites. You're basically saying the same. Full-page reloads are, ceteris paribus, always slower than some JSON payload. And when you're saying to use HTMX, I then don't understand what you mean by "minimal to no JS". > Only if you've only ever written React-style webpages Again, I'm not saying anything about using React specifically. > convoluted web framework Yet another straw man.
        recursivedoubts 2y ago
        ceteris is rarely paribus: JSON-based APIs have to make a choice between being general purpose, in which case a web app written against them may end up chatty with multiple requests per page, or they end up application specific, in which case they can be churney and a bad general purpose API. I wrote an essay about this here: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ Also, producing JSON often involves reflection and can be more CPU intensive than straight templating (w/ fixed properly lookups) depending on your technology. Finally, the size delta between JSON and hypermedia is lower than most people think, particularly with compression: https://github.com/1cg/html-json-size-comparison https://github.com/1cg/html-json-size-comparison in most real world systems i expect data store access to be the dominant latency issue some people have had good success w/htmx from a performance perspective (2x+ speed, 1/2 memory consumption): https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ but of course it depends on your use case. I think htmx would be excellent for an e-commerce site, which is mostly text and images and relatively simple, coarse-grained user interactions.

troad 2y ago

Agreed, but not even a battle-hardened production compiler requires a particle accelerator or an optical fibre cable to the Webb space telescope. Similarly, a shopping site or text-based social media does not require a soup of web frameworks. It just doesn't - it's not a solution commensurate with the scale of the problem. Complexity is expense, and this doesn't remove complexity, it introduces it, reams of it, and totally needlessly. No one has ever sat in front of a shopping site and thought - 'you know what this needs? A dozen extra mb of JavaScript that introduce no actual new customer-facing features, but that put a noticeable delay in every interaction, break the user's scrollbars and screen readers, and dramatically complicate maintenance.'

jakubmazanec 2y ago
> soup of web frameworks What a beautiful Straw man. What are these social media sites with more than one framework? > ever sat in front of a shopping site and thought But do you know what actually think? That they want to have products filtering, they want to have more products loaded with a simple button click, they want to add reviews and comments, they want to see product photos (or maybe even 3D models) - all fast without unnecessary page reloads. It's your problem you can't build it without breaking user experience.
- troad 2y ago
  All of the things you list can be achieved with minimal or no JavaScript, and many are completely trivial (filtering? adding reviews and comments?). In general, if a prospective employee told me they needed React to implement website comments, I would not walk away with a very high opinion of that dev's abilities.
  - jakubmazanec 2y ago
    They cannot be achieved without JavaScript and still be fast (good luck having product filtering with full-page reloads, your users will flee) - that was the whole point. And I didn't say you have to use React specifically. But without framework you in the end just create a custom one (as was said multiple times by other commenters).
    - troad 2y ago
      As I said, minimal to no JS. Something like HTMX or Turbo* is more than sufficient to solve this fictitious full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons). Ask the average person whether websites have gotten better or worse since 2014. That's their opinion of SPAs. > But without framework you in the end just create a custom one Only if you've only ever written React-style webpages, and can't imagine any other way a website may work. Which, needless to say, would reflect a very limited experience of the web. * Or just a plain XMLHttpRequest call? Dynamic loading is exceedingly simple, and certainly doesn't require a convoluted web framework.
      - jakubmazanec 2y ago
        But we're not talking about SPAs, we're talking about e-commerce websites. > full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons) I'm simply saying user wants performant websites. You're basically saying the same. Full-page reloads are, ceteris paribus, always slower than some JSON payload. And when you're saying to use HTMX, I then don't understand what you mean by "minimal to no JS". > Only if you've only ever written React-style webpages Again, I'm not saying anything about using React specifically. > convoluted web framework Yet another straw man.
        recursivedoubts 2y ago
        ceteris is rarely paribus: JSON-based APIs have to make a choice between being general purpose, in which case a web app written against them may end up chatty with multiple requests per page, or they end up application specific, in which case they can be churney and a bad general purpose API. I wrote an essay about this here: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ Also, producing JSON often involves reflection and can be more CPU intensive than straight templating (w/ fixed properly lookups) depending on your technology. Finally, the size delta between JSON and hypermedia is lower than most people think, particularly with compression: https://github.com/1cg/html-json-size-comparison https://github.com/1cg/html-json-size-comparison in most real world systems i expect data store access to be the dominant latency issue some people have had good success w/htmx from a performance perspective (2x+ speed, 1/2 memory consumption): https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ but of course it depends on your use case. I think htmx would be excellent for an e-commerce site, which is mostly text and images and relatively simple, coarse-grained user interactions.