There are no tracking or monitoring cookies on this site. There are only cookies used for documentation examples related to cookies.

This may take a few seconds.


Does Active CSS handle the back-end as well as the front-end?

Active CSS is designed to work on the front-end only. You still need a back-end of some kind to provide your HTML. You can use Node, PHP, Laravel, or whatever you want on the back-end to produce your front-end HTML. Active CSS may or may not work with React, Angular or Vue out of the box due to the nature of the Virtual DOM. It should work fine with front-end frameworks that can work with the DOM with whatever state it is in at any given time. No plans have been made for us to support frameworks that use Virtual DOMs, but if you work out how to do it, let us know and we'll publish any solutions.

ACSS is designed to be an expansion of CSS, and CSS lives only in the browser, so this is a front-end only solution and will remain so.

Is using Active CSS an all-or-nothing affair?

No, it doesn't do anything to the page unless you tell it to. All your plugins should still work. It's like jQuery in this regard. You can just use features when you need them. Like you might load up jQuery and use it when you need to, you can do the same thing with Active CSS.

Why has no one thought of this before?

Possibly someone did think of it, but this is the first actual implementation. It would only take someone to ask "why is there only the hover event, why not click too?" to start moving towards a solution like this. I guess people gave up when they were told that CSS was just for styling. Plus it's not a simple thing to implement.

Although anyone extending CSS like this would have ended up with something that looked like Active CSS. It isn't actually that radical a concept.

What is the developer experience like compared to JavaScript and other frameworks?

It is a more A to B method of coding, and makes it easier to work with events. This then encourages more creativity as it becomes quicker and easier to code things. You are more likely to spend time on making things look cool, whereas with a framework you make feel a bit "locked-in".

It's a language, not a framework. So you can do the same thing in many different ways.

There is no build step. So you just code and hit refresh to see your results. Assuming you've got your browser caching under control for your development area...

Once you really know ACSS, the fact that it is a very quick and direct way to code could put you off of using other frameworks altogether, as it tends to make them seem to be a bit over-engineered, with unnecessary elements involved. However, you've got to be practical about things. Don't just ditch your frameworks without a plan. Work out how to simplify your dev flow to absolute minimum and you will then see how ACSS can tie into that to make things easier. Plus you will always need some sort of sensible back-end, even when using ACSS on the front-end, unless you are building fully static sites. ACSS should work well with any purely back-end framework.

Is this a real language?

Yes. But it is not function-based like JavaScript or other frameworks. It mirrors the event-driven nature of the web platform and is therefore more direct, like CSS. Hence, there is less code to write and it is a quicker and more intuitive way to code events and actions. It removes some of the complexity of having to write certain things with the lower-level JavaScript API. It is a custom built language designed solely for building websites. Languages tend to be more flexible than frameworks. Ease of use in a language is really determined by how high-level the commands are and whether they can handle scenarios in an easy way without a lot of mucking about. Frameworks are restricted to the context of the language they are written in, and so it's sometimes harder to get the right level of flexibility and functionality while remaining easy to develop in.

Active CSS is a high-level, extendable language that could potentially be merged into the browser and that provides a way for developers to extend the language and add new commands themselves. With this strategy of incremental improvement in the browser platform, then rather than starting afresh with learning a new language every decade, developers can build on the skills they learn rather than retraining from scratch or turning into unemployable coding dinosaurs. Do you want to be regarded as a master craftsman, or an irrelevant dinosaur by the middle of your career? Would you rather be spending a substantial amount of your time learning new things because the old way isn't good enough any more or just getting on with your work?

That solution though will only work if Active CSS becomes an approved W3C spec. It is early days though, and core functionality is still being added to Active CSS. A proper spec will be submitted to the W3C at some point, when features are seen to be justified.

Why is there no Virtual DOM? Doesn't that make things slower?

No, it shouldn't be any slower. Active CSS targets specific node locations of reactive variables on the page. It is more A to B in updating specific content areas. Variables are mapped to specific text nodes within elements and those nodes simply get updated when a variable changes. Those nodes need to get updated anyway even if a Virtual DOM is employed. The direct referencing of those nodes means that no diffing of content is required before updates occur. The point is for Active CSS to work with the DOM and not take it over.

ACSS doesn't handle updating lists at this level yet though. But it's not a big deal unless you are building something like a social network. You very, very rarely actually need targeted reactive list updating. Employing front-end components to draw a new HTML list from scratch with new JSON data has no performance implications these days. That is one of the reasons why this feature hasn't been in ACSS implemented yet. It isn't necessary for building ultra-fast, scalable, dynamic websites.

A benefit of not using a Virtual DOM is that Active CSS and your plugins will work dynamically with the DOM in the state it is in at any one time. This removes a whole ecosystem of development complexity and means additionally that you are free to use JavaScript plugins as you would without a framework. All your cool, awesome plugins that you used to use from way-back-when should work seamlessly with Active CSS. Native technology is the only technology guaranteed never to go out of date. Focusing on simple, native technology, and removing what you don't really need from your stack will save you time and money in the long term as you will be less likely to accumulate technical debt. All that glitters can be a mare's nest.

Why isn't the logo in shield-style like HTML, CSS and JS?

This is just a plugin, not native technology. It should be treated like a plugin with its own logo.

Can I get involved or make suggestions?

Yes - just go to the discussions section on the github page and strike up a conversation.