3 ms·

>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 (particul

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

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.