Hello,
I only recently found my way to go. I'm a (former?) fullstack web-dev and
as I ran into a PHP related problem (DOMDocument not working with HTML5
tags, I'd choose another solution stack if the language wouldn't be a fixed
point in history) I was looking if Go already has a good way to manipulate
HTML files. The templating is fine, but in my humble opinion there's a
problem...
Problem: IMHO templating in the current form is flawed. To insert
placeholders (i.E. "{{.nav}}") probably isn't an optimal solution as it
just tells the code "hey, act upon me". It seems to be a shallow solution
to prevent code-mixins, but fails to really separate the concerns.
Solution: If there would be a Go package to directly manipulate the DOM it
would be very helpful to separate Markup and Code. The code would act onto
the markup file (*.html) to create the page/site/module/... (whatever is
needed).
Pros:
- Frontend devs could create their own pages, modules, etc. without
thinking about any special tags they'd need.
-> '<main></main>' instead of '<main>{{.content}}</main>'
-> '<meta name="description" content="">' instead of '<meta
name="description" content="{{.description}}">'
- Error/Exception if some tag/id/class/... has not been found instead of
admins possibly not knowing about it.
-> You can act upon it and tell the users "Oops, something went wrong,
we're looking into it." so they know that the current state of the site
isn't what they should see.
-> Better an empty element (and the admin knows about it) instead of users
seeing placeholders.
- It's easier to avoid any problems with funny users trying to trick the
system.
- In theory faster than templating solutions (untested claim, so there's a
big questionmark)?
- It prefers modular frontends (main site, nav, main content, reusable
modules (i.E. for items on a sales platform)) instead of a single file with
placeholders
- It prefers cleaner code and true SoC instead of the ofttimes preferred
workflow "just a little HTML in the code to create each item faster" or
vice versa.
- ...
Cons:
- If there are elements unknown to the backend-devs, they will probably
stay empty
-> Possible solution could be some kind of taint-checking for empty
elements after page creation
- "Duplicate" code if there's frontend-scripting that is changing
parameters accordingly to AJAX results, but that's almost unavoidable.
- Probably more communication needed between backend- and frontend-devs
-> Possible solution, the aforementioned taint-checking, to see these
problems in testing, if they should arise
- ...
Feel free to contribute your thoughts, other pros/cons, etc. :)
Kind regards
Karv
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
