4 ms·

Using html (and tailwindcss) have been the major productivity gain in web front-end development for us. The speed on the UI is noticeable for our users (a lot

by mamcx 4y ago

Using html (and tailwindcss) have been the major productivity gain in web front-end development for us. The speed on the UI is noticeable for our users (a lot of underpowered androids!) and the interactivity is equal than our prior vue version. React/Vue is like Nosql: Good for certain niche scenarios but overkill for most use cases. Plain html/css is pretty performant and so easy to do than duplicate the state (+validations, structures, routes,...) between client/server. So, if you are on the fence: Just try it. Is very likely it will be FAR simpler than you imagine!

FractalHQ 4y ago
This is what makes Svelte so fun and appealing for me. It’s just html with script and style tags… with optional superpowers if/when you need them. And automatically scoped styles, optimized bundles, SSR, and all the DX / UX boosts you could want!
mathgladiator 4y ago
I second tailwind as the way, and I'm using it along with web components. I think the important aspect of React/Vue was to inspire Web Components to exist. Now that I can leverage Web Components, I don't see a real need for React as the browser is very capable. For me, I'm building https://www.adama-platform.com/ https://www.adama-platform.com/ which is a reactive backend which then makes building reactive/interactive applications very simple. With tailwind, I can just copy and paste HTML snippets and make it live with data. So much fun!
- nickcox 4y ago
  > I think the important aspect of React/Vue was to inspire Web Components to exist Web Components predate React as an idea, don't they? Admittedly it too hella long to get them properly standardised.
  - bigDinosaur 4y ago
    React as an idea predates React too ;-P
- dmitriid 4y ago
  > Now that I can leverage Web Components, I don't see a real need for React as the browser is very capable. Except for the long list of issues that WC proponents pretend doesn't exist: https://twitter.com/Rich_Harris/status/1198332398561353728 https://twitter.com/Rich_Harris/status/1198332398561353728
  - mathgladiator 4y ago
    Damn, now I have to pretend those don't exist. I have to investigate how it breaks a11y as that seems to the the core killer in my case. How does that list square with https://shoelace.style/ https://shoelace.style/ ?
    - dmitriid 4y ago
      The linked tweet in the linked tweet gives one such example: https://twitter.com/sarahmei/status/1198069119897047041 https://twitter.com/sarahmei/status/1198069119897047041 I remember there being more, but I can't remember the links off the top of my head (and on mobile).
  - ramesh31 4y ago
    >Except for the long list of issues that WC proponents pretend doesn't exist: https://twitter.com/Rich_Harris/status/1198332398561353728 https://twitter.com/Rich_Harris/status/1198332398561353728 This is the sad reality for web components. You end up needing so many libraries to do basic things that a framework would handle, that your project just becomes a defacto custom framework.
- ssorallen 4y ago
  Alex Russell introduced Web Components in 2011. React was released in 2013. Web Components originally used a view-model architecture, which I would guess was heavily inspired by the most popular JS framework leading up to 2011: Backbone. React was a massive departure from Backbone, and sadly the Web Components spec was developed before React had matured and changed the landscape.
  - mathgladiator 4y ago
    Thanks for the correction
  - Shorel 4y ago
    I think it was Angular.js the framework that made us jump from JQuery to the modern way to do things. Backbone was never that popular. Angular.JS was created in 2009 and released in 2010.
    - ssorallen 4y ago
      Yup good call, Angular.js seems more likely than Backbone now that you mention it.
- darepublic 4y ago
  Sorry to say but you should brush up your UI on mobile firefox
tomcam 4y ago
How dare you call your users underpowered androids! I’ll see myself out now
woutr_be 4y ago
I started as a front-end developer, so doing lots of Angular, React and Vue. But over the past few years I've transitioned back to plain HTML (or at least templating on the server side), and I find it so much more enjoyable and much faster to developer as well. I don't have to constantly switch between front-end/back-end, having to build APIs, just so that my single SPA can consume them. Although I really miss the flexibility of of React/Vue components that can take different parameters, and have rendering logic inside them. jinja2/pug and the likes, just don't have that.
- crabmusket 4y ago
  I really think components are an incredible innovation, and I'm constantly shocked that mainstream backend template systems don't have them. Some are beginning to, e.g Laravel's blade.
  - zelphirkalt 4y ago
    What are the innovative parts of web components, which have no equivalent in lets say mainstream OOP, lumping state and behavior together?
    - crabmusket 4y ago
      Oh I didn't mean innovative in the broad software landscape. I may have spoken a bit too emphasically. I just meant to compare them to their direct competitors, e.g. Jinja style server side templating. The best part of component-based templating to me is not when it resembles OOP, but when it's functional. Components as functions with all that entails (scope, most significantly) is a step up from the very procedural, preprocessor-style template engines.
      - zelphirkalt 4y ago
        Hm. I see it exactly the opposite way: A template renders the same every time, given the same input. Rendering a template is like a function. It encourages people to put their logic elsewhere (separation of concerns) and first get the data they need, to only then render the template. Templates are merely views. A web component in contrast has internal state, which it mutates, or at least can have internal stage and often does have such. Also it relies on global state, which is accesses. It seems to me like a step down from preprocessed templates, because state and behavior are lumped together again and because of internal mutating state. The view layer is no longer cleanly separated. In practice the resulting DOM often is more convoluted and styles are defined in less obvious ways ultimately on the website. It makes writing user stylesheets and user scripts harder. You can re-use web components, but realistically every projects adapts or writes their own component anyway and you can only re-use for the same framework or one based on the framework, for which the component was written. Re-use of components seems even less than it was for "my classes from the other project" in OOP, because not only does one have language specific classes, but framework-family specific components. While not directly necessary for web components in general, I also find that syntax annoying, which mixes some kind of HTML look-alike with JS blocks inside of it. Kind of a reminder of PHP outputting HTML, which contains PHP blocks, which output JS, which modifies HTML. It is also annoying, because now I have to learn an HTML look-alike, which has new rules about what may be nested into what and those rules do not always make sense. I cannot nest as freely as in real HTML. What I write in a web component is not what ultimately gets output, but instead if will be translated at the end of the process. In a template I would simply write my HTML and compose them in such a way, that I have separate templates for semantically separate things, enabling re-use of templates. It is easy to do and the code is real HTML, no need for any indirection of translating a look-alike into ultimately HTML again. Seems to me, that many lessons of the past have been forgotten.
k__ 4y ago
So, your scenarios are mainstream and what React/Vue devs do is niche?
- mamcx 4y ago
  > React/Vue devs devs probably not (ie: as NoSql, Kubernetes and stuff, some people pick overkill things, and by some I also mean me!), but React/Vue as libraries, certainly! A SPA is a niche among the most mainstream web site. It makes sense when the interactivity is BIGLY on the cliente (like for example: A paint app). But most things on web are not 90% client vs 10% server. Is the opposite. Your todos, mail client, eCommerce site, blog, etc are better served with a server-side approach (note also how much important security is on this kind of apps!). Your screen that display an interactive map, your game, paint app must certainly need a more client-first approach. But as SPAs says: Is a "SINGLE" app. One. Is your full app ONLY ONE? No? Then you are not in the niche, and if you actually have that SINGLE screen/app is likely a fraction of the whole thing. --- Another possibility is that single thing consume so much that you say, screw it, lets do the rest similar even if is a poor-fit, but I think that is rarely if ever the best (for the users!). This is what drive adoption, React/Vue solve nicely some hard stuff and naively you think is great for the most basic one. But as show the fact that stuff like "back button" get broken without EXTRA workarounds is not the best fit for them... P.D: Is my opinion -after try for years do the opposite!- that the majority of the web apps be server-driven and maybe add a little of react/vue/alpine for extra nice touch...
darepublic 4y ago
If I ever have a web application that I expect _could_ be revisited to add more functionality, next.js is the go to. It's performance on the user end is great, though I would be interested in how it does in the underpowered android scenario. Nevertheless it's hard for me to imagine feeling good about needing to add a feature on a plain Js+html project

by mamcx 4y ago

FractalHQ 4y ago

This is what makes Svelte so fun and appealing for me. It’s just html with script and style tags… with optional superpowers if/when you need them. And automatically scoped styles, optimized bundles, SSR, and all the DX / UX boosts you could want!

mathgladiator 4y ago

I second tailwind as the way, and I'm using it along with web components. I think the important aspect of React/Vue was to inspire Web Components to exist. Now that I can leverage Web Components, I don't see a real need for React as the browser is very capable. For me, I'm building https://www.adama-platform.com/ https://www.adama-platform.com/ which is a reactive backend which then makes building reactive/interactive applications very simple. With tailwind, I can just copy and paste HTML snippets and make it live with data. So much fun!

nickcox 4y ago
> I think the important aspect of React/Vue was to inspire Web Components to exist Web Components predate React as an idea, don't they? Admittedly it too hella long to get them properly standardised.
- bigDinosaur 4y ago
  React as an idea predates React too ;-P
dmitriid 4y ago
> Now that I can leverage Web Components, I don't see a real need for React as the browser is very capable. Except for the long list of issues that WC proponents pretend doesn't exist: https://twitter.com/Rich_Harris/status/1198332398561353728 https://twitter.com/Rich_Harris/status/1198332398561353728
- mathgladiator 4y ago
  Damn, now I have to pretend those don't exist. I have to investigate how it breaks a11y as that seems to the the core killer in my case. How does that list square with https://shoelace.style/ https://shoelace.style/ ?
  - dmitriid 4y ago
    The linked tweet in the linked tweet gives one such example: https://twitter.com/sarahmei/status/1198069119897047041 https://twitter.com/sarahmei/status/1198069119897047041 I remember there being more, but I can't remember the links off the top of my head (and on mobile).
- ramesh31 4y ago
  >Except for the long list of issues that WC proponents pretend doesn't exist: https://twitter.com/Rich_Harris/status/1198332398561353728 https://twitter.com/Rich_Harris/status/1198332398561353728 This is the sad reality for web components. You end up needing so many libraries to do basic things that a framework would handle, that your project just becomes a defacto custom framework.
ssorallen 4y ago
Alex Russell introduced Web Components in 2011. React was released in 2013. Web Components originally used a view-model architecture, which I would guess was heavily inspired by the most popular JS framework leading up to 2011: Backbone. React was a massive departure from Backbone, and sadly the Web Components spec was developed before React had matured and changed the landscape.
- mathgladiator 4y ago
  Thanks for the correction
- Shorel 4y ago
  I think it was Angular.js the framework that made us jump from JQuery to the modern way to do things. Backbone was never that popular. Angular.JS was created in 2009 and released in 2010.
  - ssorallen 4y ago
    Yup good call, Angular.js seems more likely than Backbone now that you mention it.
darepublic 4y ago
Sorry to say but you should brush up your UI on mobile firefox

tomcam 4y ago

How dare you call your users underpowered androids! I’ll see myself out now

woutr_be 4y ago

I started as a front-end developer, so doing lots of Angular, React and Vue. But over the past few years I've transitioned back to plain HTML (or at least templating on the server side), and I find it so much more enjoyable and much faster to developer as well. I don't have to constantly switch between front-end/back-end, having to build APIs, just so that my single SPA can consume them. Although I really miss the flexibility of of React/Vue components that can take different parameters, and have rendering logic inside them. jinja2/pug and the likes, just don't have that.

crabmusket 4y ago
I really think components are an incredible innovation, and I'm constantly shocked that mainstream backend template systems don't have them. Some are beginning to, e.g Laravel's blade.
- zelphirkalt 4y ago
  What are the innovative parts of web components, which have no equivalent in lets say mainstream OOP, lumping state and behavior together?
  - crabmusket 4y ago
    Oh I didn't mean innovative in the broad software landscape. I may have spoken a bit too emphasically. I just meant to compare them to their direct competitors, e.g. Jinja style server side templating. The best part of component-based templating to me is not when it resembles OOP, but when it's functional. Components as functions with all that entails (scope, most significantly) is a step up from the very procedural, preprocessor-style template engines.
    - zelphirkalt 4y ago
      Hm. I see it exactly the opposite way: A template renders the same every time, given the same input. Rendering a template is like a function. It encourages people to put their logic elsewhere (separation of concerns) and first get the data they need, to only then render the template. Templates are merely views. A web component in contrast has internal state, which it mutates, or at least can have internal stage and often does have such. Also it relies on global state, which is accesses. It seems to me like a step down from preprocessed templates, because state and behavior are lumped together again and because of internal mutating state. The view layer is no longer cleanly separated. In practice the resulting DOM often is more convoluted and styles are defined in less obvious ways ultimately on the website. It makes writing user stylesheets and user scripts harder. You can re-use web components, but realistically every projects adapts or writes their own component anyway and you can only re-use for the same framework or one based on the framework, for which the component was written. Re-use of components seems even less than it was for "my classes from the other project" in OOP, because not only does one have language specific classes, but framework-family specific components. While not directly necessary for web components in general, I also find that syntax annoying, which mixes some kind of HTML look-alike with JS blocks inside of it. Kind of a reminder of PHP outputting HTML, which contains PHP blocks, which output JS, which modifies HTML. It is also annoying, because now I have to learn an HTML look-alike, which has new rules about what may be nested into what and those rules do not always make sense. I cannot nest as freely as in real HTML. What I write in a web component is not what ultimately gets output, but instead if will be translated at the end of the process. In a template I would simply write my HTML and compose them in such a way, that I have separate templates for semantically separate things, enabling re-use of templates. It is easy to do and the code is real HTML, no need for any indirection of translating a look-alike into ultimately HTML again. Seems to me, that many lessons of the past have been forgotten.

k__ 4y ago

So, your scenarios are mainstream and what React/Vue devs do is niche?

mamcx 4y ago
> React/Vue devs devs probably not (ie: as NoSql, Kubernetes and stuff, some people pick overkill things, and by some I also mean me!), but React/Vue as libraries, certainly! A SPA is a niche among the most mainstream web site. It makes sense when the interactivity is BIGLY on the cliente (like for example: A paint app). But most things on web are not 90% client vs 10% server. Is the opposite. Your todos, mail client, eCommerce site, blog, etc are better served with a server-side approach (note also how much important security is on this kind of apps!). Your screen that display an interactive map, your game, paint app must certainly need a more client-first approach. But as SPAs says: Is a "SINGLE" app. One. Is your full app ONLY ONE? No? Then you are not in the niche, and if you actually have that SINGLE screen/app is likely a fraction of the whole thing. --- Another possibility is that single thing consume so much that you say, screw it, lets do the rest similar even if is a poor-fit, but I think that is rarely if ever the best (for the users!). This is what drive adoption, React/Vue solve nicely some hard stuff and naively you think is great for the most basic one. But as show the fact that stuff like "back button" get broken without EXTRA workarounds is not the best fit for them... P.D: Is my opinion -after try for years do the opposite!- that the majority of the web apps be server-driven and maybe add a little of react/vue/alpine for extra nice touch...

darepublic 4y ago

If I ever have a web application that I expect _could_ be revisited to add more functionality, next.js is the go to. It's performance on the user end is great, though I would be interested in how it does in the underpowered android scenario. Nevertheless it's hard for me to imagine feeling good about needing to add a feature on a plain Js+html project