6 ms·

How many other web frameworks with support for "automatic code splitting, routing, hot code reloading and universal (server-side and client-side) rendering" do

How many other web frameworks with support for "automatic code splitting, routing, hot code reloading and universal (server-side and client-side) rendering" do you know?

megous 10y ago
All sound like solutions to self-created problems.
- 0x142857 10y ago
  programming itself is a problem.
- watty 10y ago
  There are tasks that can be completed quicker with web frameworks and tasks that can be completed quicker without them. They aren't a solution for every task. I'm not sure why people struggle so much and fight abstractions so much but I guess that's a sign a techie is getting "old".
  - megous 10y ago
    Struggle and fight abstractions? Some abstractions cause more trouble than they solve, and then create solutions to their own problems on top. That's the point. Older techie might have seen more abstractions, and choose more wisely the lesser complicated one for the job.
  - pg314 10y ago
    > a sign a techie is getting "old". Some of those "older" techies have gotten a wisdom that only comes with experience.
  - K0SM0S 10y ago
    This talk is incredible food for thought: On the spectrum of abstraction by Cheng Lou (react-europe 2016) [1] If you've read some of the classics, such as Structure and Interpretation of Computer Programs (1979, Gerald Jay Sussman and Hal Abelson) [2], this talk is a really interesting look at the state of affairs on abstraction circa 2016. [1]: https://youtu.be/mVVNJKv9esE https://youtu.be/mVVNJKv9esE [2]: https://mitpress.mit.edu/sicp/full-text/book/book.html https://mitpress.mit.edu/sicp/full-text/book/book.html
  - coldtea 10y ago
    >I'm not sure why people struggle so much and fight abstractions so much but I guess that's a sign a techie is getting "old". Yeah, it's a sign they are older, and have seen the same shit play again and again, and starry eyed newcomers fall for every new fad with shit-eating grins...
- akanet 10y ago
  I don't think this is a good HN comment. If you disagree that these are useful attributes for a platform to provide, please explain so that we can reason about your position. Condescending to people's earnest work isn't a virtue we should promote.
  - matt4077 10y ago
    It's a pretty good argument: the three features mentioned as advantages over static or server-rendered html only exist to mitigate problems created by the SPA structure itself. It's like touting "fast battery charging" as an advantage of a Tesla over a Porsche.
    - nilliams 10y ago
      I don't agree, but let's break this down, comparing to a traditional app in Rails/Django that renders HTML server-side, then progressively enhances with a sprinkling of JS. > automatic code splitting By code-splitting we implicitly mean we're also managing dependencies (e.g. via require() or import statements). In a traditional server-rendered-app, you can achieve something similar to code-splitting by manually breaking up your script tags across pages as needed, but you lose dependency management. With code-splitting you get both, and your bundles are going to be better optimised than if you hand-picked script-tags (at least that's the promise of automatic code-splitting, and it'll only be enhanced as 'tree shaking' techniques mature). > routing Really, this should say 'filesystem-based routing', which you don't get for free in rails/django afaik. Granted you get it in old-school PHP, which I think Next is open about wanting to copy the 'ease' of. I think that's cool. > hot code reloading You don't get that in server-rendered frameworks. It's a hugely pleasurable boon to development to not lose all your page state when you just changed a bit of CSS or JS that shouldn't affect state. It even won't destroy CSS or HTML text-content changes I made with the Chrome devtools, which would get lost if I used something like 'live reload' to reload the page with a server-rendered framework. > universal (server-side and client-side) rendering It's not the server-side rendering that's the advantage, because like you say ... we already had that. It's the fact it's both. The initial load is server-side, which is a big win for mobile devices especially (remember when Twitter switched from an SPA back to server-side-rendering to improve 'time-to-first-tweet'). But every subsequent page load is done by requesting the minimal data needed and rendering client-side, which is faster than loading a full page from the server.
- mixedCase 10y ago
  Automatic code splitting, routing and client-side rendering are necessities to provide websites that don't require a full screen repaint and server request to change small stuff. When well-executed, it provides a better experience to the average user. Hot code reloading is a way to test changes without dropping current state, something that's extremely handy during development to avoid wasting time replicating said state every time. Does the tooling suck donkey ass? Yes. Does it have serious tradeoffs to consider? Yes. But in many cases it's the right thing to do to have a higher-quality product.
  - empthought 10y ago
    > Automatic code splitting, routing and client-side rendering are necessities to provide websites that don't require a full screen repaint and server request to change small stuff. This isn't true. Have a look at how the GitHub UI is implemented. [1] There's even a name for this approach. [2] [1] http://pjax.herokuapp.com http://pjax.herokuapp.com [2] http://roca-style.org http://roca-style.org
    - NoGravitas 10y ago
      Pjax/hijax is absolutely the right way to go for content-focused sites.
  - Touche 10y ago
    > Automatic code splitting, routing and client-side rendering are necessities to provide websites that don't require a full screen repaint and server request to change small stuff. Client-side routing is rarely used to change small stuff. It's usually used to replicate an entire page transition. > When well-executed, it provides a better experience to the average user. It's rarely well-executed. Client-side routing means you have to replicate every feature of browser routing, and most frameworks get it wrong. Numerous issues like not supporting cmd/ctrl+click to open in a new tab, ext, are common. > Hot code reloading is a way to test changes without dropping current state, something that's extremely handy during development to avoid wasting time replicating said state every time. Like the GP said, this is a self-created problem. Separate development pages to test out small parts of an application is how you avoid replicating state. But today's web development environment is so wrapped up in tooling and build complexity that creating a new page to test out a small part of the application is actually really hard to do.

How many other web frameworks with support for "automatic code splitting, routing, hot code reloading and universal (server-side and client-side) rendering" do you know?

megous 10y ago

All sound like solutions to self-created problems.

0x142857 10y ago
programming itself is a problem.
watty 10y ago
There are tasks that can be completed quicker with web frameworks and tasks that can be completed quicker without them. They aren't a solution for every task. I'm not sure why people struggle so much and fight abstractions so much but I guess that's a sign a techie is getting "old".
- megous 10y ago
  Struggle and fight abstractions? Some abstractions cause more trouble than they solve, and then create solutions to their own problems on top. That's the point. Older techie might have seen more abstractions, and choose more wisely the lesser complicated one for the job.
- pg314 10y ago
  > a sign a techie is getting "old". Some of those "older" techies have gotten a wisdom that only comes with experience.
- K0SM0S 10y ago
  This talk is incredible food for thought: On the spectrum of abstraction by Cheng Lou (react-europe 2016) [1] If you've read some of the classics, such as Structure and Interpretation of Computer Programs (1979, Gerald Jay Sussman and Hal Abelson) [2], this talk is a really interesting look at the state of affairs on abstraction circa 2016. [1]: https://youtu.be/mVVNJKv9esE https://youtu.be/mVVNJKv9esE [2]: https://mitpress.mit.edu/sicp/full-text/book/book.html https://mitpress.mit.edu/sicp/full-text/book/book.html
- coldtea 10y ago
  >I'm not sure why people struggle so much and fight abstractions so much but I guess that's a sign a techie is getting "old". Yeah, it's a sign they are older, and have seen the same shit play again and again, and starry eyed newcomers fall for every new fad with shit-eating grins...
akanet 10y ago
I don't think this is a good HN comment. If you disagree that these are useful attributes for a platform to provide, please explain so that we can reason about your position. Condescending to people's earnest work isn't a virtue we should promote.
- matt4077 10y ago
  It's a pretty good argument: the three features mentioned as advantages over static or server-rendered html only exist to mitigate problems created by the SPA structure itself. It's like touting "fast battery charging" as an advantage of a Tesla over a Porsche.
  - nilliams 10y ago
    I don't agree, but let's break this down, comparing to a traditional app in Rails/Django that renders HTML server-side, then progressively enhances with a sprinkling of JS. > automatic code splitting By code-splitting we implicitly mean we're also managing dependencies (e.g. via require() or import statements). In a traditional server-rendered-app, you can achieve something similar to code-splitting by manually breaking up your script tags across pages as needed, but you lose dependency management. With code-splitting you get both, and your bundles are going to be better optimised than if you hand-picked script-tags (at least that's the promise of automatic code-splitting, and it'll only be enhanced as 'tree shaking' techniques mature). > routing Really, this should say 'filesystem-based routing', which you don't get for free in rails/django afaik. Granted you get it in old-school PHP, which I think Next is open about wanting to copy the 'ease' of. I think that's cool. > hot code reloading You don't get that in server-rendered frameworks. It's a hugely pleasurable boon to development to not lose all your page state when you just changed a bit of CSS or JS that shouldn't affect state. It even won't destroy CSS or HTML text-content changes I made with the Chrome devtools, which would get lost if I used something like 'live reload' to reload the page with a server-rendered framework. > universal (server-side and client-side) rendering It's not the server-side rendering that's the advantage, because like you say ... we already had that. It's the fact it's both. The initial load is server-side, which is a big win for mobile devices especially (remember when Twitter switched from an SPA back to server-side-rendering to improve 'time-to-first-tweet'). But every subsequent page load is done by requesting the minimal data needed and rendering client-side, which is faster than loading a full page from the server.
mixedCase 10y ago
Automatic code splitting, routing and client-side rendering are necessities to provide websites that don't require a full screen repaint and server request to change small stuff. When well-executed, it provides a better experience to the average user. Hot code reloading is a way to test changes without dropping current state, something that's extremely handy during development to avoid wasting time replicating said state every time. Does the tooling suck donkey ass? Yes. Does it have serious tradeoffs to consider? Yes. But in many cases it's the right thing to do to have a higher-quality product.
- empthought 10y ago
  > Automatic code splitting, routing and client-side rendering are necessities to provide websites that don't require a full screen repaint and server request to change small stuff. This isn't true. Have a look at how the GitHub UI is implemented. [1] There's even a name for this approach. [2] [1] http://pjax.herokuapp.com http://pjax.herokuapp.com [2] http://roca-style.org http://roca-style.org
  - NoGravitas 10y ago
    Pjax/hijax is absolutely the right way to go for content-focused sites.
- Touche 10y ago
  > Automatic code splitting, routing and client-side rendering are necessities to provide websites that don't require a full screen repaint and server request to change small stuff. Client-side routing is rarely used to change small stuff. It's usually used to replicate an entire page transition. > When well-executed, it provides a better experience to the average user. It's rarely well-executed. Client-side routing means you have to replicate every feature of browser routing, and most frameworks get it wrong. Numerous issues like not supporting cmd/ctrl+click to open in a new tab, ext, are common. > Hot code reloading is a way to test changes without dropping current state, something that's extremely handy during development to avoid wasting time replicating said state every time. Like the GP said, this is a self-created problem. Separate development pages to test out small parts of an application is how you avoid replicating state. But today's web development environment is so wrapped up in tooling and build complexity that creating a new page to test out a small part of the application is actually really hard to do.