Google Summer of Code: BlazeHTML RFC

older
Re: Can someone post/point to some...

Jasper Van der Jeugt

27 May 2010 27 May '10

3:16 a.m.

Dear all, BlazeHtml started out on ZuriHac 2010. Now, Jasper Van der Jeugt is working on it as a student to Google Summer of Code for haskell.org. His mentors are Simon Meier and Johan Tibell. The goal is to create a high-performance HTML generation library. In the past few weeks, we have been exploring the performance and design of different drafts of this library. Now, the time has come to ask some questions to the Haskell community — more specifically the future users of BlazeHtml as well as current users of other HTML generation libraries. We have written an RFC to gather feedback from the community: HTML version: http://jaspervdj.be/posts/2010-05-27-blazehtml-rfc.html Plain version: http://github.com/jaspervdj/BlazeHtml/raw/develop/doc/RFC.lhs The easiest way of sending us feedback, comments or criticism is replying to the haskell-cafe thread here. Alternatively, drop a comment at the bottom of the HTML version or at reddit. Looking forward to your feedback, Kind regards, Simon Meier Jasper Van der Jeugt

Show replies by date

Michael Snoyman

27 May 27 May

3:55 a.m.

New subject: [Haskell-cafe] Google Summer of Code: BlazeHTML RFC

Two comments: * The exclamation point seems good enough for attributes. I copied that for Hamlet as well. * If you're standardizing on UTF-8, why not support bytestrings? I'm aware that a user could shoot him/herself in the foot by passing in non-UTF8 data, but I would imagine the performance gains would outweigh this. My recent benchmarks on the BigTable benchmark[1] imply a huge performance gap between ByteStrings and other contenders. As we've discussed before, I think combining BlazeHtml and Hamlet would be very nice, though I'm dubious that a BlazeHtml backend for Hamlet would be faster than a raw backend. Looking forward to hearing more progress, good luck! Michael [1] http://www.snoyman.com/blog/entry/bigtable-benchmarks/ On Thu, May 27, 2010 at 10:16 AM, Jasper Van der Jeugt wrote:

...

Dear all,

BlazeHtml started out on ZuriHac 2010. Now, Jasper Van der Jeugt is working on it as a student to Google Summer of Code for haskell.org. His mentors are Simon Meier and Johan Tibell. The goal is to create a high-performance HTML generation library.

In the past few weeks, we have been exploring the performance and design of different drafts of this library. Now, the time has come to ask some questions to the Haskell community — more specifically the future users of BlazeHtml as well as current users of other HTML generation libraries.

We have written an RFC to gather feedback from the community:

HTML version: http://jaspervdj.be/posts/2010-05-27-blazehtml-rfc.html Plain version: http://github.com/jaspervdj/BlazeHtml/raw/develop/doc/RFC.lhs

The easiest way of sending us feedback, comments or criticism is replying to the haskell-cafe thread here. Alternatively, drop a comment at the bottom of the HTML version or at reddit.

Looking forward to your feedback, Kind regards, Simon Meier Jasper Van der Jeugt _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Bas van Dijk

4:38 a.m.

New subject: [Haskell-cafe] Google Summer of Code: BlazeHTML RFC

Q14: Do you see any problems with respect to integrating BlazeHtml in your favourite web-framework/server? How about also providing an enumerator back-end? http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite... Then your library can integrate more easily with the snap framework: http://snapframework.com Regards, Bas

Jasper Van der Jeugt

4:48 a.m.

New subject: [Haskell-cafe] Google Summer of Code: BlazeHTML RFC

Hey Bas,

...

How about also providing an enumerator back-end? http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite...

Then your library can integrate more easily with the snap framework: http://snapframework.com

Sure, I can do that. But I already tested integration with the snap framework, the best path here seems to call the `writeLBS` function from the snap framework on the `L.ByteString` that BlazeHtml produces (`writeLBS` internally uses an enumerator). Kind regards, Jasper Van der Jeugt On Thu, May 27, 2010 at 10:38 AM, Bas van Dijk wrote:

...

Q14: Do you see any problems with respect to integrating BlazeHtml in your favourite web-framework/server?

How about also providing an enumerator back-end? http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite...

Then your library can integrate more easily with the snap framework: http://snapframework.com

Regards,

Bas

Bas van Dijk

5:36 a.m.

New subject: [Haskell-cafe] Google Summer of Code: BlazeHTML RFC

On Thu, May 27, 2010 at 10:48 AM, Jasper Van der Jeugt wrote:

...

...
How about also providing an enumerator back-end? http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite...

Then your library can integrate more easily with the snap framework: http://snapframework.com

Sure, I can do that. But I already tested integration with the snap framework, the best path here seems to call the `writeLBS` function from the snap framework on the `L.ByteString` that BlazeHtml produces (`writeLBS` internally uses an enumerator).

I think it's worth analyzing if using enumerators directly gives a significant performance improvement over converting from lazy ByteStrings. Looking a the conversion functions in the snap framework it looks like we can avoid some intermediate lists for one: writeLBS :: L.ByteString -> Snap () writeLBS s = addToOutput $ enumLBS s addToOutput :: (forall a . Enumerator a) -> Snap () addToOutput enum = modifyResponse $ modifyResponseBody (>. enum) enumLBS :: (Monad m) => L.ByteString -> Enumerator m a enumLBS lbs iter = foldM k iter enums where enums = map (enumPure1Chunk . WrapBS) $ L.toChunks lbs k i e = e i -- from iteratee: enumPure1Chunk :: (SC.StreamChunk s el, Monad m) => s el -> EnumeratorGM s el m a enumPure1Chunk str iter = runIter iter (Chunk str) >>= checkIfDone return Regards, Bas

Alberto G. Corona

7:08 a.m.

New subject: [Haskell-cafe] Google Summer of Code: BlazeHTML RFC

As a user, I have too many HTML generators, a few of them with Ajax and none with server-side event handling (like ASPX or JSPX). Ajax is complicated but server side event handling is what I really miss because it is simple from the user point of view, my ervents could be handled in haskell code rather than in javaScript and I implicitly could use the advantages of dinamic HTML and Ajax without the need to know them at all. Imagine a dynamic Web application with 100% haskell code made with dynamic widgets created by third party developers. So, anyone want to create a HTML templating system with server side event handling? It is not terribly hard to do. (I refer to ASP.NET documentation or the JavaServer Faces framework). By the way, I vote for XML templating or else, combinator templating that produce XHML templating because it can be handled by a future graphical IDE. 2010/5/27 Jasper Van der Jeugt

...

Hey Bas,

...
How about also providing an enumerator back-end?

http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite...

...
Then your library can integrate more easily with the snap framework: http://snapframework.com

Sure, I can do that. But I already tested integration with the snap framework, the best path here seems to call the `writeLBS` function from the snap framework on the `L.ByteString` that BlazeHtml produces (`writeLBS` internally uses an enumerator).

Kind regards, Jasper Van der Jeugt

On Thu, May 27, 2010 at 10:38 AM, Bas van Dijk wrote:

...
Q14: Do you see any problems with respect to integrating BlazeHtml in your favourite web-framework/server?

How about also providing an enumerator back-end?

http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite...

...
Then your library can integrate more easily with the snap framework: http://snapframework.com

Regards,

Bas

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Matt Parker

12:19 p.m.

New subject: [Haskell-cafe] Google Summer of Code: BlazeHTML RFC

Blaze HTML looks wonderful to me (especially with the do notation), and better then Hamlet for one reason: writing idiomatic haskell for stuff like this: ul $ forM_ [1, 2, 3] (li . string . show) instead of the Hamlet style: %ul $forall children.person child %li $child$ which, i don't know, for some reason, made me feel like i was back in PHP land. -matt The problem i have with Hamlet is the "forAll x xs" stuff On Thu, May 27, 2010 at 7:08 AM, Alberto G. Corona wrote:

...

As a user, I have too many HTML generators, a few of them with Ajax and none with server-side event handling (like ASPX or JSPX). Ajax is complicated but server side event handling is what I really miss because it is simple from the user point of view, my ervents could be handled in haskell code rather than in javaScript and I implicitly could use the advantages of dinamic HTML and Ajax without the need to know them at all.

Imagine a dynamic Web application with 100% haskell code made with dynamic widgets created by third party developers.

So, anyone want to create a HTML templating system with server side event handling? It is not terribly hard to do. (I refer to ASP.NET documentation or the JavaServer Faces framework).

By the way, I vote for XML templating or else, combinator templating that produce XHML templating because it can be handled by a future graphical IDE.

2010/5/27 Jasper Van der Jeugt

...
Hey Bas,

...
How about also providing an enumerator back-end?

http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite...

...
Then your library can integrate more easily with the snap framework: http://snapframework.com

Sure, I can do that. But I already tested integration with the snap framework, the best path here seems to call the `writeLBS` function from the snap framework on the `L.ByteString` that BlazeHtml produces (`writeLBS` internally uses an enumerator).

Kind regards, Jasper Van der Jeugt

On Thu, May 27, 2010 at 10:38 AM, Bas van Dijk wrote:

...
Q14: Do you see any problems with respect to integrating BlazeHtml in your favourite web-framework/server?

How about also providing an enumerator back-end?

http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite...

...
Then your library can integrate more easily with the snap framework: http://snapframework.com

Regards,

Bas

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Matt Parker

2:31 p.m.

New subject: [Haskell-cafe] Google Summer of Code: BlazeHTML RFC

will it be possible to easily interleave IO values into the HTML? like instead of the [1,2,3] ul $ forM_ [1, 2, 3] (li . string . show) what if it was a function that returned IO [1,2,3] (maybe 1,2,3 came out of a database). will the forM_ handle that OK? On Thu, May 27, 2010 at 12:19 PM, Matt Parker wrote:

...

Blaze HTML looks wonderful to me (especially with the do notation), and better then Hamlet for one reason: writing idiomatic haskell for stuff like this:

ul $ forM_ [1, 2, 3] (li . string . show)

instead of the Hamlet style:

%ul $forall children.person child %li $child$

which, i don't know, for some reason, made me feel like i was back in PHP land.

-matt

On Thu, May 27, 2010 at 7:08 AM, Alberto G. Corona wrote:

...
As a user, I have too many HTML generators, a few of them with Ajax and none with server-side event handling (like ASPX or JSPX). Ajax is complicated but server side event handling is what I really miss because it is simple from the user point of view, my ervents could be handled in haskell code rather than in javaScript and I implicitly could use the advantages of dinamic HTML and Ajax without the need to know them at all.

Imagine a dynamic Web application with 100% haskell code made with dynamic widgets created by third party developers.

So, anyone want to create a HTML templating system with server side event handling? It is not terribly hard to do. (I refer to ASP.NETdocumentation or the JavaServer Faces framework).

By the way, I vote for XML templating or else, combinator templating that produce XHML templating because it can be handled by a future graphical IDE.

2010/5/27 Jasper Van der Jeugt

...
Hey Bas,

...
How about also providing an enumerator back-end?

http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite...

...
Then your library can integrate more easily with the snap framework: http://snapframework.com

Sure, I can do that. But I already tested integration with the snap framework, the best path here seems to call the `writeLBS` function from the snap framework on the `L.ByteString` that BlazeHtml produces (`writeLBS` internally uses an enumerator).

Kind regards, Jasper Van der Jeugt

On Thu, May 27, 2010 at 10:38 AM, Bas van Dijk wrote:

...
Q14: Do you see any problems with respect to integrating BlazeHtml in your favourite web-framework/server?

How about also providing an enumerator back-end?

http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite...

...
Then your library can integrate more easily with the snap framework: http://snapframework.com

Regards,

Bas

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Jasper Van der Jeugt

3 Jun 3 Jun

3:37 a.m.

New subject: [Haskell-cafe] Google Summer of Code: BlazeHTML RFC

On Thu, May 27, 2010 at 8:31 PM, Matt Parker wrote:

...

will it be possible to easily interleave IO values into the HTML? like instead of the [1,2,3]

ul $ forM_ [1, 2, 3] (li . string . show)

what if it was a function that returned IO [1,2,3] (maybe 1,2,3 came out of a database). will the forM_ handle that OK?

Depends on how you write the code. More precisely, it depends on in which monad the forM_ takes place. Also, I would not recommend interleaving IO values into the HTML, because the HTML is pure -- you usually don't want to mix that with IO. I'd rather write something like: numbers <- getFromDataBase return $ ul $ forM_ numbers (li . string . show) Or it could be possible to store your templates in a separate modules, and they would all have a pure type signature: templateX :: Arg1 -> Arg2 -> Html a I think this would be the preferred way, because it allows a separation between the pure View code and the IO-interleaved Controller code in a web application. Kind regards, Jasper Van der Jeugt On Thu, May 27, 2010 at 8:31 PM, Matt Parker wrote:

...

will it be possible to easily interleave IO values into the HTML? like instead of the [1,2,3]

ul $ forM_ [1, 2, 3] (li . string . show)

what if it was a function that returned IO [1,2,3] (maybe 1,2,3 came out of a database). will the forM_ handle that OK?

On Thu, May 27, 2010 at 12:19 PM, Matt Parker wrote:

...
Blaze HTML looks wonderful to me (especially with the do notation), and better then Hamlet for one reason: writing idiomatic haskell for stuff like this:

ul $ forM_ [1, 2, 3] (li . string . show)

instead of the Hamlet style:

%ul $forall children.person child %li $child$

which, i don't know, for some reason, made me feel like i was back in PHP land.

-matt

On Thu, May 27, 2010 at 7:08 AM, Alberto G. Corona wrote:

...
As a user, I have too many HTML generators, a few of them with Ajax and none with server-side event handling (like ASPX or JSPX). Ajax is complicated but server side event handling is what I really miss because it is simple from the user point of view, my ervents could be handled in haskell code rather than in javaScript and I implicitly could use the advantages of dinamic HTML and Ajax without the need to know them at all. Imagine a dynamic Web application with 100% haskell code made with dynamic widgets created by third party developers. So, anyone want to create a HTML templating system with server side event handling? It is not terribly hard to do. (I refer to ASP.NET documentation or the JavaServer Faces framework). By the way, I vote for XML templating or else, combinator templating that produce XHML templating because it can be handled by a future graphical IDE.

2010/5/27 Jasper Van der Jeugt

...
Hey Bas,

...
How about also providing an enumerator back-end?

http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite...

Then your library can integrate more easily with the snap framework: http://snapframework.com

Sure, I can do that. But I already tested integration with the snap framework, the best path here seems to call the `writeLBS` function from the snap framework on the `L.ByteString` that BlazeHtml produces (`writeLBS` internally uses an enumerator).

Kind regards, Jasper Van der Jeugt

On Thu, May 27, 2010 at 10:38 AM, Bas van Dijk wrote:

...
Q14: Do you see any problems with respect to integrating BlazeHtml in your favourite web-framework/server?

How about also providing an enumerator back-end?

http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite...

Then your library can integrate more easily with the snap framework: http://snapframework.com

Regards,

Bas

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Deniz Dogan

29 May 29 May

9:24 a.m.

2010/5/27 Jasper Van der Jeugt :

...

Dear all,

BlazeHtml started out on ZuriHac 2010. Now, Jasper Van der Jeugt is working on it as a student to Google Summer of Code for haskell.org. His mentors are Simon Meier and Johan Tibell. The goal is to create a high-performance HTML generation library.

In the past few weeks, we have been exploring the performance and design of different drafts of this library. Now, the time has come to ask some questions to the Haskell community — more specifically the future users of BlazeHtml as well as current users of other HTML generation libraries.

We have written an RFC to gather feedback from the community:

HTML version: http://jaspervdj.be/posts/2010-05-27-blazehtml-rfc.html Plain version: http://github.com/jaspervdj/BlazeHtml/raw/develop/doc/RFC.lhs

The easiest way of sending us feedback, comments or criticism is replying to the haskell-cafe thread here. Alternatively, drop a comment at the bottom of the HTML version or at reddit.

Looking forward to your feedback, Kind regards, Simon Meier Jasper Van der Jeugt _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Q2: What HTML standards should the library at least support? HTML 4 Transitional XHTML 1.0 Transitional XHTML 1.0 Strict I don't care if frameset doctypes are supported. Q3: Which HTML version would you preferably use? HTML 4 Transitional. Please, don't make HTML 4 Strict the default. I personally haven't used it in years and don't really know any professional web developer that uses it today. -- Deniz Dogan

Matt Parker

1:34 p.m.

...

Q3: Which HTML version would you preferably use?

HTML 5. google summer of code should be about pushing the new and exciting.

Gregory Collins

2:05 p.m.

New subject: [Haskell-cafe] Re: Google Summer of Code: BlazeHTML RFC

Matt Parker writes:

...

Q3: Which HTML version would you preferably use?

HTML 5. google summer of code should be about pushing the new and exciting.

Yes, definitely, this should be the default IMO. G -- Gregory Collins

Jochem Berndsen

30 May 30 May

10:27 a.m.

New subject: [Haskell-cafe] Re: Google Summer of Code: BlazeHTML RFC

On 05/29/2010 08:05 PM, Gregory Collins wrote:

...

Matt Parker writes:

...
Q3: Which HTML version would you preferably use?

HTML 5. google summer of code should be about pushing the new and exciting.

Yes, definitely, this should be the default IMO.

+1 -- Jochem Berndsen | jochem@functor.nl

Tom Lokhorst

10:35 a.m.

New subject: [Haskell-cafe] Re: Google Summer of Code: BlazeHTML RFC

+1 for HTML5. Also, I suggest focussing on the html serialization of HTML5. The xml serialization (XHTML5) is only useful in an XML environment. For such environments pure xml libraries are more appropriate. Besides, I like html syntax better. On 30 May 2010 16:27, Jochem Berndsen wrote:

...

On 05/29/2010 08:05 PM, Gregory Collins wrote:

...
Matt Parker writes:

...
Q3: Which HTML version would you preferably use?

HTML 5. google summer of code should be about pushing the new and exciting.

Yes, definitely, this should be the default IMO.

+1

-- Jochem Berndsen | jochem@functor.nl _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Jasper Van der Jeugt

2 Jun 2 Jun

11:26 a.m.

On Sat, May 29, 2010 at 7:34 PM, Matt Parker wrote:

...

...
Q3: Which HTML version would you preferably use?

HTML 5. google summer of code should be about pushing the new and exciting.

I can say that HTML 5 will definitely be supported. We use some sort of metacode to generate Haskell combinators from a simple, formal HTML specification. Thus, it should be possible to support HTML 5, HTML 4 Strict and HTML 4 Transitional easily. Kind regards, Jasper Van der Jeugt

5465

Age (days ago)

5472

Last active (days ago)

List overview

Download

14 comments

9 participants

participants (9)

Alberto G. Corona
Bas van Dijk
Deniz Dogan
Gregory Collins
Jasper Van der Jeugt
Jochem Berndsen
Matt Parker
Michael Snoyman
Tom Lokhorst