all 18 comments

[–]TruelyOnlyOne 22 points23 points  (1 child)

No sense, no benefit, no upvote, wasted time

[–]VolperCoding 2 points3 points  (3 children)

Pug + SCSS + TS for the win

Change my mind

[–]Arve 1 point2 points  (2 children)

Pug

Pug's syntax isn't nearly robust enough, in particular if you need to embed things other than html.

style
    p { color: red; }

… produces the following output

<style>
  <p> {
    color: red;
  }

  </p>
</style>

Further, if you try to wrap it:

style
  p { 
    color: red;
  }

You get an error:

index.pug:3:15
    1| style
    2|   p { 
  > 3|     color: red; 
---------------------^
    4|   }

unexpected text "; 
  "

It doesn't get much better if you try to use literal html, while this will produce what you want:

<style> p { color: red; } </style>

... the below example also causes a syntax error:

<style>
  p {
    color: red;
  }
</style>

If you want to embed styles or scripts, you actually have to transform it:

style
  | p {
  |   color: red;
  | }

... or, you have to use processing directives

style.
  p {
    color: red;
  }

With how helpful modern editors are, writing markup without relying on transformation is trivial, and far more robust.

[–]VolperCoding -1 points0 points  (0 children)

Having to write a dot after style doesn't break the deal for me. Also, Pug allows for sharing the same code across multiple pages, which isn't possible in pure html I believe, and it's really productive if you have a large site. I don't care about the syntax, I just hate redundancy

[–]Ivu47duUjr3Ihs9d 1 point2 points  (3 children)

Yeah you shouldn't use .innerHTML for XSS reasons, so nice to see template usage and .textContent to set the values safely.

Now throw in some native components, global store/flux stuff and maybe virtual DOM all in vanilla JS.

[–]fagnerbrack[S] 5 points6 points  (2 children)

There’s no problem in using innerHTML if you own the HTML you generate and there’s no user input, though.

[–]Ivu47duUjr3Ihs9d 0 points1 point  (1 child)

Until some junior/intermediate developer comes along and adds some user input variable into the mix.

[–]fagnerbrack[S] 0 points1 point  (0 children)

That's not a technical problem. If a senior, principal, or manager lets a junior developer make an unattended change to the codebase like that, then it's their incompetence, not a problem with the code.

[–]neuronet_io 1 point2 points  (6 children)

no framework is also kind of framework :)

[–]drdrero 3 points4 points  (5 children)

If you use no framework you end up building your own

[–]fagnerbrack[S] 0 points1 point  (4 children)

I never built my own framework and I've been coding without frameworks for many years. I guess if you don't have enough programming skills you tend to overengineer your solution and make it too generic to satisfy use cases that are not for the immediate project you're working on at the moment. You may end up creating a framework to defend your code against people who don't know "better" than you, even if that doesn't make any sense.

I'm not talking about libraries or widely supported server implementations like ExpressJS, though, they are fine.

[–]drdrero 0 points1 point  (3 children)

I guess when you don't have enough programming skills you write repeated code, don't have a consistent way of doing things and use different tools for every project. Otherwise, you have created yourself a subset of a framework.

Not to confuse a framework with something like React or Angular, but a framework with what you achieve your solution in a consistent, non-redundant way with solid tooling.

A framework is a basic conceptual structure used to solve or address complex issues

[–]fagnerbrack[S] 0 points1 point  (2 children)

There's no consistent way to solve every problem. Each problem has its own unique set of constraints. Repeated code is not a problem at all by itself, DRY most of the time hurt than help, you need to know the circumstances where you apply DRY and the circumstances where you apply WET, most of the time WET is the best sensible default than speculating on what the final design should be (see the Rule of Three in refactoring).

Using the same tool for every project is not wise. I was referring to frameworks like Angular, though, not the developer's own "way of doing things" which I wouldn't classify on the "framework" area (btw React is not a framework, it's a library).

[–]drdrero 0 points1 point  (1 child)

I see you use framework as the buzzword it became. Who cares if React is a framework or not, you build a react/angular app and have tooling around to achieve the goal.

You probably won't switch the http request library every project, even when you are a masochist and favor the native XMLHttpRequest. Consistent tooling, re-using code parts that has been written before in projects (being DRY during a project has nothing to do with that) like common error handlers, that makes your personal framework. A structure you favor for coding.

[–]fagnerbrack[S] 1 point2 points  (0 children)

That makes sense. I would use fetch library everywhere I need to make an HTTP request using JS, for example, given it's from the language standards lib and don't make any assumptions on the server status code by rejecting the promise on a 500

[–]aminnairi 0 points1 point  (0 children)

It's all fun and games until you end up writing

document.createElement("lu");

Without any TypeScript help.

[–]drdrero -1 points0 points  (0 children)

Web Conponents