September 30, 2019
Posted 2019-09-30
Blog
Articles- terminal.d gets clipboard functions, ldc 1.20 out.
- DConf keynote speaker announced: Lua architect Roberto Ierusalimschy, Named args DIP discussed
- February 3, 2020
- Adam's terminal suite explained
- Understanding mixin templates, terminal.d improvements
- My attribute-by-default proposal. Also dmd 2.090 came out.
- DConf 2020 announced: June 17-20 in London. @safe by default debated. Adam did: Android, JNI, WebSocket in arsd libs
- tar.xz, --DRT tip, dom bug fixes, more Android and JNI, link to old phobos docs
- LDC 1.19 - Android, AVR. My rant on tests, update on JNI and COM.
- Walter's string interpolation proposal is OK but not great. My Android thing nearing beta release. dub downtime explained.
- Android project update, introduction to arsd.jni
- New pattern about interface contracts
- Adam shares Windows console secrets - DO NOT USE chcp!!
- Adam's rant on benchmarks
- Socket tutorial
- November 4, 2019
- October 28, 2019
- arsd package updates, forum nonsense
- Update on Android
- Adam does iOS "goodbye world"
- September 30, 2019
- D turns 20, Adam rants on software freedom
- Named arg DIPs and my thoughts on code organization
- September 9, 2019
- I wrote about mixin templates vs string mixins on Stack Overflow
- August 26, 2019
- Bug bounty in D again - my hot take, on reusing code, a fun picture, my tentative plan for the next month
- Time invested is worth a lot
- cgi.d's new scheduler, static this tricks
- July 29, 2019
- July 22, 2019
- Solving vs managing problems
- A big week in the arsd repo
- July 1, 2019
- June 24, 2019
- June 17, 2019
- CRTP thoughts, named arguments DIP review, DConf videos now on youtube
- musings on hybrid CT/RT tests, some more progress on new web framework
- a little more webassembly
- May 20, 2019
- Adam's string interpolation proposal
- DMD 2.086 live, GCC 9 with D support formally released, DConf coming soon, links to posts on builder pattern and disallowing implicit conversions with templates, and 2d array op overloads
- template constraint error improvements coming?
- dmd 2.086 beta, dstep 1.0 released, Adam works on memory usage
- obj-c and webassembly report, tips on is expressions linked.
- new ldc, new dmd, dpp on the blog
- D's future discussed in forums
- LDC beta, DConf blog link, Adam introduces gamehelpers.d
- March 18, 2019
- LDC 1.15.0-beta1, responsive design rant
- dmd 2.085.0 released
- Obj-C interop and D without druntime code to copy/paste
- dmd beta, more info coming next time, demo of new web framework initial prototype
- automatic web interface discussion, reflection tips and tricks
- Adam busy with weather and a move, lots of community announcements
- January 28, 2019
- Working on official blog 2018 retro, C++ new wrapped, dmd reading zips?
- dmd obj-c growing, Adam static foreaches an interface to RPC
- dmd 2.084, hope for future, but busy non-D week for me
- IDE tools released, my cgi.d gets new features
- DConf announced, tip, Adam rants: mouse trap
- This Week in D is back!
Another LDC beta, and my thoughts on the PHP to D blog post ideas.
Core D Development Statistics
In the community
Community announcements
See more at the announce forum.
Adam's thoughts
HTML generation by objects
One of the controversies I saw about the blog post this week was using DOM functions to generate or populate HTML templates. I like this approach, in fact, I have been using it for a long time now myself! And even my new webtemplate.d module, while appearing to be string-based on the outside, is actually DOM based on the inside.
HTML can be represented as a string, but it isn't actually a string. Forgetting this is what leads to cross-site scripting (also known as XSS) vulnerabilities among other problems like simply broken websites. (I once had a form that would randomly fail to submit. The root cause? The submit button ended up on the outside of the </form> tag. Whether it worked or not now depended on factors that made it appear quite randomly.) Using strings makes these problems very easy, whereas using a DOM representation makes these things harder, if not impossible.
Template languages mitigate this somewhat by at least HTML encoding dynamic elements by default, and truth be told, this actually does a decent job! But DOM based stuff can do even better:
Some of these possibilities can be done with strings, too (a general pattern; there is rarely only one way to do something) - you can also run validators on the output, check links, etc., but by the time they are strings you have lost information. Some can be regained (ironically, often by parsing it back into a dom lol), but the definitive original data is now gone.
What about separation of concerns?
The most common counterargument to DOM templates is separation of concerns: the fear that DOM manipulation puts too much of the view logic in the main application code. I have to confess, I've done quite a bit of that myself. dom.d makes it so easy it is tempting to put everything right there in the D code.
But, it is also quite easy to separate things just like any other template system, if not even better. My webtemplate.d is one attempt at merging the best of both worlds: it looks like a string system on the outside (similar to asp, erb, etc.), but on the inside still uses a DOM based system. When you write <a href="<%= link %>">, it isn't just inserting a string at a character position, but rather knows to set the value of the link's href attribute to the value of the variable link.
Even without that, a dom system can work on id, class, or data-* attributes and achieve a high level of decoupling. You can define custom tags, too, as well as as much or as little manipulation DSL as you like. Indeed, the Javascript frameworks React and Angular work this way, in principle. Both are integrated into the dom concept instead of treating it as strings mixed with code.
Of course, you could also just argue the server side is just generating a semantic description of the data, then the template lays it out based in ID tags (or whatever), and then the CSS achieves visual separation.
It depends on how specifically you use it.
Rewrites vs fixes
Another common criticism of seeing wins in D is the argument that you can have those same wins in other languages, that the rewrite is unnecessary.
First, I'd counter on empirical grounds: if the old code was so easy to fix, why didn't it happen there? Whatever the reason, this is an interesting observation. Just, of course, this also needs to be weighed against the other frequent empirical observation, that the rewrites (much like the code they are replacing probably did) often go over budget and behind schedule.
But second, I'd say rewriting generally makes it possible to correct big mistakes and cancel a lot of technical debt, while slimming down with lessons learned from use. (If you actually finish them - a big temptation is to try to do too much and that breaks you.)
And in particular, using D in general gives a benefit in enabling experimentation. Walter Bright wrote about this back when he was writing his Warp preprocessor - in his case, using the pipeline programming paradigm helped him make larger algorithmic changes during his benchmarking iterations. I find D's static checks and metaprogramming facilities help give me the confidence to make changes with the right mix of customization and centralization.
So yes, in theory, you can usually get he same wins in other languages that D can do, but I'd argue that the process of getting there is easier in D.