
EHTML: Front-end development can and should be simple - bikkkkk
https://guseyn.com/posts/frontend-development-can-and-must-be-simple
======
oscargrouch
I miss the days Javascript were only considered a script language for HTML/CSS
and we use it for silly things like hover on buttons or simple animations.

The whole thing got completely out of control and we lost the transparency of
the web. We could open the source, see how it was made and learn some new
tricks. The indexers like search engines could index and understand the
content only by reading the data and metadata of a site.

Now is such a black box, that if you need to index for instance, you will need
to use a browser to render the whole page before you or any automated process
can understand it. Search engines now need to have ML based image and language
recognition just to understand the contents of a site (this is nuts). The free
trade of information is much more expensive and the web is turning into a
black box day-by-day..

The whole "appization" of the web for which the biggest leader is Google, is
leading to the fall of a medium of information that have so much potential.

Sorry for the rant, this is not the best place, but i cant see any move that
can change the course of this medium serving mostly the big guys, leading to
more concentration of power and resources.

Thats why i've think the only answer that can turn the table, need to start
fresh, because the game the web is in, is already rigged, and i think that it
has a lot to do with the design, not just the politics, strategy and the big
money.

~~~
satyrnein
In one telling, if the web had not added the features it did, it would have
ceded even more ground to mobile apps, which are even less indexable,
linkable, etc.

~~~
oscargrouch
There are two distinct paths for what the browser/web should become.. more
appish like or more like a collection interactive documents. In the end they
tried to mix both, but the appish view is eating whats left of the open world
of data the web was designed to be.

This is the path Google decided it should go.. They have Android if the strong
'app list' contender wins over web and on the other end they can index the web
with AI and Chrome whats left to be indexable (making it hard for contenders)
and also bloating the browser (with a huge set of API's) making it hard for
other players to try other visions for the web that require and can be done
with a simple engine.

I get it that it had to compete somehow with the app store. But for me, the
better option would be to split into two products, each one following one
path, but with browsers not following the path that would eventually kill
them.

I just see a 'dead end' with the web mostly being a framework to be embedded
for rich apps(its also a great tech for this end).

Thats why im trying something new here.. a different sort of a "browser", but
i dont think it can be called that way in the end.

I've started a couple of years ago, and im almost in the finish line now..

I hope that i can deliver a platform where information can flow free without
leading to centralization and digital monopolies that can choke all the rest,
but i cannot know if it will really deliver that, because its not just about
the tech..

------
cj
> Every moment a new JavaScript framework borns here and there, and all of
> them claim that they are better than other ones for different irrelevant and
> stupid reasons. The main problem with all those frameworks is JavaScript.

I‘m not quite seeing how this library solves that problem.

~~~
type0
So, does this library work for browsers with js disabled then? can it generate
regular html pages?

~~~
warent
No, it is JavaScript and will break with JS disabled

------
Deimorz
Reminds me of intercooler.js in various ways:
[https://intercoolerjs.org/](https://intercoolerjs.org/)

Intercooler seems more appropriate if you're looking to mostly build a
standard HTML site with some Javascript/AJAX enhancements though, and (at
least from a quick look) EHTML seems to be more aimed at being a templating
language with HTML-like syntax that you can use instead of generating the HTML
with backend templating.

------
stevebmark

        data-actions-on-response="
          mapToTemplate('${someResponse.body}', '#box');
          showElms('#box');
          logToConsole('statusCode:', '${someResponse.statusCode}');
        "
    

_oh my god_

~~~
eberkund
Looks familiar,

    
    
      someAttributeNvmWeCallThemProps={(someResponse) => {
        mapToTemplate('${someResponse.body}', '#box');
        showElms('#box');
        logToConsole('statusCode:', '${someResponse.statusCode}');
      }}

~~~
evv
Sure it is similar to JS/React, but you're missing out on lint tools, TS,
flow, reasonml, or other tools that help you catch errors.

~~~
eberkund
I don't know why React people always say that unless you're using JSX you miss
out on lint tools. VueJS templates use "" instead of {} but you still get all
the lint tools you'd expect.

------
warent
This is definitely a throwback to the days before we had complex JS libraries
but I'm not sure if that's a good thing. To me this seems like all the wrong
things are being abstracted away and you're left with stuff that should be
abstracted. The heavy coupling of the view and the model with no clear
controller is blurring the lines too much in what should be a separation of
respnsibilities.

This could work for tiny applications but for anything moderately complex I
predict this quickly turning into ad hoc spaghetti.

------
room271
This kind of AMP-like approach is something I'm a big fan of for simpler, more
news-like articles. There are potentially a lot of developer experience and
user experience (especially performance) benefits if done right. For my
thoughts on the whole AMP-style vs React/SPA approach see:
[https://niclong.uk/2019/07/20/amp.html](https://niclong.uk/2019/07/20/amp.html)
.

~~~
ShamelessC
What does this have to do with AMP?

~~~
CharlesW
Not the parent, but from TFA:

 _" By ‘AMP approach’ I mean loosely: a server-side that produces markup, and
dynamic behaviour introduced by markup-driven web-components on the client-
side. I do not mean the exact AMP libraries and that specific implementation.
If you are not familiar with how AMP works, it is probably worth taking a
brief look at some of their examples at this point before reading on."_

~~~
room271
Thanks. Couldn't reply earlier but this is definitely what I meant.

------
thiht
> Every moment a new JavaScript framework borns here and there

We need to stop with this meme, the landscape has largely stabilized around
Angular 2+, React and Vue in the last 5 years, and it's not going to change
anytime soon.

------
jbob2000
The only reason it’s not simple is that the product manager or designer or
client wants something different. If I don’t have to deal with them, then it’s
a piece of cake to implement a standard front end.

------
rossdavidh
I don't have much to say yet, except that I am intrigued and will investigate
more. Also, I like the documentation's use of short videos to demonstrate how
something is supposed to work.

------
crimsonalucard
I always thought the bigger mess was html and css rather than JavaScript.

~~~
warent
Particularly CSS. There's a lot of ways to apply styles now, e.g. styled
components directly in the JS, or using SCSS, etc, and these help, but overall
it's still a huge mess.

~~~
CharlesW
Although you can apply styles with JavaScript, it's best not to confuse doing
that with CSS. CSS is a reasonably-straightforward DSL. I really don't
understand suggestions that it's a "mess".

~~~
warent
You're misunderstanding. Styled components is a specific concept that uses CSS
within JS: [https://www.styled-components.com/](https://www.styled-
components.com/)

The mess with CSS comes from the difficulty of code resuability once an
application becomes complicated. Things start colliding and patterns diverge
easily.

~~~
CharlesW
> _You 're misunderstanding. Styled components is a specific concept that uses
> CSS within JS…_

Thanks, yes, I didn't realize you were talking about a particular framework.
I'm not familiar with that one.

> _The mess with CSS comes from the difficulty of code once an application
> becomes complicated. Things start colliding and patterns diverge easily._

CSS is imperfect, and there are different ways to think about it. But if you
find yourself running into design problems often, you may want to rethink how
you think about CSS.

For example, my approach to CSS used to be thoroughly semantic. Lately I've
been enjoying more of a "utility first" approach, which I learned about from
an article that you might also find interesting: [https://adamwathan.me/css-
utility-classes-and-separation-of-...](https://adamwathan.me/css-utility-
classes-and-separation-of-concerns/)

~~~
crimsonalucard
>CSS is imperfect, and there are different ways to think about it. But if you
find yourself running into design problems often, you may want to rethink how
you think about CSS.

Any language or system that requires highly disciplined and unintuitive
patterns to make work is a flawed system.

There is a a sort of catharsis once understanding of a pattern is achieved but
you should not be fooled by this. "Rethinking" a concept increases your
perception and understanding but CSS was never designed to be thought about
from another perspective. What you are mastering when you master CSS is how to
use the idiosyncrasies of a flawed system.

This is not unique to the front end. SQL is much the same way. Often in SQL
there are Optimizations with no rhyme or reason. You just write one
permutation of a query and pray that it compiles into something performant.

A well designed system is one where good design is emergent from the language
itself. A good example of this on the front end is ELM.

~~~
CharlesW
> _Any language or system that requires highly disciplined and unintuitive
> patterns to make work is a flawed system._

Things can seem unintuitive is when one's mental model of something is
different than what's actually happening. In that case one can choose to
believe that one's mental model is perfect, or one can consider the
possibility that one's mental model is incomplete and/or incorrect.

But that's learning, no? Everyone's mental map of almost everything is
incomplete and/or incorrect. Consider that CSS is generally (the occasional
implementation bug notwithstanding) doing what you tell it to do, and that if
it's not doing what you'd expect, that there's probably an opportunity learn
why your mental model doesn't match the reality of the abstraction.

> _This is not unique to the front end. SQL is much the same way. Often in SQL
> there are Optimizations with no rhyme or reason._

There's always rhyme or reason (or bugs, sometimes). I have the pleasure of
working with some of the foremost SQL experts in the world. When SQL that I've
written doesn't work how I'd expect or as performantly as I'd expect, I
inevitably discover that the problem is that my mental model is wrong and/or
incomplete and eventually walk away with enhanced understanding.

~~~
crimsonalucard
The language itself should map to the mental model. It should be an obvious
mapping. You learn the language you gain the mental model. With css, you learn
the language the mental model does not follow.

Many times the model that the language promotes is not what the developer
needs so the developer creates patterns to deal with inefficiencies. This is a
flaw.

Sql abstracts the underlying model of procedural algorithms into a one line
declarative expression. The language is designed to hide the model
deliberately.

However due to the requirement of optimizing queries one must optimize the
procedural algorithms while working with an API that deliberately hides it.
Thus in order to know which permutation of a sql expression maps to what
permutation of procedural algorithm you must memorize arbitrary mappings or
hacks. This is a huge design flaw. Your premiere sql experts are experts in
using hacks to get around the flaws of SQL.

------
turtlebits
One of the major problems with javascript is the huge payloads you need to
include. This one sits at 245k minified.

------
codeafin
Though it's cool that someone's trying to help with the JavaScript problem on
the internet, since this can't run without JavaScript it only seems to add to
the problem.

Still great to see people trying different approaches in avoiding that mess.

~~~
guseyn
It's based on JS, of course, but the goal is to get rid of JS as much as
possible for the developers who want to build frontend for their apps

------
kuon
The sanest environment I used for front end development was elm, I can't
recommend it enough. And if you don't need offline app, pure server side
rendering makes wonder and things live phoenix live view are really good.

~~~
thiht
I wouldn't say Elm is completely sane. Debugging is inexistant, the "1 release
every 2 years" breaks everything everytime, and some basic features are hard
to do well (eg. routing)

I believe Elm will become good once it reaches 1.0. Right now it's not
reliable enough.

------
mwilcox
I get the idea but technically this is just making HTML more complicated.

~~~
guseyn
Complex HTML is always better than complex JS, because HTML is declarative
language, it's much easier to maintain and modify

------
ketzo
“Front-end development can and should be simple”

==

“Every way a human can interact with an application is easy to sum up in ~500
lines of JavaScript I cooked up over the weekend”

------
iamthes
Cold Fusion Reborn?

------
difosfor
Reminds me of Polymer v2

------
teilo
[https://xkcd.com/927/](https://xkcd.com/927/)

------
koehr
"Every moment a new JavaScript framework borns here and there, so here is
mine." That is what should be written on the page, to be honest. And not even
the claim, that it lets you do everything without writing any JavaScript is
not true because you simply move your JavaScript into the DOM node attributes.
I think this is pretty much a step backwards towards in-page PHP or some XML
logic parsing.

Thanks for trying though. The fatigue is real.

~~~
core-questions
> a step backwards towards in-page PHP

In-page PHP is ugly, but it sure let normal people who had gotten comfortable
with serving static HTML make dynamic web pages quickly. It's also highly
performant.

~~~
aylmao
Lee Bryon had a fantastic talk about this during the last React Conf, check it
out [1]. He talks about the cyclic nature of programming paradigms, and how we
might actually be "going back to PHP" and that might not necessarily be a bad
thing.

PHP does after all have a straightforward mental model and expressive syntax,
but now we have learned to build better (more secure, more resilient,
performant, better architected, etc) web apps. IMO very worth a watch.

[1]:
[https://www.youtube.com/watch?v=vG8WpLr6y_U](https://www.youtube.com/watch?v=vG8WpLr6y_U)

~~~
bhhaskin
I would argue that we have never left PHP. WordPress powers 34% of the web.
It's fast and flexible, and modern PHP is actually a delight to work in. It's
also pretty secure. You have to go out of your way to make it insecure. Which
is an issue with any programming language.

------
alexandernst
$js_frameworks++;

