351–357 of 357 posts
For enterprise apps it doesn't matter and for that you can safely use a framework like React. But its very crucial for Internet apps. Surprisingly, Google neglected building tools in that area, apart from guidelines via its webmaster blogs.
Earlier quoted context omitted.
Well everything that happens in a real computer is an FSM. There's a finite amount of memory and therefore a finite number of states.
That's playing fast and loose with the literal every-day definition of the words "finite", "state" and "machine". There is actually something in computer science with a precise mathematical definition called a "finite state machine," [1] that is not simply any machine that has a finite number of states. When you use that term, you're not just talking about what it can do, but also what it can't do, because "finite st…
Leslie Lamport makes the same observation on page 4 here: http://research.microsoft.com/en-us/um/people/lamport/pubs/s...
The comment I replied to was "My experience shows it is a state machine, but I have not see any formal study of it." - I was simply replying "of course it's a state machine".
Lots of situations in GUIs can be modelled as quite compact state machines - but it depends on the level you model it at. If you need to model the state of a text box then your state machine will grow very large since you need a new state for every possible input string. Given modelling simplifications where we abstract away some parts with large state spaces by collapsing states, there are very few pieces of software which don't benefit from being modelled with state machines.
Personally I would be a very frustrated programmer and if I had to program user interfaces with Turing machines since writing a transition table would feel awfully low level and since the Turing machine model doesn't have any facilities for user interaction I'm not sure any users would be terribly happy with the result (so I'm not quite sure what you're trying to say here).
It's really unfortunate that so many people aren't interested in learning Ember. I just started an internal IT tool in Rails and Ember and I'm really enjoying the simplicity of it. I want something that is easy to understand, easy to setup, and won't change for a while. I became more interested in Ember when I read something online about how they are focusing on stability in the long term instead of a bunch of featur…
http://qbix.com/platform/features
Would like to get some feedback on it, from anyone who looks through the features.
One thing I have noticed over the years is that the front end community is becoming more and more a "let me google how to do it" kind of community. The tooling ecosystem is so burdensome. Just to get a hello world app with React, Redux, Webpack, esLint, and ES6 takes forever. Sure there are starter boiler plates but they all don't seem to do quite what you need. Before it felt more like a solidly engineered app, now…
One thing I have noticed over the years is that the front end community is becoming more and more a "let me google how to do it" kind of community. The tooling ecosystem is so burdensome. Just to get a hello world app with React, Redux, Webpack, esLint, and ES6 takes forever. Sure there are starter boiler plates but they all don't seem to do quite what you need. Before it felt more like a solidly engineered app, now…
I would only use React/Redux for a complex app that's going to be touched by a lot of people. That's where it really shines. Elm is a non-starter in these situations -- I can't seriously propose it for a project because the learning curve is astronomical. Also, I think simple Hello Worlds are a dangerous thing. They convince you that a tool solves all your problems until three months later when you notice your foot's…
Elm is much SIMPLER than js, but not as EASY for you because it is new.
If you are at all familiar with compilers, types, and functional programming it should all be review anyways.
If not then you are missing a big part of your education and I would question your capabilities as a programmer.
Earlier quoted context omitted.
parched-tasks-webapp has all but one of those things (hashed file names), and it's just built on browserify. And you don't have to do weird things to get your CSS out of your JS on the server.
Why not just use css modules with the extract text plugin to put everything in a single stylesheet to solve that problem? For Dev it supports hot reload, and other environments get an extracted stylesheet that works with sever rendering and avoids fouc's. Plus you can autoprefix the output, and because of the css modules design you get encapsulated component css for free. The annoyance is working with a css framework…
In both cases, the page is loading an external stylesheet, so both are as susceptible to FOUCs as the other.
This is only my opinion, but using CSS loaders backs you into a corner where your javascript file is suddenly less portable, since the environment it will be running on needs to be aware of it.