10 ms·

Sorry, I couldn't resist. Second and third paragraphs, with some minor editing: HTML is close to this ideal. If you haven't encountered it yet, I strongly reco

Sorry, I couldn't resist. Second and third paragraphs, with some minor editing: HTML is close to this ideal. If you haven't encountered it yet, I strongly recommend going through the tutorials at https://www.w3schools.com/html/ https://www.w3schools.com/html/. HTML introduced a brilliant idea: all the pages of your app are files in a your-project/pages directory, and each of those files is just an HTML page. Everything else flows from that breakthrough design decision. Finding the code responsible for a given page is easy, because you can just look at the filesystem rather than playing 'guess the component name'. Project structure bikeshedding is a thing of the past. And the combination of SSR (server-side rendering) and code-splitting — something the React Router team gave up on, declaring 'Godspeed those who attempt the server-rendered, code-split apps' — is trivial.

rich_harris 9y ago
If you don't mind reloading the entire page on every single navigation, and don't have any dynamic data or interactivity, this is indeed a very solid approach.
- RobertRoberts 9y ago
  But this is where the entire argument of "do first page load server side because it's faster" doesn't make any sense. Because then aren't you suggesting that after that, all the other pages can be slow? The worst sites I visit now are React.js like sites, instead of the page load being slow, _everything_ is slow. Ugh. I can't wait until web 3.0 and this silly balogna with the "make a browser with React and run it inside a browser" fades out... (note, Netflix _removed_ their js rendering from their home page cause it was slow)
  - scottmf 9y ago
    I feel like a lot of HN is stuck in 2010 and dislikes all of this new web tech because they don’t understand it. This comment is a prime example.
    - megaman22 9y ago
      Possibly a lot of HN has been around the block for a couple of decades at this point, and has seen this web dev stuff come full circle several times, and before that, the same ideas in desktop software. Computer science programs really need to introduce something like a "History of Computing Ideas" course as a mandatory element. Maybe we can get away from rehashing the same cycle of trends every five years and move onto some different wheels.
      - goatlover 9y ago
        Are they going to also teach that at bootcamps?
      - Danihan 9y ago
        I'm still waiting for my web framework in pure ASM idea to manifest.
      - OJFord 9y ago
        > Computer science programs really need to introduce something like a "History of Computing Ideas" course as a mandatory element. Isn't that the whole programme? In my final year I had a couple of more advanced courses in which we could just about get our heads around results published by the lecturer four years ago when we started the programme. Everything else is just working up to that, from Boole's ideas; through Turing's and von Neumann's.
        megaman22 9y ago
        You're looking at this from a more academic perspective than my comment implied. Really, it's the whole clusterf&*^ of software engineering being conflated with computer science, when they are really not the same thing in any way. There is a lot of practical implementation history that people are often woefully ignorant of, and it leads them to tread the same paths over and over and over. - Here are the core GNU command line utilities; make, sed, grep, etc. They are battle-tested, use them, don't rewrite them a dozen times in JavaScript - Here is the progression of version control tools that people have used over time, and some reasons why we've moved on from SourceSafe and rcs to Git. - Here's the history of how people have done databases, flat-file, vs sql vs nosql - etc, etc, etc.
  - rich_harris 9y ago
    Server-side rendering means you get a quick first load. Client-side rendering means subsequent navigations are quick, because there's less data to transfer (maybe a little bit of JSON, maybe nothing at all). Going back to the server for 100kb of HTML and reloading the entire page, as opposed to fetching 10kb of JSON and instantly updating it in place, is a very 2002 way of doing things!
    - RobertRoberts 9y ago
      >...because there's less data to transfer... The problem is that just the theory, reality if often times different. >Going back to the server for 100kb of HTML and reloading the entire page... This implies that 1) you don't go "back to the server" to load your bit of JSON. and 2) the JSON loaded doesn't require any extra templates, images or more JSON to be loaded. See the problem? It's all assumptions. Another thing, what about browser caching? I can see how the next page loads _only_ the html, as all the js, css and images were loaded already. I think you are falling for the exaggerated speed benefits from making a website with a JS framework. To be clear, I am talking about a web page, an HTML document, static content. Maybe that's where the confusion happens in discussions like this. (I said "sites", not "webapps" in my original comment) A history lesson, we did this with Flash years ago (no more page refreshes!), and everyone ultimately learned to hate it. Just because the flashy crap is spread over the entire "webapp/site" to every button, mouseover and click doesn't mean it's useful or better. (I think many devs think they need to build basic site features with big frameworks just to "stay modern".) Look at Youtube, it's slower now that they implemented their "webapp" experience, but the page doesn't "refresh", so that is somehow better... (is youtube really a webapp? Or a bunch of pages with videos on them?)
      - rich_harris 9y ago
        Ultimately, the proof is in the pudding. Which is faster, when you start navigating around? * https://news.ycombinator.com/item?id=16052558 https://news.ycombinator.com/item?id=16052558 * https://hn.svelte.technology/item/16052558 https://hn.svelte.technology/item/16052558 Bear in mind that HN itself has a huge advantage over HN clones, yet — for me at least, sitting here — the Sapper version is significantly snappier.
- taneq 9y ago
  When the entire page is 50kb of compressed text and some cached images, I don't mind reloading it on every single navigation (at which point dynamically generated HTML is more than adequate for dynamic data). It's only when devs insist on shoveling 5mb of compressed JS libraries into it that it becomes an issue.
- purerandomness 9y ago
  If you get <200ms Time To Interactive, working middle mouse click and back buttons, in which scenario wouldn't you want that?
unclebucknasty 9y ago
>HTML is close to this ideal HTML is anything but ideal. In fact, it's the core of the problem where Web applications are concerned. HTML and its kin (particularly CSS) were designed for content-oriented Web pages, not Web applications. Continuing to devise Web-app frameworks that are predicated upon developers wrangling HTML for controls and CSS for layout will lead to more iterations of frustration; only to perhaps slightly lesser degrees. It doesn't matter if you write JS that renders it or templates. It's the same problem. What's needed is a component-framework with proper tooling (including IDEs) for layout and design. We've solved this with Swing and even Visual Basic. So, for the life of me, I still can't figure out why we haven't moved in this direction full-on for Web frameworks. If the issue is that HTML and CSS are standards with broad support, then I concur: but compose the app via a proper GUI and let the tooling generate the HTML/CSS. It's odd: we use Webpack, Browserify, etc. for full on Web-app builds, along with various cross-compilers for JS. But, at the end of the day, we're still writing HTML-based templates (or JS) and CSS. This is generally an unpopular view on HN. But, I can nearly guarantee that the next truly meaningful advancement in frameworks will be via a component-oriented approach that abandons direct manipulation of Web standards like HTML/CSS altogether.
- felipeccastro 9y ago
  I agree with your view, but I suspect it hasn’t happened yet for a couple of reasons: - every time it was attempted, the generated html/css was terrible (think old ASP Net for example), and maintenance hard. Abstractions only work when they are not leaky - designers, devs and users in general expect to have custom design for everything, rather than standard controls. Something to do with “have a unique brand and not look like everyone’s else app”.
  - unclebucknasty 9y ago
    >the generated html/css was terrible (think old ASP Net for example) We've come a long way in tooling, libraries, and in the underlying standards. Technologies like ASP also pre-dated SPAs and were targeted for server-side development; hence make for a poor analogy. Swing would be a more apt comparison, and even Visual Basic. In general, poor execution in the past is no reason to drop the objective. We've tolerated plenty of bad HTML-based frameworks and years of CSS-quirkiness, yet we keep plugging away at it. >and maintenance hard But the actual objective is that you wouldn't hand-maintain the generated code. We're currently so bound to HTML-thinking that it's hard to embrace that notion. >designers, devs and users in general expect to have custom design for everything I've heard this. Interestingly, though, we look to tools like Bootstrap and design-motifs like Material, etc., which emphasize uniformity. Also, there's no reason branding can't be applied without directly manipulated CSS. A good component-based library would allow for that and would also allow for the construction of extensible custom components.

rich_harris 9y ago

If you don't mind reloading the entire page on every single navigation, and don't have any dynamic data or interactivity, this is indeed a very solid approach.

RobertRoberts 9y ago
But this is where the entire argument of "do first page load server side because it's faster" doesn't make any sense. Because then aren't you suggesting that after that, all the other pages can be slow? The worst sites I visit now are React.js like sites, instead of the page load being slow, _everything_ is slow. Ugh. I can't wait until web 3.0 and this silly balogna with the "make a browser with React and run it inside a browser" fades out... (note, Netflix _removed_ their js rendering from their home page cause it was slow)
- scottmf 9y ago
  I feel like a lot of HN is stuck in 2010 and dislikes all of this new web tech because they don’t understand it. This comment is a prime example.
  - megaman22 9y ago
    Possibly a lot of HN has been around the block for a couple of decades at this point, and has seen this web dev stuff come full circle several times, and before that, the same ideas in desktop software. Computer science programs really need to introduce something like a "History of Computing Ideas" course as a mandatory element. Maybe we can get away from rehashing the same cycle of trends every five years and move onto some different wheels.
    - goatlover 9y ago
      Are they going to also teach that at bootcamps?
    - Danihan 9y ago
      I'm still waiting for my web framework in pure ASM idea to manifest.
    - OJFord 9y ago
      > Computer science programs really need to introduce something like a "History of Computing Ideas" course as a mandatory element. Isn't that the whole programme? In my final year I had a couple of more advanced courses in which we could just about get our heads around results published by the lecturer four years ago when we started the programme. Everything else is just working up to that, from Boole's ideas; through Turing's and von Neumann's.
      - megaman22 9y ago
        You're looking at this from a more academic perspective than my comment implied. Really, it's the whole clusterf&*^ of software engineering being conflated with computer science, when they are really not the same thing in any way. There is a lot of practical implementation history that people are often woefully ignorant of, and it leads them to tread the same paths over and over and over. - Here are the core GNU command line utilities; make, sed, grep, etc. They are battle-tested, use them, don't rewrite them a dozen times in JavaScript - Here is the progression of version control tools that people have used over time, and some reasons why we've moved on from SourceSafe and rcs to Git. - Here's the history of how people have done databases, flat-file, vs sql vs nosql - etc, etc, etc.
- rich_harris 9y ago
  Server-side rendering means you get a quick first load. Client-side rendering means subsequent navigations are quick, because there's less data to transfer (maybe a little bit of JSON, maybe nothing at all). Going back to the server for 100kb of HTML and reloading the entire page, as opposed to fetching 10kb of JSON and instantly updating it in place, is a very 2002 way of doing things!
  - RobertRoberts 9y ago
    >...because there's less data to transfer... The problem is that just the theory, reality if often times different. >Going back to the server for 100kb of HTML and reloading the entire page... This implies that 1) you don't go "back to the server" to load your bit of JSON. and 2) the JSON loaded doesn't require any extra templates, images or more JSON to be loaded. See the problem? It's all assumptions. Another thing, what about browser caching? I can see how the next page loads _only_ the html, as all the js, css and images were loaded already. I think you are falling for the exaggerated speed benefits from making a website with a JS framework. To be clear, I am talking about a web page, an HTML document, static content. Maybe that's where the confusion happens in discussions like this. (I said "sites", not "webapps" in my original comment) A history lesson, we did this with Flash years ago (no more page refreshes!), and everyone ultimately learned to hate it. Just because the flashy crap is spread over the entire "webapp/site" to every button, mouseover and click doesn't mean it's useful or better. (I think many devs think they need to build basic site features with big frameworks just to "stay modern".) Look at Youtube, it's slower now that they implemented their "webapp" experience, but the page doesn't "refresh", so that is somehow better... (is youtube really a webapp? Or a bunch of pages with videos on them?)
    - rich_harris 9y ago
      Ultimately, the proof is in the pudding. Which is faster, when you start navigating around? * https://news.ycombinator.com/item?id=16052558 https://news.ycombinator.com/item?id=16052558 * https://hn.svelte.technology/item/16052558 https://hn.svelte.technology/item/16052558 Bear in mind that HN itself has a huge advantage over HN clones, yet — for me at least, sitting here — the Sapper version is significantly snappier.
taneq 9y ago
When the entire page is 50kb of compressed text and some cached images, I don't mind reloading it on every single navigation (at which point dynamically generated HTML is more than adequate for dynamic data). It's only when devs insist on shoveling 5mb of compressed JS libraries into it that it becomes an issue.
purerandomness 9y ago
If you get <200ms Time To Interactive, working middle mouse click and back buttons, in which scenario wouldn't you want that?

unclebucknasty 9y ago

>HTML is close to this ideal HTML is anything but ideal. In fact, it's the core of the problem where Web applications are concerned. HTML and its kin (particularly CSS) were designed for content-oriented Web pages, not Web applications. Continuing to devise Web-app frameworks that are predicated upon developers wrangling HTML for controls and CSS for layout will lead to more iterations of frustration; only to perhaps slightly lesser degrees. It doesn't matter if you write JS that renders it or templates. It's the same problem. What's needed is a component-framework with proper tooling (including IDEs) for layout and design. We've solved this with Swing and even Visual Basic. So, for the life of me, I still can't figure out why we haven't moved in this direction full-on for Web frameworks. If the issue is that HTML and CSS are standards with broad support, then I concur: but compose the app via a proper GUI and let the tooling generate the HTML/CSS. It's odd: we use Webpack, Browserify, etc. for full on Web-app builds, along with various cross-compilers for JS. But, at the end of the day, we're still writing HTML-based templates (or JS) and CSS. This is generally an unpopular view on HN. But, I can nearly guarantee that the next truly meaningful advancement in frameworks will be via a component-oriented approach that abandons direct manipulation of Web standards like HTML/CSS altogether.

felipeccastro 9y ago
I agree with your view, but I suspect it hasn’t happened yet for a couple of reasons: - every time it was attempted, the generated html/css was terrible (think old ASP Net for example), and maintenance hard. Abstractions only work when they are not leaky - designers, devs and users in general expect to have custom design for everything, rather than standard controls. Something to do with “have a unique brand and not look like everyone’s else app”.
- unclebucknasty 9y ago
  >the generated html/css was terrible (think old ASP Net for example) We've come a long way in tooling, libraries, and in the underlying standards. Technologies like ASP also pre-dated SPAs and were targeted for server-side development; hence make for a poor analogy. Swing would be a more apt comparison, and even Visual Basic. In general, poor execution in the past is no reason to drop the objective. We've tolerated plenty of bad HTML-based frameworks and years of CSS-quirkiness, yet we keep plugging away at it. >and maintenance hard But the actual objective is that you wouldn't hand-maintain the generated code. We're currently so bound to HTML-thinking that it's hard to embrace that notion. >designers, devs and users in general expect to have custom design for everything I've heard this. Interestingly, though, we look to tools like Bootstrap and design-motifs like Material, etc., which emphasize uniformity. Also, there's no reason branding can't be applied without directly manipulated CSS. A good component-based library would allow for that and would also allow for the construction of extensible custom components.