8 ms·

Everything that does not let me define the interface in HTML is a no-go for me. HTML and CSS are a very good approach to define a GUI. And they will be around

by TekMol 6y ago

Everything that does not let me define the interface in HTML is a no-go for me. HTML and CSS are a very good approach to define a GUI. And they will be around for a very long time. This is the reason why I also don't use React, Flutter and all the other ways to build web/mobile/whatever applications. I am torn on Vue. It is kind of ok because it lets you work with HTML templates with placeholders. Great. But it alters your data (puts getters/setters on everything) even when you don't need that. The best solution in my book is to use a javascript template engine like handlebars.

kondu 6y ago
What's your opinion on svelte?
- TekMol 6y ago
  Svelte seems to be set on having a server side build process for the front end. That is an even bigger no-go for me. The complexity of React and the OPs framework at least be contained in the frontend. With a server side build step, the complexity of the frontend spoils over to the backend.
- BiteCode_dev 6y ago
  One big selling point on vue is that you can just use a tag script and map a vue object on your regular HTML page. Ne need for build steps. No need for html in the JS script. It feels like JS from the 2000, simple and light, but with reactivity and speed. Of course, once you need it, you can just use the awesome ViteJS to get your backend build with SFC files. This makes vue scale up, but also scale down, which is equally important.
valenterry 6y ago
HTML is a text markup language and hence not very well suited to build a logical structure for the same reason that xml is not very well suited to describe data. And that is not because it cannot do it, but because it is too powerful. What is better in my opinion is a mix. Use one language or specification to model your architecture and structure and then, strictly on top of that, write (x)html to define your content. (you could also use markdown, just choose a markup language) Then, for the layout/design, use CSS that is completely separate from your site's structure and content; read: separate file, not embedded in the rest. Well, maybe CSS is insufficient and you also need to use Javascript or some language on top of it because the CSS is still lacking of lot of important things, but that's not a principal problem but a specific problem of CSS as a language.
- TekMol 6y ago
  With HTML you define a tree of elements. And you assign IDs and classes to those elements. How is that not well suited to build a logical structure?
  - kevincox 6y ago
    Because HTML (excluding web components which require JavaScript) doesn't have any way to handle repetition and conditionals. Of ccourse the commenter does mention using a templating language but a lot of people will be annoyed with this basic language and just want the full lower of JS to generate the site structure.
    - tonyedgecombe 6y ago
      doesn't have any way to handle religion <a religion="christian" href="...
      - kevincox 6y ago
        Fixed to repetition.
  - valenterry 6y ago
    Because it is too powerful. You can do something like this: <div class="main"> oh <div class="sub"> hello </div> </div> This is valid HMTL but it is not a valid structure in any context that I could imagine, because what is the "oh" supposed to do there? To prevent these (and other) mistakes, the way you can build up the structure should be restricted in a meaningful way and certainly not allow text and random positions and similar things. You could then describe this with a subset of HTML, but there isn't really any reason to choose it, except for "I'm used to it". Better choose your native programming language. And if it is not better than a HTML subset, maybe consider choosing your language.
mrweasel 6y ago
I know I'm old fashion, but I still don't like it when JavaScript and HTML is mixed. HTML comes first, then maybe some JavaScript to enhance features and finally CSS to make things look pretty. It's probably not a good way to built modern websites, but that's sort of the model I understand. Also any mention of NPM makes me not want to use something. Frankly the tooling around JavaScript is horribly confusing, especially for someone who learned HTML 22 years ago.
- azangru 6y ago
  > Frankly the tooling around JavaScript is horribly confusing, especially for someone who learned HTML 22 years ago. Why wouldn't the said someone take a day or two to update themselves on javascript tooling in order to get less confused? There are so many great resources available.
  - javajosh 6y ago
    The browser itself takes far longer than a day or two to learn to program even without tooling, considering that content is roughly the size of MDN; there is so much js tooling and documentation and of such wide variety that a year or two would not be enough for even a light review (roughly the content of github/js). And even that is not enough time to develop heuristics for deciding between approaches. And it doesn't begin to touch tooling, like editors, or deployment and runtime. Here is a video of a lovely man who invented Erlang, Joe Armstrong, expressing confusion about how to build a "modern" javascript program: https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4 (hilariously he was using grunt - a tool which is now entirely out of favor).
    - scambier 6y ago
      Come on, this isn't that hard if you have minimal, or even outdated, web dev knowledge. There is like 3 major frameworks (Angular, React, Vue). Spend a few hours to look how it is to work with each one, make your choice and follow a tutorial. Congrats, you've made your first Single-Page App. Of course if you've never written a line of code in your life, or if you're angry at the thought of using a dependency manager, you're going to have a hard time. And not only with the web stack.
azangru 6y ago
> Everything that does not let me define the interface in HTML is a no-go for me. Interesting. I'd say that anything that doesn't let me check that the interface contract for a component is met, i.e. that the component is receiving all the data from the parent that it has declared as required, is close to a no-go for me. I want my tools to be able to statically analyse my code and tell me where I screwed up.
thunderbong 6y ago
Like the other commenter mentioned, you should look at Svelte. I had the same perspective as yours and I've worked on multiple modern JS frameworks and Svelte is the closest I can get to mapping my mental model of how a web page works (HTML, CSS, JS) with the framework. Actually, I should correct myself - yes, the breakdown in terms of technology is HTML, CSS, JS but the underlying abstraction is actually - structure, presentation and functionality. This is where, imho, Svelte really shines. It helps you to map your mental model of structure, presentation and functionality to it's corresponding implementation of HTML, CSS, JS with a sprinkle of syntactic sugar. This goes way far in keeping the code easy to understand and maintainable in my opinion.
- TekMol 6y ago
  See https://news.ycombinator.com/item?id=26723219 https://news.ycombinator.com/item?id=26723219
- SahAssar 6y ago
  Svelte does three things that I disagree with: uses unconventional JS-ish syntax (like '$:' labels and how it does import/export), requires a very framework-specific templating language and requires a large build step. Since those are pretty central to how svelte is used and it's philosophy I don't think svelte is a good fit for me, personally. We all value different things in different frameworks, and that's great!
  - audience_mem 6y ago
    I agree. I've learnt my lesson and I will _NOT_ be running "npm install" on any greenfield projects anymore. I like the idea of Svelte but I do not like its dependency on npm/node. At least with Vue I can just include the library into the page, with no mandatory build step.
    - edoceo 6y ago
      Have y'all looked at RiotJS? My current favourite, not in my way, easy to reason about JS toolkit for building (all or part) of web-interface
jcelerier 6y ago
> HTML and CSS are a very good approach to define a GUI. source because the currently existing HTML/CSS UIs with which I have the "pleasure" to interact do a very good job of convincing of me of the exact opposite
volgar1x 6y ago
If you are building a documentation website, sure. Go implement a video-streaming platform using HTML/CSS only, that would be a real treat! :)
LaundroMat 6y ago
I'd guess you would like alpine.js
madeofpalk 6y ago
> Everything that does not let me define the interface in HTML is a no-go for me [...] This is the reason why I also don't use React. could you elaborate on that? How would you like to define interfaces in a way different from React or... anything else?
spankalee 6y ago
As someone who helped lead the Polymer team in the transition from HTML-first Polymer to JavaScript-first lit-html/LitElement, I have some experience building both approaches. I think that JavaScript-first is far better for templating the more general case (or the lower level foundation) because JavaScript is where your data lives. It's generally much easier to bring markup into JavaScript than it is data and data manipulation into HTML. In HTML you need re-invent expressions, scopes, control-flow, references, and imports. You're going to spend more time and code implementing a less expressive, slower, and more proprietary system. In JavaScript you just need a way to describe fragments of the resulting DOM (whether you prefer JSX, function calls, or tagged template literals), and the rest is just JavaScript. Now, I do see benefit from the HTML-first approach for a lot of people and some use cases. One reason I also push on web components so hard is that with interop comes flexibility in allowing a mix-and-match of approaches. As a side-project I'm working on an HTML-first declarative component system layered on top of LitElement: https://github.com/justinfagnani/stampino-element https://github.com/justinfagnani/stampino-element <stampino-element name="simple-greeter" properties="name"> <style type="adopted-css"> :host { color: blue; } </style> <template> <h1>Hello {{ name }}!</h1> </template> </stampino-element> <simple-greeter name="World"></simple-greeter> This can interop with any other web component, so you can write your app components in HTML, but drop to JS for the most complex components and use JS-first third-party components and design systems.
- lhorie 6y ago
  There are - as with most things in life - pros and cons to each approach. With plain JS, it's absolutely true that you can let the language do its things when it comes to things like scope, control flow, etc as opposed to reinventing them. But at the same time, there are a million ways to loop in JS, and a more restricted DSL can offer very good optimization opportunities that cannot be reasonably implemented on top of a JS-based templating engine. You can also create custom syntax for cases where the language doesn't gel so well (e.g. each/else or await in svelte) I've been slowly seeing more and more of a third approach where there's very little in the way of control flow in the template itself, where data is wired up using different constructs. Solid.js is an interesting example where it uses reactive constructs on top of "plain JS(X)", while encapsulating control flow inside components, which it is then able to optimize aggressively.

by TekMol 6y ago

kondu 6y ago

What's your opinion on svelte?

TekMol 6y ago
Svelte seems to be set on having a server side build process for the front end. That is an even bigger no-go for me. The complexity of React and the OPs framework at least be contained in the frontend. With a server side build step, the complexity of the frontend spoils over to the backend.
BiteCode_dev 6y ago
One big selling point on vue is that you can just use a tag script and map a vue object on your regular HTML page. Ne need for build steps. No need for html in the JS script. It feels like JS from the 2000, simple and light, but with reactivity and speed. Of course, once you need it, you can just use the awesome ViteJS to get your backend build with SFC files. This makes vue scale up, but also scale down, which is equally important.

valenterry 6y ago

HTML is a text markup language and hence not very well suited to build a logical structure for the same reason that xml is not very well suited to describe data. And that is not because it cannot do it, but because it is too powerful. What is better in my opinion is a mix. Use one language or specification to model your architecture and structure and then, strictly on top of that, write (x)html to define your content. (you could also use markdown, just choose a markup language) Then, for the layout/design, use CSS that is completely separate from your site's structure and content; read: separate file, not embedded in the rest. Well, maybe CSS is insufficient and you also need to use Javascript or some language on top of it because the CSS is still lacking of lot of important things, but that's not a principal problem but a specific problem of CSS as a language.

TekMol 6y ago
With HTML you define a tree of elements. And you assign IDs and classes to those elements. How is that not well suited to build a logical structure?
- kevincox 6y ago
  Because HTML (excluding web components which require JavaScript) doesn't have any way to handle repetition and conditionals. Of ccourse the commenter does mention using a templating language but a lot of people will be annoyed with this basic language and just want the full lower of JS to generate the site structure.
  - tonyedgecombe 6y ago
    doesn't have any way to handle religion <a religion="christian" href="...
    - kevincox 6y ago
      Fixed to repetition.
- valenterry 6y ago
  Because it is too powerful. You can do something like this: <div class="main"> oh <div class="sub"> hello </div> </div> This is valid HMTL but it is not a valid structure in any context that I could imagine, because what is the "oh" supposed to do there? To prevent these (and other) mistakes, the way you can build up the structure should be restricted in a meaningful way and certainly not allow text and random positions and similar things. You could then describe this with a subset of HTML, but there isn't really any reason to choose it, except for "I'm used to it". Better choose your native programming language. And if it is not better than a HTML subset, maybe consider choosing your language.

mrweasel 6y ago

I know I'm old fashion, but I still don't like it when JavaScript and HTML is mixed. HTML comes first, then maybe some JavaScript to enhance features and finally CSS to make things look pretty. It's probably not a good way to built modern websites, but that's sort of the model I understand. Also any mention of NPM makes me not want to use something. Frankly the tooling around JavaScript is horribly confusing, especially for someone who learned HTML 22 years ago.

azangru 6y ago
> Frankly the tooling around JavaScript is horribly confusing, especially for someone who learned HTML 22 years ago. Why wouldn't the said someone take a day or two to update themselves on javascript tooling in order to get less confused? There are so many great resources available.
- javajosh 6y ago
  The browser itself takes far longer than a day or two to learn to program even without tooling, considering that content is roughly the size of MDN; there is so much js tooling and documentation and of such wide variety that a year or two would not be enough for even a light review (roughly the content of github/js). And even that is not enough time to develop heuristics for deciding between approaches. And it doesn't begin to touch tooling, like editors, or deployment and runtime. Here is a video of a lovely man who invented Erlang, Joe Armstrong, expressing confusion about how to build a "modern" javascript program: https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4 (hilariously he was using grunt - a tool which is now entirely out of favor).
  - scambier 6y ago
    Come on, this isn't that hard if you have minimal, or even outdated, web dev knowledge. There is like 3 major frameworks (Angular, React, Vue). Spend a few hours to look how it is to work with each one, make your choice and follow a tutorial. Congrats, you've made your first Single-Page App. Of course if you've never written a line of code in your life, or if you're angry at the thought of using a dependency manager, you're going to have a hard time. And not only with the web stack.

azangru 6y ago

> Everything that does not let me define the interface in HTML is a no-go for me. Interesting. I'd say that anything that doesn't let me check that the interface contract for a component is met, i.e. that the component is receiving all the data from the parent that it has declared as required, is close to a no-go for me. I want my tools to be able to statically analyse my code and tell me where I screwed up.

thunderbong 6y ago

Like the other commenter mentioned, you should look at Svelte. I had the same perspective as yours and I've worked on multiple modern JS frameworks and Svelte is the closest I can get to mapping my mental model of how a web page works (HTML, CSS, JS) with the framework. Actually, I should correct myself - yes, the breakdown in terms of technology is HTML, CSS, JS but the underlying abstraction is actually - structure, presentation and functionality. This is where, imho, Svelte really shines. It helps you to map your mental model of structure, presentation and functionality to it's corresponding implementation of HTML, CSS, JS with a sprinkle of syntactic sugar. This goes way far in keeping the code easy to understand and maintainable in my opinion.

TekMol 6y ago
See https://news.ycombinator.com/item?id=26723219 https://news.ycombinator.com/item?id=26723219
SahAssar 6y ago
Svelte does three things that I disagree with: uses unconventional JS-ish syntax (like '$:' labels and how it does import/export), requires a very framework-specific templating language and requires a large build step. Since those are pretty central to how svelte is used and it's philosophy I don't think svelte is a good fit for me, personally. We all value different things in different frameworks, and that's great!
- audience_mem 6y ago
  I agree. I've learnt my lesson and I will _NOT_ be running "npm install" on any greenfield projects anymore. I like the idea of Svelte but I do not like its dependency on npm/node. At least with Vue I can just include the library into the page, with no mandatory build step.
  - edoceo 6y ago
    Have y'all looked at RiotJS? My current favourite, not in my way, easy to reason about JS toolkit for building (all or part) of web-interface

jcelerier 6y ago

> HTML and CSS are a very good approach to define a GUI. source because the currently existing HTML/CSS UIs with which I have the "pleasure" to interact do a very good job of convincing of me of the exact opposite

volgar1x 6y ago

If you are building a documentation website, sure. Go implement a video-streaming platform using HTML/CSS only, that would be a real treat! :)

LaundroMat 6y ago

I'd guess you would like alpine.js

madeofpalk 6y ago

> Everything that does not let me define the interface in HTML is a no-go for me [...] This is the reason why I also don't use React. could you elaborate on that? How would you like to define interfaces in a way different from React or... anything else?

spankalee 6y ago

As someone who helped lead the Polymer team in the transition from HTML-first Polymer to JavaScript-first lit-html/LitElement, I have some experience building both approaches. I think that JavaScript-first is far better for templating the more general case (or the lower level foundation) because JavaScript is where your data lives. It's generally much easier to bring markup into JavaScript than it is data and data manipulation into HTML. In HTML you need re-invent expressions, scopes, control-flow, references, and imports. You're going to spend more time and code implementing a less expressive, slower, and more proprietary system. In JavaScript you just need a way to describe fragments of the resulting DOM (whether you prefer JSX, function calls, or tagged template literals), and the rest is just JavaScript. Now, I do see benefit from the HTML-first approach for a lot of people and some use cases. One reason I also push on web components so hard is that with interop comes flexibility in allowing a mix-and-match of approaches. As a side-project I'm working on an HTML-first declarative component system layered on top of LitElement: https://github.com/justinfagnani/stampino-element https://github.com/justinfagnani/stampino-element <stampino-element name="simple-greeter" properties="name"> <style type="adopted-css"> :host { color: blue; } </style> <template> <h1>Hello {{ name }}!</h1> </template> </stampino-element> <simple-greeter name="World"></simple-greeter> This can interop with any other web component, so you can write your app components in HTML, but drop to JS for the most complex components and use JS-first third-party components and design systems.

lhorie 6y ago
There are - as with most things in life - pros and cons to each approach. With plain JS, it's absolutely true that you can let the language do its things when it comes to things like scope, control flow, etc as opposed to reinventing them. But at the same time, there are a million ways to loop in JS, and a more restricted DSL can offer very good optimization opportunities that cannot be reasonably implemented on top of a JS-based templating engine. You can also create custom syntax for cases where the language doesn't gel so well (e.g. each/else or await in svelte) I've been slowly seeing more and more of a third approach where there's very little in the way of control flow in the template itself, where data is wired up using different constructs. Solid.js is an interesting example where it uses reactive constructs on top of "plain JS(X)", while encapsulating control flow inside components, which it is then able to optimize aggressively.