Ended up with Ag-Grid after using a couple other data tables in the past and have been using it for 4 years or so. Still the best product in the market in my eyes.
Only you can decide whether it's worth it for you - this depends on how many of its features you can actively use.
I also do not find it crappy, as otherwise written here. API is pretty solid and mighty (still, only ever used it with vanilla JS, not with frameworks - things might feel different with frameworks) and documentation is good enough. Occasionally have to look up stuff in its sourcecode though.
Otherwise: There's an open source version. Unless you need the features marked as "enterprise" features, you can at least try out the integration already. There are some pretty elementary features like row grouping part of the enterprise version, though, so do not assume you'll be able to actually stay on the community edition.
> Node/NPM definitely is on-par with CPAN. But pip isn't even close.
I'll say this as someone who still does more than 80% of his backend work in Perl: This is not true. I wish it was.
CPAN was awesome once. Now it's mainly old. Yes, you will find obscure things which you won't find for Python. At same time, anything interfacing with modern stuff is often only 40% done in CPAN or not at all compared to the Python, PHP or JavaScript eco system. Not talking about data science stuff here, where Python gained a huge lead - simply have a look at how much support you get nowadays in CPAN for interfacing with, for example, current web api versions or interfacing with third party files like docx, pdf, excel, odt. If there's support for things at all, it is so far far far behind to what libs in other ecosystems have to offer, most of the time.
It simply shows that the crowd implementing business applications went elsewhere, so anything in that area seems stuck in the 2000 to 2010s in CPAN.
Nice little tool. Not entirely sure what kind of JSON it supports. For a test I simply threw a file I had laying around at it (which basically contained a data array hidden in an object, a not sooo exotic format) and it simply did not react at all, no error message or any hint to what it supports.
The author of the blog post seems to mean what also often was called "linking" on the C-64: Taking some thing which is supposed to occupy different memory areas and used to consist of multiple files to a single file which makes sure everything's at the right memory locations with a small bit of bootstrap code.
Think BASIC plus supporting machine language code, or code plus assets.
If you take it to the extreme, there was a thing called an IFFL loader (e.g. https://github.com/luigidifraia/iffl-system ) which allows you to put a whole file system with multiple streams into a single C64 file. This had some advantages at friction points like where when the file had to switch location between BBSes and Disk Swappers as you didn't need create disk images first and could simply copy the single part files. Always used to be somewhat exotic though when I still was in the C64 scene - not sure how it's nowadays.
I am skeptical that this can be repeated at all nowadays the way we had it in the 80ies and 90ies (or even earlier, but I'm an 80ies child, haha). At best with some kind of limited hardware or in some narrow area like writing games. Also, surely not with Scratch. Scratch is, what you give a 5 year old to learn some concepts in my opinion. My children were appalled by it when they became 10 cause it's "baby stuff". At least those kids interested in programming.
The thing in the 80ies and early 90ies was, that you could actually, as a kid, compete with something professional and have total control over the outcome, if you had a bit of talent in any area. This was unbelievably motivating.
Where can one person or two people nowadays seriously compete with professionals and have serious control over the outcome? If at all in the area, where you will actually find kids today: Roblox games, Unity games, anything with a finished engine, where they can focus on the content itself because anything else will simply be unrealistically large effort.
Also, limited retro hardware things might work, I do not know. For me, if I was a child again, they would not work because these are things that are too limited - I would always know there are really powerful PCs with all 3d stuff around. As said above, the fantasy of being able to do anything some software company could do was what motivated me in the 80ies/early 90ies, so I'd rather probably teach myself some game engine, too, because that allows me to live the state-of-the-art fantasy. At least I assume that.
Another thing old hardware did, by the way, which modern hardware does not, is that it launched people on a programming learning path immediately, if they desired to successfully use it. You could not use a C64 without learning at least a tiny little bit of basic.
> I am skeptical that this can be repeated at all nowadays
For me I think it was more of an access issue that caused me to want to do it. Once you were done with the 2-3 games you might have. You started getting the mags from the library and typing things in and hoping it would work (no typos!). Just so you could get another game.
Along the way you picked up tons of low level programming. The computers of the time were 'batteries included' usually including some form of BASIC and then an escape into the world of ASM if you knew the right incantations. After awhile you would find hey this programming thing is sort of fun too.
But today a kid has some access to things like what you point out. But however they also have access to thousands of other games for a very reasonable price. The older systems you better be committed to getting that game you wanted as they were decently priced high enough you had to shell out a decent amount of cash to get it. With free to play and thousands of low priced games plus the massive catalogs of older systems. Getting a game is now 'easy' and cheap.
On my old computers apple2, c64 and ti994a the prompt to launch things was a programming prompt. With the GUI world there is no prompt just files and icons. Getting an IDE setup on most modern systems is not hard but it is an extra step (and fiddly with some of them). You are then presented with a blank canvas but you have to know how to fill out the form to get it to do anything at all.
Could we replicate the old systems? Totally. Would anyone actually use them? Not so much as to 'get things done' the GUI is way better. There is a step missing if we want to replicate what we had. But is 'what we had' the right way to program? That I am not convinced of. Pretty sure if I said 'yes' that would be my bias of using it that way showing. We would have to have a different way that still brings people up step by step we had but fits into the current landscape of computers.
While everyone here seems to talk about the epub angle to the story, there's also simply the deeper story here, that "the web's" handling of paged media and the CSS paged media specs (to which his epub problem is related) is a never ending shitshow. Not only for epubs, for everybody who actually wants to print to real paper, too, ideally with a working cross browser solution.
Mistake is largely not in the specs, but in the lack of support for them. Page breaking controls, weirdly breaking tables, lack of access to area outside the page box to influence headers/footers without weird hacks etc. etc. For printing, the 1990ies never ended.
This leads to the bizarre situation where basically everyone who has semi complex printing needs in web applications will create PDF and then print that - and for creating those PDFs, often HTML to PDF conversion is used, just with actually implemented CSS for paged media. Which again proves that the spec is at least 99% there, if somebody would just kindly implement it in a browser, too.
Won't be more complex than having the latest WebGL whatever thing in your browser engine ;-)
Some months ago I wanted to format/print some documents, and given the existing tooling I had I decided to try the html->pdf route. I fully agree is a shitshow. The way things break across pages is hard to fix even when hand-tuning the html itself (not just by working it around with css) to avoid content being cut across margins and pages no matter what. I've found chrome to be "less bad", but still unusable. Column handling is even a bigger joke.
In the end I exported the document to libreoffice, and got something way more usable in a few hours just by editing the styles than whatever I was able to do in days of fiddling with html+browser.
iBooks on apple might get a pass as it doesn't need to paginate, but truth be told it seems that epub/ebooks and ereaders in general are being targeted at novels and romance, where form factor, typesetting and formatting doesn't matter that much.
I have access to ebooks through my local library and there's no way I would use, let alone buy, any technical ebook.
Not to mention, I've seen a steady average decline in the quality of printed media in general over the last ~15 years. A lot less attention is put in the typesetting and layout. Even the print quality itself is lower, which I think is due to the smaller and cheaper print runs being done now also for more popular titles.
I thought book quality started going downhill circa 1990.
I am a fan of the old mass market paperbacks. These had a reputation of being low quality books back in the day because they are cheap and not super-durable but I think they are high quality from a Deming point of view because they are made by a process that is highly repeatable. Circa 2000 I thought my 1970s paperbacks were in great shape, but 2010 they were seriously yellowing.
I just looked at my bookshelf and found a '59 James Blish anthology that I bought for 50 cents maybe ten years ago, it is in "poor" condition and will probably crack if I read it without taking great care. Next to that I found a copy of Galbraith's The Affluent Society from 1958 which is perfectly usable except I'd be worried about the cover coming off. A Frank Herbert book from '68 is stained but in great shape other than the cover also being at risk. A '74 Herbert book is a touch discolored but has no problems at all.
(My collection includes not just science fiction of that era but also both self-help and serious books on psychology as well as books about science, politics, social sciences, etc. Government reports about inflation or race relations would be published as mass market paperbacks. You could get Plato and Sartre and Freud and the rest of the Western literary heavyweights)
The construction, materials, process, and such were repeatable enough that they even fail consistently. Not permanent, but 50 years is not bad. The right size to go in a purse or side pocket of a backpack (e.g. part of the loadout of a bibliomaniac who has 12 books in his backpack) I've got to find a good way to reinforce the cover (adhesive tape?)
Those are no longer produced, today it is trade paperbacks. There is wide variation in the dimension, construction, materials and processes for these. You sometimes find a trade paperback that is beautiful, strongly constructed and printed on acid free paper. Others you pay $50 for and the binding breaks the first time you lay the book open on the table.
Might depend on the age and or brand of the tape - I've seen old tape (30+ years maybe) that has yellowed. I have a 15 years old book at home with some tape and it's okay, except for the tape that wasn't in contact with the book (which is yellowed).
I think being able to format a page just for printing, esp. with HTML/CSS itself is a killer feature and is gigantically underestimated.
I understand that printers are Satan incarnate and runs on concentrated sins of cost cutting engineers, and nobody has time to read that 1.5 page article someone wrote by giving proper effort, but scientific articles, books, nice blog posts we want to delve in, etc. are real and regardless on the substance they run on, printers are real things and they are used nevertheless.
The tendency to assume that everyone is running on high end laptops and cutting edge, network connected tablets is making me angry sometimes. Implementing features like this will make many programmers' life easier who need to be able to generate and print reports from their web applications, too.
It's not only about books and shrewd people who want to print a blog post and study/read that on a table or wherever.
Completely agree - I wrote a book that had some specific layout requirements in HTML, and while it was easier to get something up and running than LaTeX, getting the printing part right was very painful (not least of all because no browsers seem to support things like page numbering).
I can partly understand the poster above: Some people (including me) for example want and have to use JavaScript, but simply don't want to get dragged into that whole node.js/npm ecosystem for various reasons.
I avoid any tool which forces me to pull in a gazillion npm packages, while I gladly use esbuild for example because it looks and feels like a nice little compact tool.
I feel the same way about python, but I don’t blame python authors for using the python ecosystem to write python tools when I am forced to use a little python. I consider python to be an essential part of any build system since it’s used in so many places, as much as I don’t like it.
Maybe the problem people have is that node/npm are becoming a similarly “essential” build system piece much like python. That much I can certainly understand.
And how would you test whether the collapse has taken place? This does not work. You either measure something and thereby collapse it, or you do not touch the stuff. You cannot find out via measurement whether the other side measured already.
Only you can decide whether it's worth it for you - this depends on how many of its features you can actively use.
I also do not find it crappy, as otherwise written here. API is pretty solid and mighty (still, only ever used it with vanilla JS, not with frameworks - things might feel different with frameworks) and documentation is good enough. Occasionally have to look up stuff in its sourcecode though.
Otherwise: There's an open source version. Unless you need the features marked as "enterprise" features, you can at least try out the integration already. There are some pretty elementary features like row grouping part of the enterprise version, though, so do not assume you'll be able to actually stay on the community edition.
reply