Hacker News new | past | comments | ask | show | jobs | submit login
EHTML: Front-end development can and should be simple (guseyn.com)
70 points by bikkkkk on Nov 27, 2019 | hide | past | favorite | 71 comments

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.

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.

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..

What that telling leaves out is the fact that the web is also an extremely popular way to distribute documents. When someone finishes writing a manifesto or a fan fiction and considers how to disseminate it, they never respond with, “I know: I’ll distribute my manifesto or fan fiction on the iOS and Android’s app stores.” That greatly reduces the harm done by the lack of indexability and linkability of mobile apps.

> 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.

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

No, it is JavaScript and will break with JS disabled

loading pages with some information from endpoints and mapping it to html template, sending and validating forms, making navigations with turbolinks, making authorization via google and getting url parameters by specified pattern. And you don't need JS for such simple things

Reminds me of intercooler.js in various ways: 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.

      mapToTemplate('${someResponse.body}', '#box');
      logToConsole('statusCode:', '${someResponse.statusCode}');
oh my god

Looks familiar,

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

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.

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.

no, this looks like a nightmare leaky abstraction imperative API with non statically analyzable code like '#box'

#box is just a selector, it means element with id box, and you can see errors like "element is not found" anyway

I'm assuming it evals it, or runs it through some parser and does parameter replacement before executing.

it evals, but only some part of it, so it prevents XSS attacks

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.

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 .

What does this have to do with AMP?

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."

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

> 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.

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.

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.

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

The DOM layout model is particularly bad, IMO. I have very little to gripe with about Javascript since es6. Now I am using TypeScript and I think that language is pretty good.

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.

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.

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".

You're misunderstanding. Styled components is a specific concept that uses CSS within JS: 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.

> 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-...

>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.

> 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.

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.

SCSS? Is it 2015?

I'm not sure if this was intended to be a joke, it just seems hilarious to imply that something from three years ago should be considered outdated.

100% agreed. Html and css are for documents not for ui imo. Quite sad that they are becoming the standard for creating ui

The entire browser HTML-CSS layout engine is optimized for laying out text.

Your online banking balance is just text.

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

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.

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

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.

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.

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

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

“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”

Cold Fusion Reborn?

Reminds me of Polymer v2

"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.

> "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.

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.

> it doesn't tell us what distinguishes this framework within the space of new frameworks.

Neither does "The main problem with all those frameworks is JavaScript".

> 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.

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

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.

> In-page PHP is ugly

Why? Although I agree PHP itself is ugly, I always considered this particular part beautiful and alone worth tolerating the rest.

I don’t think there’s anything but in-page PHP. Some files are just skipping the HTML altogether.

same. author quickly lost me when i found these usual suspects in the repo: .babelrc, Gruntfile.js, package.json, package-lock.json, etc...

the fundamental premise still holds. we need to go back to roots and improve on HTML.

This lib allows you not to write js, it's just based on it.

> The fatigue is real.

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.

My feeling on the fatigue—as I imagine theirs is—is not that "making new things" is bad in some way. It's that re-abstracting the same problem in different ways has kind of diminished the novelty of frontend development. Where before we were trying to just do things consistently across browsers and had maybe one or two major libraries or patterns to develop expertise for in the market that solved those problems. Now, to be marketable for jobs, you have to accommodate a fairly fragmented market for the same problem. It's less a matter of fatigue related to "Oh sheesh now we have some stupid way to draw 3D graphics and communicate with Bluetooth devices via JS. When are we gunna stop making new things!?". It's more that "Oh golly, another way to piece components together with JS, HTML, CSS and route the pages together, super excited to re-enter the job market when I don't have production experience with Vue, React, Angular, Svelte, Redux, MobX, Vuex, and maybe others I dunno cuz idc". These aren't necessarily perfectly true statements, and nobody is necessarily forced to do anything, but it's fucking boring to hear about, and boredom leads to fatigue.

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.

So you are admitting that your Fear of Missing Out is irrational. You've developed a phobia of new libraries because... why? Because a small portion of other developers who post a lot on the internet are magpies?

Choose your own adventure already.

I don't personally have a fomo, but I'd certainly argue that it is very much rational and not necessarily a phobia. My impression is that it's just a cynical reaction to a lack of interest derived from lack of diversity in the problem domain. Your reaction would be irrational, perhaps derived from insecurity or feeling that your personal belief has been attacked repeatedly. Would you say that you personally love re-inventing the wheel, and would you prefer to have your viability in the job market depend on variable your knowledge is on the narrow scope of re-inventing the same wheel?

It's not just the parent poster, it's many people. The fatigue is real. If we have solutions today that meet all business needs, why do we new frameworks? Good ideas should stand the test of time. I don't think we've got a real discernible reason for why React or Vue are becoming stale or too rigid.

Repeating a meme over and over again doesn't make it true, it just makes you a robot.

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.

I think you've got this a bit backwards. It's not that people _feel_ that they need to retain information on every shiny new thing, it's that they _have actually had_ to retain information on an overwhelming number of new shiny things for professional reasons.

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!

> it's that they _have actually had_ to retain information on an overwhelming number of new shiny things for professional reasons.

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".

> No, they have not.

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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact