Haxe for web front-end development

[Nathan Hüsken]

Hi,

I am in the situation, that I have to develop a html5 front-end. Since I
am not a fan of JavaScript and I am fluent in Haxe, I was wondering what
possibilities I have in Haxe to do this.

I have not experience with web development and html5. I have used haxe
to write games for mobile and flash using openfl and stablexui.

Are there javascript front-ends that work well with haxe?
What would you use/what are your suggestions?

Thanks!
Nathan

[Confidant]

Can you explain what you mean by a "front-end", and what your application needs are? To begin with, Is it graphics-intensive or does it require mostly HTML? Is it a one-page thing, or does it need to use multiple URLs (i.e. "routing")?

[Brennan Kinney]

It really depends what sort of front-end you are tasked to develop. If you're to do a traditional sort of website with vertical scrolling and responsiveness, there can be quite a bit of learning unless project scope/content is small. Without a good understanding of HTML5/CSS3 and the various technologies that enhance the development experience of those two techs you might have some difficulty, it's all fairly basic stuff, there is just quite a bit of it depending on what you're trying to do and how much you care about doing it right vs good enough.

If you're just wanting to use the web browser as a platform for games/apps similar to traditional ones, Canvas/WebGL is better suited for you and the html/css less important. With either of those two technologies your mostly focusing with either JS or Haxe and developing similar to other platforms. Pixi.js is a popular lib that uses WebGL with a Canvas fallback, it also has official Haxe support :) OpenFL also has web targets, though these are more catered towards games than apps far as I know. I've heard of UFront for Haxe but no experience with it, most of my learning involves JS or using JS libs, so I've put Haxe aside for now as I think it might complicate and already complicated workflow :P I could totally be wrong however, that and I'm trying to get a job doing this where they expect JS knowledge and I don't think they'd be too happy with me trying to collaborate by adding Haxe into the mix :(

AngularJS would be a framework you could look into, it's very popular, and at the same time has plenty of hate :P I recall someone creating Haxe support for this framework and putting it on Github. Do you need a framework? I recall vdoms and maybe dom libs for Haxe being discussed in the group some time ago. What sort of features are you looking for?

[Juraj Kirchheim]

From my experience, Haxe + CSS + HTML is an excellent, even ridiculously productive mix. Things you'll need:

1. Learn CSS (mostly about selectors)

2. Get comfy with a web inspector (I personally use Chrome) to learn as you go (you can change style and see the effect in real time, you get autocompletion, etc.).

3. Consider: https://polyfill.io/

4. Learn: https://css-tricks.com/snippets/css/a-guide-to-flexbox/ (unless it has to work in IE8)

5. Use: https://www.npmjs.com/package/autoprefixer

6. Know: https://developer.mozilla.org/en/docs/Web/CSS/box-sizing (I actually go as far as `* { margin: 0; padding: 0; box-sizing: border-box }` for a drastic but effective CSS reset)

7. Consider: http://necolas.github.io/normalize.css/

8. Use: http://lesscss.org/ ... easiest way: http://lesscss.org/#client-side-usage

Most front end frameworks out there are catering to people who don't want to learn CSS or even HTML (not that there is a lot to know about the latter). I advise you to steer clear of them until you can make an informed choice. As Brennan pointed out, it might increase the learning curve somewhat. It's well worth it. HTML and CSS are going to be around for a while. JavaScript silver-bullet-frameworks come and go. Don't waste your time on ephemeral fads.

Best,

Juraj

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Brennan Kinney]

That is a pretty good list :) Just to save Nathan the hassle of figuring out what that all means

3. polyfills/shims add support for modern features older browsers(usually always IE), the linked service is fairly new and looks like a sweet approach(less effort more 'magic')

4. flexbox support is fairly good, you can see browser feature support via http://caniuse.com, flexbox will make content layout far more pleasant :) alternatively look into grid systems(bootstrap/foundation come with these, though there are great focused libs like Susy)

5. autoprefixer is another compatibility tool, it'll save you from having to think about vendor prefixes for browsers in your CSS

6. box-sizing is a style in your CSS that will assist with layout by making your elements more predictable with width values.

7. normalize.css is CSS you'd use prior to the rest to get styling consistency across browsers as they don't always use the same default styles

8. less is a pre-processor for CSS, it lets you write pure CSS but with extra features that'll improve the experience, Sass(an alternative) appears to be industry preference these days.

There is plenty more that could be mentioned, just concentrate on grasping basics for now til you have something functional, 1,2,4 and 6 will be useful immediately though :)

[Jeff Ward]

That is a nice list... for general HTML5 development. So the question then seems to be, how is Haxe typically used? Presumably as JavaScript source replacement? Any other tie-ins? Seems like I read about some Haxe/CSS or Haxe/JSON-schema projects? And are the best practices / examples for interfacing Haxe with existing JavaScript libraries -- some way to define/use JS AMD modules? Are there common JS library bindings? Haxe's jQuery API appears to be just such a binding - aka, type-safe jQuery wrapper?

Basically, what are typical uses of Haxe in an HTML/CSS (non-game) proejct?

I'm in a potentially similar situation as the OP, so this interests me as well.

[Nathan Hüsken]

Hey,

Firstly, wow, thanks for all the detailed information!
Let me answer the questions that have been raised.

> Is it graphics-intensive or does it require
> mostly HTML? Is it a one-page thing, or does it need to use multiple
> URLs
> (i.e. "routing")?

My goal is a web-application as a replacement for an installed software.
It is not very graphics intensive but consists of multiple screens. But
there is only one entry point, so it does not require multiple URLs.
There is no intrinsic "need" for HTML but I also see not reason against it.

So, if I understand Brennan's first mail correctly, he would suggest a
canvas/webgl approach for this. The main part of my app is the gui. Is
this still a good Idea? The only toolkit I four this is
http://www.zebkit.com/

Or (and that is how I interprete Juraj's post) I use html/css for the
GUI. Is the suggestion to (at least at first) use no toolkit but plain
html/css/haxe made javascript?

Again, thanks for all the information!
Nathan

>>> To post to this group haxe...@googlegroups.com <javascript:>

[Philippe Elsass]

No you want to use DOM/CSS unless you are making a game!

[Confidant]

Given that it's only ever going to run in a browser, and it's not graphics-intensive, I would recommend an HTML/CSS approach simply for performance and versatility. Zebra looks good but you'll have to write some Haxe externs for it. Once you choose a UI, it could be coupled with almost any MVC framework for structuring your app. I myself have used Haxe's PureMVC coupled with JQuery externs and the Canadian government's WET/BOEW toolkit to make an in-browser app. The beauty of Haxe is you can pick and choose pieces for the best fit, whether it's JS libraries or Haxe-based ones. It just helps if there's already externs built.

There's been some good progress (here and here) made with AngularJS and Haxe, and there are externs for Bootstrap for UI. That would also take you pretty far if you need a lot of DOM manipulation. I myself am looking for excuses to try Ufront for a project; it is super versatile and can do either browser rendering or server-side rendering.

[Andreas Söderlund]

I highly recommend Mithril for making web apps. Here are the Haxe externs: https://github.com/ciscoheat/mithril-hx

/Andreas

[Brennan Kinney]

I'm a bit averse to solutions like mithril, they've got great performance but you're mixing in html. for basic html usage I guess you wouldn't be too concerned about it. At that point though is there much point besides using any other approach that compiles html/js? For a basic web app, there isn't much need for super performance I'd imagine it's not going to be heavy on rendering. If the projects code were to be transferred/maintained by others, you'd need to onboard to your solution rather than taking someone with a solid web background, if codebase isn't too big or framework/tooling not too complicated might not be an issue. I take it that you can use mithril with Live Reload or BrowserSync?

If you don't have a large audience to cater for, performance isn't critical, no concerns for search engine indexing or screen readers/accessibility, no need for internationalization(i18n), or the many libs/tooling out there for web dev available...then why not stick to Haxe using something like OpenFL? Unless anything I mentioned was required, or you needed to support mobile(browsers not native app)/responsiveness, low bandwidth, etc, perhaps you'd be fine with what you know well already? :) Was there an understanding why the application was being ported to work in the browser? If it's just for online access, then scope/demographic taking what I've said into consideration would answer if you should focus on proper web dev or compile to web(with a basic understanding of what's going on under the hood/output files).

[Andreas Söderlund]

I'm a bit averse to solutions like mithril, they've got great performance but you're mixing in html. for basic html usage I guess you wouldn't be too concerned about it.

Yes, and that's what React does too. I think the realization that an MVC View is actually an object, tightly coupled to its output, is making things simpler, instead of the delusive "decoupling at any cost". For example, when separating the view templates, a language must be invented to make things easier for the front-end developer, as React/Angular/Polymer did. But we're not in the early 00's anymore, where Dreamweaver and WYSIWYG was the way to go. Things turned out to be a bit more complicated. On the front-end today, the UX world of responsive design, animations and complex interactions is making a DSL too limiting. Front-end developers needs to know javascript anyway, so that's one of the reasons I like that the Mithril view templates are written directly in javascript, enabling the full power of a general-purpose language. It has found a nice balance between flexibility and readability too.

A big framework gives you lots of tools and safety at the price of simplicity, which may be just what you need instead. Your system works best when you can solve complex problems with simple tools.

For example, I just wrote a Mithril app that displays ajax data in a table, allows four types of filtering, direct data update through input fields (with friendly error management) and client-side CSV export, all in less than 200 readable lines of Haxe code. I don't think I can do this in other web frameworks and languages, considering my specific needs for this app. I would have searched for some plugin and found a limitation, as it usually is with generic stuff, not to mention conceptual integrity since the creator of the plugin usually have a different idea of structuring than me. That means I have to dive deep into the big framework and the plugin to understand and tweak it, then repeat the process for the other parts of the app. Feels much better to have full control on a slightly lower level in <200 lines, without sacrificing readability either. Keeping things simple is what keeps me happy.

 

At that point though is there much point besides using any other approach that compiles html/js? For a basic web app, there isn't much need for super performance I'd imagine it's not going to be heavy on rendering. If the projects code were to be transferred/maintained by others, you'd need to onboard to your solution rather than taking someone with a solid web background, if codebase isn't too big or framework/tooling not too complicated might not be an issue. I take it that you can use mithril with Live Reload or BrowserSync?

Sure, that works just fine. There's a project for that here: https://github.com/AlexeyGrishin/gulp-livereload-mithril

/Andreas

[Philippe Elsass]

No that's an irresponsible suggestion; using openfl or any game engine is not suited to web apps. Only people who don't know HTML/CSS well enough will advise that. There is a little learning curve, but it's both powerful and productive to use.

Not only have game engines considerable user text input limitations, but more generally users have clearly voiced that they didn't want something that replaces browser rendering like Flash. Unless it's a game of course.

--

To post to this group haxe...@googlegroups.com

[Confidant]

I'm sorry I didn't mention Mithril; it always looked to be easier to learn than Angular.
And yeah, per Philippe's comment, I'd only use OpenFL if there was a chance you'd want to bundle as an app down the road.

[der Raab]

Great list! You need to go the HTML/CSS way and apply a nice logic layer written in Haxe. Haxe is awesome for working with DOM elements. Full type safety - but don't cast HTMLElements. :) And one benefit might be to reuse some validation logic in the backend as well! Just benefits. No drawbacks.