* Integrating with non-TypeScript libraries can be difficult depending on the quality of external typings available
* Error messages can at times be slightly obtuse (especially depending upon the complexity of types used)
* Learning curve of TypeScript (Certain language features can be a bit complex. For example, mapped/conditional types might seem tough for a beginner. See here for an example[0])
That said, to me, it's still a no-brainer to use TypeScript for anything beyond the most trivial of apps. The advantages it gives you have heavily outweighed the disadvantages in my experience so far.
My favorite is [1]. The downstream errors that type generates are "fun."
"Slightly obtuse" is an understatement when dealing with `Pick` and the errors the complimenting mapped types generate. Once you throw in React and higher order components, you can get errors that are literally several console pages long - although that's usually just tsc "tracing" the error through the complex types.
Yes, your experience mirrors mine completely. It's quite difficult to get complex higher-order components working correctly, especially if you're throwing in things like defaultProps and propTypes. For example, some issues I've hit recently: [0][1].
I think this is likely an artifact though of how powerful TS's type system is. I'm sure there're error-readability improvements possible, but with such complex type constructs, it's not all together surprising to me that the error messages can be difficult.
My worry with these challenges is not that they make TS unworthwhile (it's still completely worth it), but they do make it a little harder to convince a team to adapt TS and sell TS to React developers who are use to working in JS.
I know the TS team has React support as a priority and they've done a pretty great job of making TS React-friendly. I do wish they'd be slightly more hands on with maintaining `@types/react` and even publishing documentation, but perhaps it's fine to leave that to the community.
I always found react-redux's connect function maddeningly hard to understand, because it does far too many things all in one function. The types just expose that complexity, and make it plainly obvious that it should be split apart.
The great thing about types is that the make you think more about keeping you APIs nice and clean on a semantic level, not just about if the syntax in your examples look pretty. I really hope more library authors use them early on so they avoid such mistakes in the future. There's only so much the Flow and TypeScript devs can do to make up for those existing problems.
Which gets to my wish that instead it is the React team themselves that adopt and maintain @types/react more directly, rather than leaving it to the community and/or Typescript devs. Seeing CRA add default support for Typescript transpilation with easy opt-in for type checking, is a great sign that plenty more React developers are going to have a chance at Typescript. Hopefully it becomes more of a two-way street where the Typescript community isn't just typing major React libraries after the fact, but more of the libraries are directly written in Typescript or at least the types are directly maintained by the authors of the APIs.
> Feel free to make a PR to improve things boubiyeah
What kind of answer is this?
I don't think "boubiyeah" is working for you, nor has signed up for contributing to your project.
When you publish something to a public forum, even if you it is an open-source project, you open yourself to criticism(actually criticism is a great tool to help you improve your project), so my suggestion would be to be open and positive about the feedback, even if it is not all back-patting.
PS: You have done great work on the toolkit, thank you for making it open source.
In my experience[1] the best way to get contributors is exactly the opposite, you have to leave the easy and cool parts for new people and do all the grunt work by yourself. Making a new feature is something fun that other contributors can try to do and learn a lot, while optimizing your website is something that mostly only saves you money (as contributors could do that virtually anywhere else and learn the same). See an example of what I mean: [2]
I think given the gp, this is quite a perfect reply. 4.2mb of js on a text-oriented docs page is either an infrastructural problem or it's by design. Dismissing it casually as something that can be considered a simple "issue" solvable with a PR or two seems a pretty clear sign of "people who don't see performance problems".
I appreciate that it's open source, so inviting PRs and general contributions is cool, but there does seem a bit of a dearth in understanding of the problem.
This makes me cringe. Sure, encourage us to make a PR to implement a tri-state radio button if it doesn't exist. Don't encourage us to make a pull request to reduce a 10 second documentation page load time.
Is there a demos section? Tried to load http://blueprintjs.com/docs/ on mobile (chrome and Firefox on Android), most of the page is cut out due to scrolling restrictions
That's the right place to see examples - sorry that it doesn't work well on mobile yet.
Just as a caution though, the library, in general, is intended for desktop web applications. We haven't made mobile-compatibility a priority, although at the very least, yes, we would like the docs site to be at least usable on mobile!
The funny thing is, so many people don't seem to realise that ordinary end-users will be, too. End-users care about performance. Not all of them necessarily understand that what they care about is performance, but it all contributes to the experience. Even back I need the 90s there was much statistical evidence that the slower a website was, the lower engagement it received.
Hi all, I work at Palantir and worked on Blueprint (although I'm currently working on a different project). Happy to answer any questions you have about it.
Just a note - we didn't intend to heavily publicize the project quite yet. For example, the docs site is still a WIP, so apologies if it causes issues for you on mobile devices.
Just a nitpick, but when looking at the docs, I can't move with Page Up/Page Down unless I click in the "content column/area", kind of annoying when one navigates using the left bar and then can't move around (on no-mouse setups, e.g. trackpoint + keyboard). So you might want to look at that.
Otherwise no issues (older laptop i5/chrome), so I guess you guys mostly fixed that by now.
I really like blueprint! Although I think it's a bit ambiguous in the documentation that there are some elements under 'components' which are not react componentsp per se. You are referring to this as they have a 'CSS API' (like navbar). It' not a big deal but if you are doing a react app it's good to have an overview of the actual building blocks.
Maybe they should be under another section?
Hi! I'm not a web developer, I work on server side, native mobile and desktop, but I'm very impressed with your framework and want to give it a try for creating UIs. What I really don't like about web development is it's overcomplicated approach to laying out the elements. Do you have any kind of layout helpers in your framework?
Thanks for the kind words achikin! Blueprint doesn't include anything to simplify layout. However, if you're able to only support relatively modern browsers, flexbox [0] is a great CSS feature that really makes layout easier. If you're looking for something like the traditional CSS library grid, you can always grab it from a different library, like PureCSS [1], and use it side by side with Blueprint.
This might be a little bit outside Blueprint, but, I cannot not take the opportunity to ask - how is the reactions internally at Palantir now when the chairman and co-founder now also is part of the Trump transition team?
* Slightly more complex build workflows
* Integrating with non-TypeScript libraries can be difficult depending on the quality of external typings available
* Error messages can at times be slightly obtuse (especially depending upon the complexity of types used)
* Learning curve of TypeScript (Certain language features can be a bit complex. For example, mapped/conditional types might seem tough for a beginner. See here for an example[0])
That said, to me, it's still a no-brainer to use TypeScript for anything beyond the most trivial of apps. The advantages it gives you have heavily outweighed the disadvantages in my experience so far.
[0]: https://github.com/piotrwitek/utility-types/blob/532fe5cfcc5...