Live data from Hacker News

Marko – A declarative, HTML‑based language

markojs.com

141–150 of 189 posts

Re: Marko – A declarative, HTML‑based language

#142

Earlier quoted context omitted.

File-based routing is fundamentally flawed and it cannot be fixed. A number of libraries opt for it since it's easier for newcomers to pick up, but eventually you run into all of the cases where you do need something else. This in turn leads you to a hybrid system of multiple things where there's no single source of truth and everything is spaghetti.

Care to make quite a simple example where file based routing would struggle?

Role based access control is one of the simplest examples, your routes need to be conditional and all come with related metadata for permissions and such. With file-based routing you'll then end up with your routes defined in one place and the configuration for them either in a separate different place or split up across the codebase. Whenever you need to change something you need to remember to do it everywhere else. If your routing is in code, you can define everything in one place with strict type checks, tests, and so on.

Re: Marko – A declarative, HTML‑based language

#143
post #8

Earlier quoted context omitted.

How would you prefer to write those examples?

Personally, I'd either just put the content in an ID-ed span and have a script to replace the content. Another, perhaps better, way is to use Alpine.JS which excels at this kind of stuff.

You should give this a read, it explains why they chose to put everything within the markup

https://markojs.com/docs/explanation/separation-of-concerns

Re: Marko – A declarative, HTML‑based language

#144
post #59

After two decades of this churn we are back to the equivalent of JSP. It was the correct paradigm all along but millennials wouldn't be caught dead working with such a "lame" technology so they bestowed SPA on us and now they are slowly walking it back.

We also had JSF, which was even cooler - being able to reconstruct the state server-side. It was ridiculously fast to write complex form-driver websites with that! No DTOs/schemas in different languages, no worry about how the client calls the server, what happens if it fails, etc.

The only problem is that it won't necessarily scale to some insane numbers without some care.

(Not sure why the past tense, it does work and developed still)

Re: Marko – A declarative, HTML‑based language

#145

Earlier quoted context omitted.

React is "just JavaScript" that you have to write in a very particular way, which the language in no way helps you enforce, for otherwise your "web app" will misbehave is bizarre and confusing ways.

There are no particular ways to code react where JSX is just JavaScript, it is not.

React is not the same thing as JSX. You can use React without using JSX and you can also use JSX without using React. This argument makes no sense from the get go.

Re: Marko – A declarative, HTML‑based language

#146

Earlier quoted context omitted.

There are no particular ways to code react where JSX is just JavaScript, it is not.

React is not the same thing as JSX. You can use React without using JSX and you can also use JSX without using React. This argument makes no sense from the get go.

It does not change the fact that JSX is not valid JavaScript and so 99.9% of React code is not valid JS.

Re: Marko – A declarative, HTML‑based language

#147
What I'm hoping to see in the future are:

1. native support for all http verbs such as put and delete in html itself without relying on JavaScript

2. sensible controls for drop down, select, multi select, date, time, datetime and so on without relying on any JavaScript

3. Submitting a form and submitting actions without reloading the whole page again without requiring any JavaScript

4. A whole lot of stuff yes without requiring any JavaScript

When I first heard the term htmx, I thought that was what htmx was but sadly it is just intercooler. What I am asking for requires broad support from browser vendors.

Re: Marko – A declarative, HTML‑based language

#148

Earlier quoted context omitted.

Agreed on the syntax part. We’ve had good syntax for templates before: {% for user in users %} {{ user.firstName }} {% endfor %} And we have good syntax for templates now: {#each users as user} {user.firstName} {/each} Why do we have to squish everything into HTML-like-but-not-quite blocks? But no, JSX isn’t that great either: {users.map(user => ( {user.firstName} ))}

Why not use html/XML style syntax rather than mixing two syntax styles? For example, "{/each}" already looks like " ".

I guess the argument against would be that designates an HTML "thing", i.e. some content for rendering.

is about control flow, so it's a conceptually different thing.

I can't tell how convincing that argument is to be honest, and how much I'm just rationalising familiarity.

Re: Marko – A declarative, HTML‑based language

#149
post #36

Honestly I don't know... I'm somewhat skeptical about these "next big thing that will fix all your pains in web development". There is so much fragmentation in JS libraries / frameworks. Angular, React, Vue, Svelte, Asto, SolidJS, NextJS, Nuxt, Qwik... The list is so overwhelming. Almost each one claims that it fixes a problem in other framework, and a year later the other framework fixes that issue... I think it's b…

Honestly I don't know... I'm somewhat skeptical about these "next big thing that will fix all your pains in web development". There is so much fragmentation in JS libraries / frameworks. Angular, React, Vue, Angular, Asto, SolidJS, NextJS, Nuxt, Qwik... The list is so overwhelming. Almost each one claims that it fixes a problem in other framework, a year later the other framework fixes an issue... I think it's better…

Svelte / SvelteKit is very lightweight but probably not a good choice if your app quickly grows in complexity. Angular has a larger community, long term support from Google, more people are familiar with, has rich functionality (including forms, localizations) and is well structured for huge projects. Once NextJS, SolidJS and others were interesting because of SSR, but Angular added this too (and continues to improve) in the recent versions.
Post reply on HN