Hi! This is super common feedback and something the team is definitely thinking about! What would you want to see it increased to? (Chris Munns from Serverless @ AWS)
This would be amazing! At lot of ML use cases are largely unfeasible in lambda on python without serious pruning. Latest version of tensorflow is 150mb uncompressed, add numpy pandas etc to that and it adds up fast. I think 1 GB uncompressed would be pretty reasonable in the current state of ML tools, personally.
As a thought, could Lambda (perhaps in cooperation with AWS Sagemaker?) offer a Lambda execution environment atop the AWS Deep Learning AMI? This would solve a lot of problems for a lot of people
Is there any plan to add more disk space, or a way to fan out jobs? We use a lambda that does work on video files, we have to limit how many run concurrently (3) to prevent running out of disk space right now. Edit - or ability to attach volumes like Azure's lambdas.
Can't wait for this too, it seems kind of old limitation not suitable for layers at all. But on another hand - lambda should be small and fast if something out of limits is needed then fargate or ecs should be used.
That said I I hope they increase the limit to at least 500 Mb sooner than next reInvent.
Worked at Amazon from 2010 - 2012. Left because I wanted to create something of my own. Have failed twice at since then, hopefully will succeed this time.
Website looks nice! My 2 cents would be to maybe have a demo dashboard without signing up? I just feel like it forces people to invest without knowing what it is. Wish you success!
ChartPoet is like Google docs for databases.
ChartPoet provides an excel/sheets like collaborative environment for databases so that people who dont know SQL can work on querying and visualizing data.
Have a look (Access Pin: 7612) at this
OP! Nice of you to ship this. We need more of editors and self publishing platforms.
I tried creating an editor a few years ago at my last job [1]. It is really hard to get all things correct when implementing your editor, with all quirks that contendeditable has.
At my last job we did a comparison between Vue and React before rewriting a major frontend application.
We did a POC in both React/Vue and ended up using Vue mainly due to the following reasons:
Single File Components
Single file components (.vue files) is the best thing about Vue.
I understand this might be a personal preference, but we wanted to avoid CSS-IN-JS.
Our designer could churn out neat html/css, but was a beginner in Javascript.
With Vue's single file components, he could also hack parallely with us while iterating on html/css.
Standard / Official way of doing things
This again is a personal preference but Vuejs comes with a recommended way to do a majority of things.
Vuex(state management) and Vue-Router are provided/maintained by same Vue core team.
React at times can be overwhelming for beginnners, just because of the amount of choice available
Example:
Google Search for 'React CSS style' [https://www.google.co.in/search?q=react+css+style] points to a bunch of links all of which link to valid solutions, but I have to go through a few of them before I get what I am looking for.
Also, as a team we were primarily writing Angular 1 when we decided to choose a frontend framework for newer projects.
I feel this also made our transition to Vue easier vis a vis React
> Our designer could churn out neat html/css, but was a beginner in Javascript.
I write JS every day, and frankly that code looks like an unholy mess to me, so I can't imagine what it looks like to a beginner. Is "styled.div``" a function call? It's not self-evident. How do you do inheritance? Is that a template string with functions inside it? Would that CSS autocomplete?
That code looks very much like it sacrifices ease of writing CSS for ease of writing JSX. That isn't the correct tradeoff for everyone.
You're writing scss within the text blocks. You're correct that you need some understanding of JS.
I've never worked with designers that wrote css, I'd also probably not trust them to do so (my own failings).
I don't agree that it looks like an unholy mess (hyperbole may be lost on me), but I can see how it could be jarring at first look. I had a similar reaction when I looked at Relay (https://facebook.github.io/relay/), when they used literals for data fetching.
So, yeah, you lose all the syntax highlighting etc. that comes with just writing normal CSS. I don't think it's unreasonable for a designer to object to that - how would you feel if you were presented with a build system that required you to write all your JavaScript inside one big string statement?
Maybe it's just me, but I don't find it intuitive at all. `styled` has properties for, I assume, every HTML tag? But it can also be called as a function for inheritance purposes? And that inherited call appears to use the same tag as its parent... but what if I want to reuse styles across different tags? How could I define some shared CSS properties I'd use across different elements?
Don't get me wrong, it is cool stuff. But it also feels far too much like hand-wavey magic stuff. I've literally never used Vue before, but looking at this page:
I have zero confusion about how to write styles for it. And I really don't understand why styled-components would be worth the extra effort by comparison. What does it bring to the table? It's different without a compelling reason for being different.
> I mean, same way with Vue really. If the editor didn't know wtf a Vue file is, you'd lose all the integration too.
In a way, that's fair. In another way, the example single component Vue file I linked to is an HTML file. It has a <script> tag and a <style> tag. Just associate .vue with HTML and you're done.
That gets to my broader point as well - styled-components reinvents the way you declare styles and the way you apply styles, and requires the entire thing to be written as a JS file. And for what? I still don't understand what the advantage is over a syntax everyone already knows (and has validators for already!)
If you remove styled-component specific tooling from the equation to simplify the argument and just use Glamorous instead of styled-components (which are very close to the same thing except the later is just JS), then it's exactly because of tooling.
The reality is that tooling for templates (even Angular or Mustache style) is pretty terrible. Tooling for CSS is just as terrible. Static analysis or doing simple things like interpolation of data is pretty darn bad.
But JavaScript tooling isn't half bad. It's not the best there is, but its still reasonably advanced. Thus you have React, which is basically just JavaScript and objects. Sure JSX, but when used in React, it's just sugar to define those objects (hyperscript would work just fine too if you don't want to use a compiler, and early on in React's life just creating the objects from factories was just fine. Certainly better than weird templates with bad tooling).
Once it's all javascript, everything works: my linter works (and is certainly more advanced than css linters), both major type systems work, my refactoring tools work, and I have all the language at my disposal without learning anything new to do stuff like conditionally showing or hiding things. No need for an ng-if, v-if or whatever.
The same logic keeps going with styled-components. Associate the styles with a plain old JavaScript object, using javascript constructs (in this case, template strings), and all the tooling to manipulate them, interpolate them, or type check them just works (eg: TypeScript isn't bad at typing interpolations in template strings). And if that's not good enough, Glamorous is just objects so it's even easier.
Now I mentioned both styled-components and glamorous...normally this logic would heavily favor the later, but for some reason, tooling for styled-components have gone above and beyond to make up for the shortcomings of template strings, so it ends up working better for me.
Maybe someday some very motivated people will make tooling for the non-JS parts of ecosystems that are not "all JS", and this point will be moot, but right now the React ecosystem is the one that lets you most heavily lean on tools.
It's probably why it doesn't look so great from a newcomer perspective though: if you're not at a point where you're trying to squeeze every last bits of power from the tooling ecosystem, then it's just overhead and a waste of time.
Is it bad to write without all these JS tools?
We just use Visual Studio and include the standalone Vue.js file. We write plain css (no sass etc) and js with some occasional JQuery. We don't use Nodejs and its build tools (Kinda don't like the complexity all those tools bring. You are more worried about the tooling than the actual problem at hand). We use Ajaxmin and Httpcombiner. That's it for Frontend.
Vuejs is great. Found it to be easy and simple to understand. Big thumbs up for Evan You.
It's not bad at all. You just have different requirements. I prefer React, but if the apps I was working on came to change in requirements, I'd be very happy to have Vue as an option. I don't think having 16 different major frameworks that overlap in functionality is healthy, but having a handful of fairly distinct ones that overlap on some points is just a good thing.
We have hundreds of full sized frontend applications, millions of lines of both javascript and scss. Thousands of extremely complex i/o operations and algorithms. We push the tools in the ecosystem to their limit and have to write our owns where they fail us.
And when I'm at home making a small app, create-react-app and VSCode, then npm install-ing styled-components, is all I need to replicate 80% of the above. It's all just JavaScript so all my tools just work the way I expect them to.
Not everyone needs (or want!) this. And that's okay.
Agreed.
The webside ecosystem is in a high state of flux. It has to be streamlined somewhere. Does it need a fundamental architectural change? Would like to see things a bit more saner ;)
I would argue that the right boundary for designers to be working with front-end people is via central company style assets, and not at the component level where ad-hoc styles should be stored.
It seems a little odd that the front-end designer, who is in our hypothetical not comfortable enough to actually work on component themselves, would be brought in to tag-team with someone else who also doesn't feel comfortable enough to do the work themselves.
I much prefer putting the styles in a separate {componentName}.scss file, import'ing that into the component and using the Webpack Extract Text Plugin:
You can work with two files per component if you must truly put the styling in another file.
One of the boons of react is that you can create a set of reusable base components that can be built upon throughout your app.
If you can code-split the app, lazy-loading components as needed, and if you can cache all of the static app anyway, why does it matter if the presentation is tied to the logic?
The same can be said for vue.js. :)
The two languages have many merits and they both make their own sacrifices. But they are ultimately two peas of a pod.
Like Thor and Loki.
But who is Thor and who is Loki? ;)
Why do packages like this need to be ported or re-implemented for Vue rather than referenced? That package hasn't been updated since August while the root styled-components library has ~700 closed issues and 11,300 watchers
I've seen it with other stacks as well with almost complete re-implementations, a lot of duplicated effort and it feels like it goes against the packaging philosophy for javascript
20 minutes vs an afternoon is probably not a great gauge for making technology choices.
I highly recommend watching Rich Hickey's "Simple Made Easy" [1] talk which covers how the right ("simple") choice may not be the "easiest" (convenient, most familiar) one.
I don't mean to be an arse, but if you agree with my point, then maybe you can see why I disagree that your "that and" is a valid strike against React/in favour of Vue.
Simplicity makes picking up the unfamiliar easier. You can't accurately deduce from time alone that the time to pick up Vue was based on familiarity with similar libraries.
> Simplicity makes picking up the unfamiliar easier.
The talk I referenced talks about how the opposite is often true. Tools that result in objectively simpler systems can come with a initially steeper learning curve.
> You can't accurately deduce from time alone that the time to pick up Vue was based on familiarity with similar libraries.
True, I was really just suggesting questioning instincts when evaluating tools based on the initial 'time to get started'.
> "The talk I referenced talks about how the opposite is often true. Tools that result in objectively simpler systems can come with a initially steeper learning curve."
I'm aware of Rich Hickey and Clojure. In my experience with Lisps, although they are superficially simple, they make you do more abstraction work than is necessary in more commonly used high-level imperative languages. Lisp seems to strongly encourage building a high number of helper functions, which is fine if you're highly opinionated about how a job should be done, and less so if you just want to import some battle-tested libraries and write something that gets the job done. I suspect this is where the learning curve with Clojure really comes in, in that it's more closely related to being learn how to architect an application in a Lisp-friendly way than it is about getting familiar with the language.
Totally agree actually, I love all Rich's talks and agree with almost every word of Simple Made Easy but I don't necessarily agree with the conclusion he takes it to (Clojure).
I've heard it suggested somewhere that possibly the leap is in believing that 'a simple thing + a simple thing = a simple thing'.
npm install -g create-react-app
create-react-app my-app
cd my-app/
npm start
Your sentiment is correct that tooling around these pieces of technology needs to always be first class. React failed miserably, and Vue did an AMAZING job.
I'm probably starting to sound like a shill for React. I've used both and love both. I do like that React is "just javascript", which I think is why I use it.
I used that. I took me a huge time just to understand what all the tooling was doing, how to integrate it in my current stack and how it was going to affect my current project.
My pet peeve with react is that I can't just code. I have to stop every 10 steps and reflect on the tool I use, instead of the problem I'm trying to solve.
I have no idea what you are talking about. React doesn't require any tooling. Drop a reference to React from some cdn in your HTML file and you are good to go. People confuse the myriad of libraries and tools complementary to React for React. You don't need create react app for Hello world.
Create React App gives you a zero configuration way to not only write hello world, but also bootstrap a non-trivial production ready application. In the company I work for, we were previously using JSPM/SystemJS/Gulp. We replaced all of that with create-react-app. It allows you to very easily bootstrap existing applications on top of it: http://fredrik.anderzon.se/2016/12/04/adding-create-react-ap...
And if you want full control of your project, you can "eject" and CRA will generate the webpack configuration file being used so that you can tweak to your heart's content.
I use React daily, and the whole experience has been extremely pleasant.
> My pet peeve with react is that I can't just code. I have to stop every 10 steps and reflect on the tool I use, instead of the problem I'm trying to solve.
Thank you! Every time I've tried react (and enough attempts were made to finally decide it was just not for me), there was always something in the back of my mind that I didn't like and I just couldn't put it to words. You just described what it was.
And, if one forgoes tooling, then the situation is like the one you described in your previous comment: an afternoon just to get a "Hello world".
As far as the actual libraries themselves go, if any of Vue/Angular/React are the new jQuery, it's Vue. It's the smallest of the three, but more importantly it's the easiest of the three to drop into a page without any tooling.
I have a hard time understanding why this "drop in" experience is so important. Are you all writing simple contact us forms or something incredibly simple?
Any application that I've built which actually required a technology like Vue or React was a significant undertaking and a few hours getting up and going (not that either of them require anywhere close to that) is nothing.
I don't see how jQuery could have been anywhere near as ubiquitous if it had required a build step.
It makes experimenting easier for beginners, for people considering switching to it, for people who are already using it and want to try something outside the context of their existing codebase, for people writing tutorials and demos, etc.
The less bullshit to wade through when using a tool, the more situations it will be applicable to, regardless of skill level or project size.
That's just it though, Vue & React aren't for most web sites. There is no point in pulling either in unless you are building something much more complex than where jQuery would suffice. There is no need for a technology to be "ubiquitous", just that it is going to meet the demands your application has for it.
Actually vue is so small and simple you can just drop it anywhere. Even on non JS heavy website. It's a bit like redis. Low price. Always nice to have. Very reliable.
First, as a learning experience it's easier. In the HN bubble it's easy to forget most web project out there don't even have npm installed. I regularly train dev that just learn what ajax means.
Secondly, a lot of my projects just don't need anything else. If i have a 2 weeks contract with a client, i'm not going to setup webpack, a ci server and docker.
Having the choice to scale up or down is an amazing feature.
Which order did you attempt to learn them in? Is it possible taking the time to attempt to learn react affected how easy it was to pick up Vue? I know we love to hate on React here but they are very similar. Can you identify what in particular is so confusing with regards to react vs. vue? They have a very similar API.
Vue dlc is better. Vue doesn't require webpack. All vue tutorials agree on how to so things and they work the first time you try them. You son't have to learn a new way to do templates or pass data. You can start withou components. You can even start without npm.
In summary, vue offers a simpler hands on experience while allowing smooth learning curve to more complicated setup matching react's.
React just throws you in unkown waters and say 'now swim'. And on the side of the river, 3 persons are screaming to you contradictory advices.
Vue requires webpack when going for anything beyond a simple hello world experience. At some point beginners are going to have to enter the real world.
BTW - You don't need webpack for React either. It is entirely possible to write React without it.
> Vue requires webpack when going for anything beyond a simple hello world experience
Not at all. That's the beauty of it. A lot of projects just drop Vue in a script tag and use no components. There are 1000's of projects out there with such a scale that anything else would be overdoing it.
> BTW - You don't need webpack for React either. It is entirely possible to write React without it.
Technically yes. But realistically no. First, you will find almost zero doc/tutorials on how to do so. All the ecosystem and community assumes webpack, and a top-down component architecture. If you ask on a forum how to do x, people will promptly tell you to use Redux. And the React API is clearly not comfortable anyway without tooling.
It's a bit like saying "well you could perfectly code a Java project without an IDE". Yes you can. But who would do it ?
>Even if you don’t like the idea of Single-File Components, you can still leverage its hot-reloading and pre-compilation features by separating your JavaScript and CSS into separate files:
<!-- my-component.vue -->
<template>
<div>This will be pre-compiled</div>
</template>
<script src="./my-component.js"></script>
<style src="./my-component.css"></style>
If I end up going with Vue, I'd probably do that. It looks like a lot of boilerplate though ...
Is there any tool from the Node ecosystem designed to reduce that boilerplate?
I started off hating the idea of single page components; I'd have much rather had a component reside within a directory (with template.html, style.sass and script.es6.js files or whatever) but in reality, so long as you keep your templates light and do any heavy lifting elsewhere, it's quite manageable.
Newer JavaScript functionality makes that work nicely.
Well, this approach of single file components (.vue) containing separately scoped HTML, CSS and JS is what the Google Polymer team were recommending all the way for the last several years, but it seems no one was listening to them.
