Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I feel that it empowers me as a Backend developer and makes me productive on both the BE and the FE.

For one it adds a simple set of primitives I need to learn on top of HTML (a basic tech to know), so no large JS frameworks or patterns to learn.

Secondly, it's really fast with regards to development speed, application speed and just getting up to speed in general. A basic MVC framework (such as Django but others also) is all you need in addition to the primitives I talked about above. With modern frameworks such as Vue or React, I need a backend with basically the Model and Controller part and then a different framework for the View part.



If you are confident that HTML will be your only target over time, then for sure this works.

The challenge can come if/when your backend needs to start servicing a mobile app, or some other channel that doesn't use HTML.

But again if you know that won't happen, no need to prematurely optimize for it.


If you structure your backend correctly, it should be trivial to build a JSON API on top of your service layer. Unless you're coupling your http endpoints to your service logic.


With webview based applications becoming more and more common, maybe HTML is all we’ll ever need.


I'm a Front End Dev and work with SPAs for the past 2 years. Working an offline-enabled PWA powered by Svelte and Redux. Honestly, I have a hunch that an HTML-based oriented development can still provide a great (measured) offline experience, without needing to rebuild wholesale to SPA.

It's a totally different ballgame if the app is mostly client-side utility anyway (calculators, etc), but the HTML + a bit of JS handling Service Worker and offline presentation should enable a great offline experience. I haven't seen it done in a large scale, but it should work.


Not if you want to adjust your views to different screen sizes and types.


Here you go:

https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queri...


In the wild, media queries are simply not enough. Often you need some JavaScript to really make things workable on smaller screens.


Why couldn't the client provide information to the server for selecting the appropriate HTML and CSS code for that particular client?


"Some Javascript" != SPA.


It's not exactly a lot of work to handle HTML for web apps and have an API for mobile clients or services. For example, if you are using Django, just add DRF with some serializers etc and re-use any common backend logic with both frontends.


1. Hotwire uses this approach for mobile as well (Hey and Basecamp are built this way)

2. Or you expose an API for those mobile clients. You might still be saving more work (but this is subjective and depends on the project).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: