To me, from the getting started, it looks like yet another JavaScript framework.
Might be good, unfortunately I got framework fatigue.
My personal website has about 30 lines of javascript, no framework and no library.
Contrarian take: the whole field of front-end frameworks seems to be lacking an all around good isomorphic solution to me.
Is there anything that would out of the box: 1) do fully static server-side rendering that outputs zero JS by default, 2) still be capable of rendering client-side interactive components where appropriate (for user agents with JS), 3) have both of the above as equal first-class citizens without contrived workarounds needed to achieve either interactivity or SSR, 4) handle all required bundling/fetching at build stage and load fast at runtime, 5) be isomorphic and leverage TypeScript typings to validate the correctness of the whole thing at build time as much as possible, and ideally 6) allow easy reuse of preexisting React components?
Another comment already mentioned Svelte. Alternatively, Hotwire Turbo or htmx might be more along the lines of what you want. Choose your own server-side language. I sprinkle in fancier frameworks when individual components need it, but this is more the exception than the rule.
The biggest difference is that it uses tags/components as a means to mix markup and code. (the "old" server-side language ColdFusion does this same thing)
I still slip <?php> tags straight into inline html a la 2004 from time to time, when it suits the purpose. I even occasionally use href="javascript:" if it saves time. No shame in using what works.
templates are always limitations, my friend. albatrosses. You're so right about the awful structure of the big CMSs...
I've just used my own RYO CMS for 15+ years for website work... it's gone through lots of updates, but it's super simple. I'd never make it public as a framework because any decent dev should be able to roll their own anyway, and I don't need the aggravation. But it's basically a VERY simplified cross between {{handlebars}} and React, without attempting to bind the whole DOM to data, plus a DSL for specifying all the pages and modules of each website in SQL, and setting up english-language router rules.
I'd ditch ergonomics any day for understanding what's going on and being able to pare it down as much as possible. Simple website clients pay so little these days it's basically charity work... you need something you can both do in an hour AND never have to worry about WordPress updating.
At least in Python, that's kinda what https://www.makotemplates.org is. Although if you're just using a subset of PHP suitable for templating, it's not really clear to me what benefit there is to PHP syntax versus, say, Jinja2 syntax.
the whole thing with PHP, originally, was you just wrote HTML pages and slipped in PHP <? echo $hello; ?> code here and there where you wanted the server to fill something in with server-side processing as the page was served. This is how it was used before it became common to generate whole templates or pages out of code. You'd be serving a basically static webpage and have a counter at the bottom showing hits, for example, so you'd take your .html and rename it to .php and the counter would be tagged to be generated by the server but everything else would just be plain HTML. PHP still supports this and the fact that it evolved into a full fledged language where you generate HTML from it (as opposed to embedding its output in static pages) still seems slightly humorous to me.
PHP with a correctly-configured server is about as fast as web-oriented scripting languages get, in practice. Yes, including Node. To be sure to beat it you'll need to switch to something compiled, and then take great care not to make any mis-steps.
If I'm in a hurry I still just use the fucking <center> tag. It works and I can't be bothered to google what's correct this week, if I'm just dipping into HTML for a minute or two.
Not as popular as it used to be, but definitely still around. The open source version (Lucee, formerly Railo) sees a lot of use as well. As for Adobe, I think it's treated as a step-child they acquired along with the rest of the Macromedia IP. I've actually been to trade shows where one part of the company was there and they didn't even know what ColdFusion is.
I would so love if Adobe would just spin off Macromedia again. I remember working on Flex frontends with CF engineers in the early 2000s and ...I mean, there is no reason that couldn't be updated to be a killer framework now if it worked with modern stacks.
Not surprising, but sad that Adobe flacks don't even know what it is. The world would be a lot more interesting if Macromedia was still a going concern, maybe aligned with Unity or some other ecosystem for game production.
>maybe aligned with Unity or some other ecosystem for game production
I think I recall Flash did try to offer some type of iPhone app development features towards the end of it's useful life but Jobs effectively sentenced Flash to death so most everyone had jumped ship by this point.
We built some games in Flash/Air that compiled to native iOS apps... they basically bundle the whole flash player into the game. It was and still is a working way to make an iOS game, it's just that Adobe no longer supports the plugin version... and you can't really trust them to support anything else going forward, so most devs moved to other languages and stacks like Unity.
ColdFusion is quite useful for internal (intranet) data search and reporting apps/pages that don't need lots of JavaScript eye-candy nor layer-happy frameworks. It makes it easy to stick hyperlinks in HTML data tables so managers can click to drill up, down, and all around to study data from different dimensions. There's also an open-source implementation or two, although I found the charting tools of the commercial version to be more mature.
I'd much rather use ColdFusion than Microsoft Power BI, if I had to choose. (MS-BI is probably a better fit for non-programmers.)
It's a whole weird world that just doesn't die. I worked at a place with ~ half a million lines of CF last year. There is a thing called CF Script which has vaguely JS-like syntax which can be used instead of the XML-based logic. There are even open-source frameworks built on top, with religious quotes in the documentation for some reason[0].
I know Luis, the creator of Coldbox. It's a great framework, and the quotes reflect his personal values, but other than finding that in the documentation, you won't find yourself being beat over the head with scripture. In years past, there were several other CF frameworks, and none could be characterized as having religious quotes, just the one :-)
I still believe good old sever-side rendering + js sprinkle is still the best business value for the buck. Our industry seems to not have analysis on engineering cost compute with business value.
This is the best way to get Python devs to start using JavaScript. But if you're already writing in JavaScript (or TypeScript), why wouldn't you want to re-use the code on server and client? Next.js is basically modern day PHP - you create a file in /pages/foo/bar.ts and it renders at localhost:3001/foo/bar. It really doesn't get much easier than this, and anyone complaining about it has likely not tried it or doesn't have a green field project where they can start from scratch with TypeScript and Next.js.
Also, this trope that "JavaScript can only render websites that require JavaScript to read" is a common misconception. Next.js, for example, is perfectly capable of rendering websites that work for clients with JavaScript disabled. In fact, that was kind of the original point of SSR: to make websites that search crawlers could read by processing the HTML sent from the server. The server renders the initial page, and then the client (optionally, if following best practices) "hydrates" the DOM to render any further content that requires client-side interaction (indeed, it's bad practice to require hydration, and a mismatch between server rendered DOM and hydrated DOM will generate warnings in development).
I wouldn’t say the state of the art is particularly great, but interestingly enough server-side rendering + JS sprinkle is exactly what many modern frameworks like Marko are going back to.
They provide some opinionated/convenient ways to author code but deliver fully server-side rendered HTML. They use fancy means to detect where interactivity is needed, and only ship JavaScript to the browser for those components.
In fact, they make what you describe easier to achieve. When you do it on your own, it’s up to you to ensure one piece JavaScript doesn’t mess another piece up, it’s up to you to sync back-end with front-end—but with a good framework you get encapsulation, bundling, and typing with compile-time checks (if you removed an attribute from some object server-side but forgot to update the client side, your build will fail with a useful error message before you can deploy it).
Your specific recommendation really depends on your use-case.
But I think the general principle applies, and you can even go further: try building simpler things. This is why I use static websites + a little JS and some API calls until I absolutely need my own server/SPA/etc.
The technical lead needs to explain and link between highly interactive widget to business value. Breaking down feature/value to pieces and link each to what type of widget it needs. JS frameworks always sell like lets build the whole thing with this whole tools. It's not only not fined-grain solution, it's often mismatched.
I don't buy the isomorphic thingy that reduces cognitive load because that's not only it's not absolutely true, it could be false and brings other type of problems.
I elaborate under the other comment. Htmx is good as long as there's not a lot of business value that needs highly interactive widgets. The whole thing is highly interactive sounds like a attempt silver bullet. The isomorphic invention currently doesn't solve client-server problems at all, it only solves 'I want to use one language' problem. Data still needs to live somewhere and move to somewhere, and there's physical distance between them, so it still has problems due to that condition.
I agree, that's why I like NextJS that gives you the DX of thinking in reusable and composable components (React) and type safety (TypeScript) that then ships no JS at all to the client.
And eBay is easily the jankiest website I use on an at all frequent basis. Click about in profile/settings and you get randomly shuttled about between pages designed in (by the looks of them) 2010, 2002, 2003, and 2016...
I don’t have inside info like you might, but it seems like a mean-spirited comment considering ebay.com uses marko, as well as other sites in the ebay group.
It definitely has not gained a lot of traction outside of ebay but there is a fair amount of buzz around the marko6 release with a completely new tags-based language.
It is also one of the few frameworks that leverage html streaming in a simple way (and has for a long time) and offers islands-style partial hydration out of the box.
You’re explaining basic external observations to someone who is painting an internal picture of Marko’s political status within eBay. This kind of insider take is gold.
Looks scary. ${index} and ${color} require escaping, (user.loggedOut) requires parentheses and |color, index| requires pipes. I just don’t understand what is going on.
What I like React for is that I can use JavaScript for things that seem to belong to JavaScript, like conditionals and loops. And components just have properties that may be dynamic and conditioned, in which case they obviously require JavaScript. But here the syntax breaks that separation of concerns IMO.
Maybe it's only me because I'm not a frontend developer and obvious things are not obvious to me, but it seems that there is nothing in the docs about deploying to a server and visiting a page it with a browser.
Anyway, I traced the JavaScript code. There are files packed with Webpack. They're not minified and pretty easy to follow. I even found a comment linking to https://github.com/gorhill/uBlock/issues/205 with the note "Do not handle added node directly from within mutation observer".
There are some docs on how to deploy for different node servers (express etc) as well as an examples repo which has templates for different environments.
I run Marko on cloudflare pages for some of my clients and couldn’t be happier, it’s the perfect framework for people who like writing plain html, but still want the advantages of a UI library like react.
Per some tests as of last year[0], Marko[1] is much more performant than Svelte, which matters a lot for UX and for page rankings (especially in case of more complex sites).
I’d expect Qwik to be faster than any of the above, but it seems not quite production-ready enough.
Right, I can understand this. In any case, it's very hard to define if something is more performant than something else due to the vast number of metrics available to estimate the performance. Are we talking DOM manipulation, time to interactivity, SSR, number of parallel requests? With today's full-stack frameworks, it's even harder to put a number on these things, let alone make a ranking.
What's interesting is Marko and Solid are opposite in some ways: the first is HTML first, with sprinkles of interactivity; and the second is JavaScript first, in that it uses JavaScript and JSX primarily. Despite these opposite approaches, they are both iterating towards having very little runtime overhead.
Marko v6 is an ambitious project that had its best parts stolen by modern frameworks. Solidjs for instance took a lot of inspiration from Marko, and solidjs would be my choice if the promise of marko resonates with you.
FYI Solid’s creator Ryan Carniato is a member of Marko’s core team (although he left eBay)
Solid has definitely gained more traction recently and the syntax is close to react, but Marko is really closer to Solid + SolidStart, and the upcoming major version will bring resumability which only Qwik offers at the moment.
Because you're not creating and updating nodes like in jQuery. You lay out a view, declaratively, fill out the holes where you want state, ie counter values, and then you have controllers to fill that out. When state changes, you recompute the entire view rather than imperatively changing out DOM nodes.
No, it's has the same semantic.
Method can return the whole new state, the changed fields or actions to be taken.
Or method can call the passed continuation with changed values instead of return.
> So, an app you write in Joystick today will look the same 10 years from now (features will be added/improved over time, but core APIs will not be deprecated unless there is a major security or performance issue). We like to refer to Joystick as "The Honda Civic of JavaScript Frameworks."
"Trust me, this thing -- which is very new -- will be around forever".
It's not a matter of trust. I designed the APIs to be stable from day one because I got tired of chasing unnecessary changes in the bigger frameworks. I spent a significant amount of time thinking ahead so changes weren't necessary.
Am I the only one perturbed by the use of invalid html? Could they not have marked up a new XSD/XML for these kinds of innovations? The browser and HTML renderers would know better to omit these kinds of markups.
The criticism is that it isn't React, and that nobody uses it but eBay.
There's nothing really wrong with it other than that there's no reason for it to exist when other frameworks work fine and have community traction. There's nothing special about eBay that requires it's own special UI framework.
And when we hire contractors to do anything they won't touch Marko so we have to use React anyway on a lot of projects.
Just not an efficient way to spend the companys money creating and maintaining a superfluous framework nobody asked for.
Get better contractors. It is just a JS framework. I have had to work in various weird frameworks, backend and frontend, and it is easy to get started in an existing codebase. Most of the fundamentals are the same.
I am so tired of developers who are scared of learning new things.
React is more of a library, if you want to compare Marko to something you could take Svelte, Next or Qwik. That said, React seems to be moving in the same direction with React Server Components (announced two years ago and still not available).
Which in my book is a fairly weak objection. Learning a new framework does not take much time if you already know one framework and you are put to work on an existing code base. I only knew Vue when I started working on an Angular codebase and it only took me a couple of days to get up to speed.
I wrote ColdFusion professionally for 7 years in the mid-'00s and I quite liked it back then. The issue, of course, was code organization and sprawl because you couldn't easily detach the logic from the view.
Still, <cfquery> blocks and <cfloop>s around the results were one of the fastest ways to get something up on a page and working, in the days before very mature frameworks existed yet.
It also forced everyone to know everything, so you could point to any dev on the team and they mostly understood the HTML, the CSS, the JS on the page, and the backend.
I think the industry trend toward specialization is useful in some cases, but it has made organizations and products almost intolerably complex in many cases where it isn't strictly necessary for the product itself.
We still have some production code that I support, but for the most part I've moved on from CF. Still, it is the language that established my career, in many ways. Custom tags well before client-side components were the rage, in-memory SQL engine (ie, take any recordset and query against it using SQL, without hitting a database), etc are features I still wish for using things like Ruby and server-side JS. The community and to a lesser degree Adobe tried to address the advantages other platforms had (like a first-class package manager) but it was too little, too late. Still, tools like CommandBox and the rest of the tooling by Ortus are actually pretty great.
I do find it interesting that client-side frameworks are "rediscovering" patterns from 25+ years ago :-)
In frontend engineering where there is a separation of logic and presentation you end up with flimsy, broken code. We used to write websites in html and then add some js that targeted specific elements and that was impossible to maintain.
Component based frameworks do away with all that because it doesn’t work. In react you’re mixing logic with your html too through jsx and this framework (and others like vue/svelte) go a step further and put everything related to a fragment of html in a single file.
This works really well, it means your styles don’t leak unless you want them to, your js usually only affects the html in the same file it’s written and you can build robust apps.
"Code elimination" in this case is making reference to Marko's ability to compile away some of the one-time code in their `render` function (unlike something like React that has to run everything inside of `render` ever time it renders).
This seems to be not just false, but the opposite of reality. Marko renders static multi-pages sites by default, and JS is generated for components that need reactivity. In fact, Marko even lacks built-in client-side routing.
