We have been using it for 3 years now at a small company. There were some minor bugs in the past (mainly UI related), but in general it is a very good replacement for Trello.
We run it in a Docker container with LDAP integration so that people can log in with their Windows accounts. The operating of it has been very straightforward.
> It's like writing shitty PHP code without templates.
For me, it's the other way around. I feel like you can still separate the logic and markup, but instead of the template engine syntax you can just JavaScript.
From the top of my head, I can at least remember six template engines' syntax I've learned: Smarty (PHP), Mustache, Blade (PHP), EJS, Angular and another custom template engine. When I tried React I was so happy that I did not have to learn another template syntax as it all was just JavaScript.
Another template engine syntax? No, thank you. I stick to React.
To be fair, JSX has its own idiosyncracies too for templating, such as className, htmlFor, and the obnoxious attribute name for dynamically inserted html. It is not immune to the criticism that it requires learning.
Those names have nothing to do with JSX or React, they're the actual properties you're setting. JS properties don't map 1:1 to HTML attributes: while for example the "src" attribute is controlled using the "src" property, the "for" attribute is controlled using the "htmlFor" property, and the "class" attribute with the "className" property. All React is doing is setting the properties you tell it to.
(The reason for the name change is that old versions of JS couldn't use keywords - like "for" and "class" - as property names.)
I agree. Those examples have nothing to do with learning a new template syntax, it's simply the API of React.Component.
Granted, there is still some syntax you need to learn for JSX, but it's very little. If you already know HTML's syntax, the only new things I can think of are the curly braces for using JS expressions as prop values (you also need to know what a JS expression is, lest you try to use an if statement), and spread attributes.
I think you misunderstand. The names are unrelated to React as well, they are native. Defined by the same standards bodies that define JavaScript itself, implemented by the browsers themselves. On a blank HTML page that includes neither React nor anything else, the line `document.body.className = "foo";` sets the body's class to "foo". (And `document.body.class = "foo";` does not.)
All JSX is doing is transforming `<div className="foo">` into `[create div element]; div.className = "foo";`. If you wrote `<div class="foo">`, JSX would faithfully transform it into `[create div element]; div.class = "foo";` - which doesn't work.
Whilst you're correct, that's where the names are from, it's also not totally accurate to suggest it has nothing to do with React.
React defines `React.createElement`, `<div class="foo"/>` transforms to `React.createElement("div", { "class": "foo" })`, so React could convert that under the hood to set className correctly.
Preact does something similar to allow this. However it now seems it is now too late for React for too little benefit. And there's a downside [1]:
> The JSX transform used to do that, but we don't recommend it because it's confusing if you ever try to pass class= or for= as a prop to your own components – you wouldn't expect to access them with a different name.
Good point. I didn't realize that the native DOM properties are also called "className" and "htmlFor". My point still applies though, that this isn't a JSX syntax issue, your point is that it's also not even a JSX-specific semantics issue.
not quite, the list of reserved keywords was made up by the committee that designed the first version of ecmascript in 10 days (or however the exact story goes).
many years later, the workarounds like class -> className were designed by whatever party exerted most control over the JS DOM API (which is not really part of "Javascript itself") at the time, and who also brought you inconsistent camelcasing such as "onclick" ...
it's neither quite "native", nor is "defined by the same standards bodies" much of a sign of good design or worthy of copying.
feels more like if someone were to build, say, a modern high perf numerical library that includes necessary workarounds tributed to the eax/ax/ah/al peculiarities of x86 assembly.
Actually those idiosyncracies are React, not JSX. Using JSX with Mithril I've had no trouble using reserved words as attribute names. Dynamically inserted html in Mithril/JSX is just {m.trust(str)}
Edit: I should also mention that Mithril comes with routing built in, as well as XHR utility and streams. I'm finding streams super useful for sophisticated state management.
You're right, but it's one of those things that you can basically treat it as html until you can't - and the points at which you can't are quite specific and other than className - are rarely used. Also the dynamically inserted html param being obnoxious is by design - they don't want you to dynamically insert html, and that's a good thing. Honestly you shouldn't ever be using that param.
>I can at least remember six template engines' syntax I've learned...
TBH, in 2017, I'm not sure why we're still hand-generating HTML with any template language.
Instead, I'd really like to see a framework that gets away from the idea of HTML templating altogether and presents a true component/properties model on top of a canvas with flexible, property-driven layout options.
I think the intense UI-demands of progressiveness/SPAs expose the unsuitability of HTML for the task. But, simply because HTML is what we're stuck with browser-wise, there's no reason we have to think or work in HTML. Use tooling to abstract it away altogether and let a translator generate it.
We have a components+properties model, driven in Python, which gets translated to HTML+JS+CSS. We also have a visual editor, and abstractions over a bunch of the client-server stuff that's typically icky on the Web.
The challenge of such a system is that the web platform is so huge and sprawling, and constantly growing - and all of it's written in JS/HTML. So we've made the pragmatic choice to prioritise usability by non-web developers, and open an "escape hatch" for doing layout etc in HTML if you really need to. But most of our users don't need it, and we're constantly working to extend the boundary of what you can do with simple properties and components.
Very interesting. Yes, at a glance, that's exactly what I had in mind.
>the web platform is so huge and sprawling, and constantly growing
>we've made the pragmatic choice to prioritise usability by non-web developers, and open an "escape hatch
Makes sense. And totally worth the tradeoff for the developer if it helps me flip the 80/20 rule around. And, if the component model is extensible such that, when I do have to open the escape hatch, I can plug a resulting component back into the framework (lay it out and set properties in the visual editor, etc.), that might be even more optimal. Either way, I'd rather a framework do the heavy lifting and let me deal with the edge cases than me do all of the heavy lifting and plumbing, so that's a win.
>and all of it's written in JS/HTML
And, this is the part where I do have to scratch my head a little. I'm going to guess you've heard this question 4,321,257 times, but why not support JS? It is the lingua franca of the Web (as your quote acknowledges) for better or worse, and virtually all devs already know it. There's also a rich JS library ecosystem.
The idea that I have to pick up Python just to try it out introduces more friction. I'm guessing that might slow adoption with a huge percentage of your potential audience who might otherwise have the knowledge they need to jump right in.
> Yes, at a glance, that's exactly what I had in mind.
Thrilled to hear it! If you do try it in more depth, please do drop me a line (email in my profile).
> why not support JS?
Two reasons:
1. Basically, the moment you use JS, any discipline or abstraction you were trying to introduce dissolves. People will reach in and use the DOM/combine it with other Web frameworks/what-have-you. And then you'll still need to know HTML and CSS and all these other pieces, as well as this new framework, and you've done the opposite of simplifying web development. This is the "Javascript Framework of the Week" failure mode.
2. Contrary to your assertion, "most devs" don't actually know JS. It's something people only learn because they're learning front-end web development, and it's difficult to learn it without the whole HTML/CSS/frameworks hairball. Python is much friendlier to, eg, data scientists or embedded programmers or back-end developers, who have every right to think they should be able to put together a web app without learning three new programming languages and two new frameworks.
(This is another way of putting what I said earlier about "prioritising usability for non-web devs".)
>Basically, the moment you use JS, any discipline or abstraction you were trying to introduce dissolves.
I see. Kind of a purist approach that eliminates all temptation by not offering the option to go there. Sound reasoning, as JS definitely has slippery-slope potential.
>People will reach in and use the DOM/combine it with other Web frameworks/what-have-you. And then you'll still need to know HTML and CSS
I'm probably too biased to make a call on this. I'm so wanting to be released from that madness that I'd fight tooth-and-nail not to descend back into it.
So, I look at it the other way around: My JS would be more disciplined (and there'd be les of it), as I'd be released from the need to use it so much for stuff like DOM handling. In my ideal world, I wouldn't even know there was a DOM or HTML or CSS. I'd just use JS in event handling and, perhaps, functionality that directly supports the same.
>"most devs" don't actually know JS...people only learn because they're learning front-end web development
That's what I intended--that most web devs know JS--as I was speaking in the context of web development.
But, I missed the emphasis on the "non-Web devs" portion of your statement. I do get that and applaud you for staying with your focus. The product has to have a market and an identity. OTOH, it feels so close for guys like me in the Web dev world who know there's a better way!
>please do drop me a line (email in my profile).
Will do. And will try to reserve any web-dev specific comments. :)
I feel that the focus on graphics has faded a bit in the most recent versions.
When I last gave it a try I had to manually generated the HTML document but without a (at least of of the box) syntax like jsx.
If I recall correctly graphics is still there, but it's mainly used for games
Check out the style-elements[0] package and the author's talk at Elm Europe introducing it[1]. It outputs HTML and CSS but doesn't base its semantics on either.
It has a clean-slate design, and there's a ton of buzz in the Elm community about it. :)
This is even worse as for me. Generally the JSX/React.createElement approach itself and the fact that many people like the idea make me cry. Do people like it just because it's given by FB?
The syntax to me is irrelevant. The important bit is to use as much JS and as little string/DSL template as possible.
Why? Because tooling. Anything that's in JavaScript can be linted with ESLint, can be typed with Flow or TypeScript, is subject to dead code elimination by my minifier, can be shared via ES6 Modules/CommonJS wihin my project or NPM with no magic. All editors that understand JavaScript will give me all of their shinies (eg: tell me if I screwed up a conditional) without needing special framework specific support.
JSX itself used to cause these problems too (but createElement and the factories of old did not), but now that they're pervasive and that anything that supports ES6 supports JSX, I get all of these benefits for free.
The moment I hop into template/DSL land, I either hope there's a plugin with all the same benefits (often there is not), or I'm sad.
Note that people who use React + JSX and make stuff like "if" or "else" components fall into these problems too, so those have to be fully avoided.
100% agree. Running Seafile for ~1.5 years with >100GB synced and ~5 users. Couldn't be happier. The sync-part just works.
Big advantages over own/nextcloud:
* Easy updates that work. When I tried owncloud, nearly every update I had to fiddle around with the database to make it work. Didn't have a single problem when updating Seafile so far.
* Block-level sync. Meaning if you change one line in a 10MB file, it will only update that part. Last time I checked, owncloud did not support this.
* Sync just works. When I tried owncloud, folders disappeared, folders were duplicated. Never had this problem with Seafile.
What exactly was the problem with Seafile? I was looking for a Dropbox alternative. Tried Owncloud and was fairly disappointed. But Seafile is working great for me (using it for ~1.5 years now).
Well, okay, it "represents" a block size increase, so that you can put ~70% more transactions into a block. In reality, it is not a block size increase as the block size will stay at 1MB.
But I don't think that this is enough long term. I would much prefer an increase to 4MB or even 8MB.
Long term 4MB or 8MB (or even 32GB) won't be enough. SegWit enables more sophisticated scaling solutions necessary if Bitcoin wants to become anything more than money for a selected few enthusiast.
There are multiple problems with the offer from VG Wort (which is the German association "representing" authors and publishers). One is that they raised the license fee. Another one is that they want to replace the current "flatrate" (where a university pays a fixed sum for the right to copy books or parts of books for education) with a individual billing concept. That means, lecturers have to report to administration for EACH part of a book or paper that they distribute. This model is not feasible as the administrative costs exceed the royalties which have to be payed for the copyright.
For this reasons, multiple virtual learning environments (which are used to distribute books and papers) in Germany might go offline in 2017 because the copyright situation is currently unclear.
We got a university wide mail yesterday that nothing will change for us due to §52a because of the "settlement" with VG-Wort. I entered mild rage mode because it was written as "great news, everything is awesome" while my personal interpretation was WTF are you doing settling this...more like negotiating with terrorists.
Oh well, this boycott is very welcome. I'd also like to see a consortium that aggressively sues these publishers for breaking copyright. There's many cases of OA licensed material being illegally reused by closed journals etc. but usually it's just "please stop"...ok. At the same time the publishers bring down the law with full force for the most trivial stuff.
Yes, but isn't the VG-Wort §52a UrhG thing a different issue? It's creating a whole lot of uncertainty right now, no doubt about that, but the article is about universities failing to reach an agreement with Elsevier. What you're talking about is a terrible new deal between VG Wort and the Kultusministerkonferenz about licensing for publication of any kind of protected material for education and research.
I think you are right. Thanks for correcting me. I thought the Elsevier thing was part of the deal with VG Wort as most mails which are currently going around in my university seem to combine both issues.
