This is the same problem a lot of leaders have in all kinds of work. It is often possible to delegate a task. But if one delegates understanding, one is at a disadvantage when compared to an organization where leadership understands the task.
When I was in charge of companies, I understood the technical tasks, but delegated understanding of things like tax law. This was okay, but I was definitely at a disadvantage compared to companies that could better optimize capital allocation around understanding of tax law.
AI means more humans in every organization are having to learn how to be managers/leaders of these agents. Those who actually understand the work they delegate will maintain an advantage over those who do not.
I am still using XSLT. I have been using it for 26 years. I generate XML documents on the backend and turn them into HTML for various reports. XSLT has a lot of features and power that newer templating languages lack.
Are any of these newer templating languages worth me switching?
Semi-serious suggestion: wrap the files in an (X)HTML page that links to a Javascript file loading a full XML parser compiled to WebAssembly, which then does the full transformation live, in-browser. You wouldn't need to change your templates or your generation logic much if you structure the surrounding skeleton right!
Of course, you'd need to get over the lunacy of loading a full DOM transformation library into the browser DOM.
you also need to get over the fact that this doesn't work while disabling javascript, while built in xslt doesn't need javascript. on the other hand though it's not a big loss given that xslt isn't any safer. anyone who turns off javascript probably ought to have turned of xslt as well.
but that just aside. the last time this was discussed a year ago i actually tried to find a working solution to load xslt through javascript and could not find any.
i only got as far as verifying that js can be loaded from an xml mimetype. xslt implementations in js also exist. what's missing is the wrapper code to load the xslt library and run it over the xml and xslt files.
perhaps now with this seriously being needed by a few sites someone will have the time to get this working.
My thought wasn't so much "do XSLT parsing in Javascript" and more "compile a C program to apply XSLT transformations using emscriptem and embed that". You can probably throw that concept into any slop machine and get a cursed compatibility library out of it.
Their comment isn’t clear if they’re doing the transform on the server before piping it down as HTML, which some implementations have done over the years as it provided access to newer XSLT features that browsers stagnated on.
In an XML document a "processing instruction" can trigger the XSLT processor to transform the document in another format.
So an XML document would be parsed and processed by the XML engine, trigger XSLT processor, which would then trigger again the XML processor again and the HTML processor.
So XSLT processing for XML/XHTML is deeply embedded. Dropping it removes a lot of corner cases that AI is good at exploiting.
The cool thing with a wasm-based xslt implementation is there is no need for the browser vendors to gate-keep it. Just use the implementation you prefer.
Except XSLT dates back to the late 90s. WASM was not even a glint in the eyes of its creators. Mozilla even used XSLT internally to drive the GUI for their browser iirc. I think based on that there is a good reason it was incorporated into browsers.
If they were going to implement it themselves it would be unnecessary to faff around with webassembly. They could just keep the native code implementation that they already have.
The problem is that XSLT has so few users that the browser writers don't want to waste any more time on it. Those few people who wrote their site around it will have to either rewrite it to use something else or add some third party webassembly implementation themselves.
XSLT is not going away, it is only in-browser XSLT which is removed. If you are happy with XSLT there is no need to abandon it. Just perform the transformation on the backend.
Flash went away because Steve Jobs made an impassioned plea to find a better way and follow their humble browser which only had single digit percentages of marketshare at the time.
Flash went away because Steve Jobs made an impassioned plea to find a better way and follow their humble browser which only had single digit percentages of marketshare at the time.
You're half right.
Yes, Jobs killed Flash. But he did it because Flash on mobile was a battery killer. And when the original iPhone came out (one of which I still have), battery technology wasn't as advanced as it is now.
Before I got my wife's hand-me-down iPhone, I had one of the few mobile phones that supported Flash. On the few occasions when I used the web browser, I lived in fear that I'd land on a web site that was using Flash because I knew it would tear through the phone's battery in less than 10 minutes.
Ever notice that the people on HN who pine for the good-ol'-days of Flash only remember games? Never the Flash ads and intrusive videos.
Even for enthusiastic Android vendors who saw it as a differentiating feature from iPhone, Flash still took three years from the iPhone launch to have its first release. Adobe was really in poor shape to port Flash to a new platform. Waiting for them as a vendor to bump their proprietary platform vs integrating support for the features into the browser would have cost years for mobile adoption.
> Adobe was really in poor shape to port Flash to a new platform
I wouldn't say poor. Adobe had its own creative-software empire to up-keep. Photoshop, Illustrator, After Effects, and its web-authoring products gave it enormous influence over creative professionals. Macromedia's Dreamweaver and Flash were serious competitors in web design and interactive media. Adobe needed the missing monopoly cards; Flash, Fireworks and Dreamweaver were them.
Flash was security ridden yes, Flash required a plugin, yes; I don't think supported AppleOS at the time. These could of all been solved but I would agree that to refactor the software would of been an expensive take.
Jobs + HTML5, WebGL, JS all had entered the ring and finished the blow.
I miss it. Growing up with the internet in 2003, 2010's was the end of the wild world web. 2020's was the era of walled gardens for which we now have LLM's for the theme park and we're now entering 2030 where the internet is on fire with creativity now wrung between Yes Ai and No Ai.
Domain name:
lordsephiroth.co.uk
Relevant dates:
Registered on: 18-Nov-2003
My first ever domain name, registered with my pocket money at the age of 13. Hopefully 2040 should bring world peace. One would hope.
Yes and no, canvas was fine for replacing flash, and JS performance was good enough quickly.
Audio however was a crapshoot for years, especially for games.
Even basic WebAudio took until 2015, and the final piece to match Flash being AudioWorklet was only first available in 2018(Chrome) and took until April _2021_ land in Safari.
So before 2021 you needed to either write your own abstractions to support multiple API's with different execution models with so-so capabilties to be somewhat on-par with what Flash provided or even for years resort to simpler solutions (ie just samples).
Nobody uses XSLT and nobody maintains XSLT. You're free to support it in your own browser but it's not reasonable to expect Mozilla to support XSLT any more than it supports VRML.
As with all similar SETI@home approaches, this paper does not address the energy cost.
Yes, we can distribute tasks to idle machines in homes and on office desktops, but it is often much more expensive than sending it to a data center where power is cheaper and the hardware is more efficient.
I think the use of “nazi” is simply sloppy thinking, but if you are genuinely interested in problematic quotes from Musk, he posts to Twitter very often.
This is quite common, you add the private key to some secure hardware module, so that only that device can sign using the certificate, and then use TLS to connect
I get that this is how iMessage works, as I understand it. I am wondering what tradeoffs make Apple decide to use the Secure Enclave versus more mundane certificate infrastructure and how they would make it hard for us to get at this with a debugger if they chose that route.
Yes, and it makes sense to add the stylus/pencil after app developers had to learn how to deal with finger taps only. Apple did the same thing with the original Mac. There were no arrow keys on the first model, so that developers were forced to accommodate the mouse.
A lot of rich men, when younger, say that they will not leave so much of the wealth to their children. Then they get older and realize what other old men realized.
Warren was CEO until 9 months ago. While yes, he's been chairman for 50 years, he's been an exclusive chairman for only 9 months. The role is ambiguous anyways and it's pretty obvious that someone else won't have the authority Warren has. And his son has been a director for 30 years so it's not like he's a new hire
He was chairman and CEO for a long time. Since he has only been a chairman for not that long I don't think it's fair to say that he's been a very active chairman for a long time.
Not enough stakeholders are terrified enough.
If the upside is profit and the maximum downside is losing money, corporations will happily rape the Earth.
The system is working as designed.
reply