EHTML: Front-end development can and should be simple
guseyn.com
guseyn.com
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.
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..
I‘m not quite seeing how this library solves that problem.
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.
data-actions-on-response="
mapToTemplate('${someResponse.body}', '#box');
showElms('#box');
logToConsole('statusCode:', '${someResponse.statusCode}');
"
someAttributeNvmWeCallThemProps={(someResponse) => {
mapToTemplate('${someResponse.body}', '#box');
showElms('#box');
logToConsole('statusCode:', '${someResponse.statusCode}');
}}This could work for tiny applications but for anything moderately complex I predict this quickly turning into ad hoc spaghetti.
"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."
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.
The mess with CSS comes from the difficulty of code resuability once an application becomes complicated. Things start colliding and patterns diverge easily.
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-...
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.
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.
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.
I was watching videos from the chrome developer conference and there were two young peppy faces beaming that "gap" was now a supported CSS attribute for flex containers. That means in 2 years, if we are lucky, we can space out elements without hacking margins on child elements. Sometimes I almost can't believe what we put up with.
Still great to see people trying different approaches in avoiding that mess.
I believe Elm will become good once it reaches 1.0. Right now it's not reliable enough.
==
“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”
Thanks for trying though. The fatigue is real.
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.
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.
Why? Although I agree PHP itself is ugly, I always considered this particular part beautiful and alone worth tolerating the rest.
Oh, get over yourself. Whatever "fatigue" you are feeling is completely of your own choice. Other people aren't beholden to you for their desire to make things.
I cannot express strongly enough how much I hate comments like this. Go live in a utilitarian dystopia if you hate people making new things so much.
You choose to look at things like this and feel fatigue. Nobody forced to to look at it. Nobody told you "that's it, start retaining now". You have a fundamental fear of missing out that, instead of addressing the fear and feeling secure in your own choices, you feel necessary to externalize as criticism towards people exercising their own free will.
React existing or not existing or being old or not being old is not a reason for others to not do the work they want to do.
As a consequence, there is a tiredness and skepticism about new things. It's not that people feel that it's necessary to retain, it's that people enjoy learning about new options, but find that their lived experience has given them a resistance to that which they might otherwise enjoy.
They approach new things with interest, but end up frustrated to find more of the same.
Also you can't just tell people to not feel things! That's not how emotions work!
No, they have not. Not any more than the rest of us. Not any more than any other profession.
I really think this whole thing is borne out of Code Camp graduates coming into the job market thinking all they needed was whatever minuscule collection of shell scripting incantations they learned in the Code Camp to get a "Zomg 6-figure++ salary". And if that is all the training you've had, I can easily see how it will feel like it is inadequate (because it is). But the answer is not "keep feeding the inadequate way of learning".
And it's certainly not replying to someone's thread in which they present their hard work with "uuuuugh, woe is meeee".
Here's an idea: listen to how people feel rather than tell them how they feel.
If people have felt the need to do something and so have done, that's as good as saying they needed to — if sufficiently done en masse. Whether that attitude was justified in the first place doesn't negate the fatigue they may now feel — a feeling they're more than entitled to, even with you saying they're not.
That said, it's pointless to comment about and I do share your sentiment that the equally as frequent echo of pessimism isn't worthwhile.
Choose your own adventure already.
It's not, both because it's incoherent English, and because it doesn't tell us what distinguishes this framework within the space of new frameworks.
> I think this is pretty much a step backwards towards in-page PHP or some XML logic parsing.
I'm not sure why programming code embedded in HTML is substantially worse than the reverse (e.g., JSX). We're mixing syntax and concerns either way.
Neither does "The main problem with all those frameworks is JavaScript".
the fundamental premise still holds. we need to go back to roots and improve on HTML.